World: r3wp

The idea of a "safe" extension is tenuous at best as it is. Don't 
add the possibility of having some system-specific libraries polluting 
the file name space. For instance, I would consider one of the minimum 
requirements of a system-installed "safe" extension to be that it 
be guaranteed delayable.

Nobody but you is talking about "safe" extensions.

We are talking about making those pesky & horrendously unsafe native 
extensions work slightly more smoothly across platforms.

If you want safe binary extensions, rewrite REBOL on Genode with 
a GPL license. Anything less won't do

One interesting thing you haven't considered: sys/load-module calls 
lib/load-extension without checking whether it is native. You can 
override lib/load-extension with a REBOL code wrapper, in %rebol.r 
even. Then you can do any safe lookups you like without messing with 
host code, and even translate .rx suffixes to .so if you like.

Interesting indeed. But one of the main points is that condemning 
this functionality into %rebol.r is not sufficient.

This is a great way to experiment with platform integration, and 
what you learn can be adapted to the host code.

Also, I don't think that triggering platform-specific suffix replacement 
by using %filename.rx is a particularly good idea (too much magic). 
But it is one option.

I don't think using a platform-specific suffix for a cross-platform 
extension and then expecting code that uses it to be cross-platform 
is a good idea. YMMV.

Yeah, as should be obivious Kaj and me strongly disagree with this 
sentiment.

The extension file itself is not cross-platform (in most cases, at 
least), therefore using a standard suffix is extremely appropriate.

And "code that uses it" can trivially be cross-platform. We only 
need to solve the filename issue.

Yup. But that's why extension lookup is implemented in a platform-specific 
way, internally, to gloss over those differences.

Fortunately there aren't many platforms that only use platform-specific 
filenames for dynamic libraries. Those can be adjusted for. At least 
the .rx naming convention is better than something like -rxt.so or 
something.

Brian, it really is not about "platforms that only use platform-specific 
filenames".

Really? Because't on Windows and OSX this is not an issue, this is 
expected behavior.

Linux's loader in general couldn't care less about the extension 
of a shared object. That doesn't make it any less prudent to stick 
with the standard .so extension.

prudent to stick with the standard .so extension

 - I'm having a little trouble understanding this, but maybe that 
 comes from too much experience with platforms where it has been demonstrated 
 that there are advantages to distinguishing between different dynamic 
 library types by using different file suffixes. The "standard .so 
 extension" means that these differences get put somewhere else in 
 the filename. But I can see your point with libraries like System.Data.Sqlite 
 that support more than one calling convention in the same file, so 
 that the R3 extension API would just be added to a system dynamic 
 library that is otherwise meant to be called by non-REBOL code - 
 incorporating its own wrapper extension.

Remember, on many Linuxes you just want to load libc, but the actual 
file is something like libc.so.6 or something (I'm paraphrasing here). 
Having LOAD-EXTENSION translate .rx is no different from that. You 
can even have a filename map on your platform if you like.

It is different, as in the Linux case you add the standard extension, 
while in the REBOL case you want to change the extension. The latter 
is less expected, so more confusing

There is no further translation happening on Linux from libc.so to 
libc.so.6 as that is just a symlink in the file system

Based on our discussions I started writing an improved extension 
loading mechanism:
https://github.com/earl/rebol3/blob/master/modules/extload.r3

It's main purpose is to translate a "generic" extension suffix (%.rx 
per default) to platform-specific extension suffixes (yes, potentially 
many).

It hooks into the extension loading process (LOAD-EXTENSION) as suggested 
by Brian, so it works transparently.

All you have to do to use it, is to import the 'extload module first, 
before you import any native extension. After that, use the generic 
suffix to load extensions.


For example, let's assume you want to load your platform's cURL-binding.* 
extension:

import %extload.r3
import %cURL-binding.rx


On Linux (in the system/platform/1 sense) and FreeBSD, this will 
first attempt to load %cURL-binding.rx and if that fails, %cURL-binding.so.


On Windows, %cURL-binding.rx and %cURL-binding.dll are tried (in 
this order).


On OSX, %cURL-binding.rx, %cURL-binding.dylib and %cURL-binding.so 
are tried (in this order).

The actual suffixes tried are by default taken from system/options/file-types.

Filenames not ending in the generic suffix are left as-is; so event 
with extload present, if can use e.g. import %cURL-binding.so directly 
and bypass the suffix translation mechanism.

I hope extload to be a suitable foundation upon which to further 
discuss these matters.

And for this to lead to eventually integrating an improved loading 
mechnism  directly into R3.

You can try them in the order the suffixes appear in system/options/file-types. 
That way your code doesn't have to special-case per platform; let 
the host code special-case it instead. Just in case .rx isn't supported 
on a platform, you might consider searching for 'extension and backtracking 
to get the file! suffixes.

The .rx suffix seems to come first in the platforms I know of.

>> find/reverse/tail find system/options/file-types 'extension word!
== [%.rx %.dll extension]

If you are doing this already, consider it documentation for the 
others :)

Do we need a system/options/extension-paths setting? You could add 
it to system/options in your %extload.r3, and it would let you preconfigure 
your system with a directory of shared extensions, if such a thing 
exists. Or it could just be assigned the same block as system/options/module-paths 
by default.

Yes, Brian, as I stated above I'm already using system/options/file-types. 
Quoting myself:

The actual suffixes tried are by default taken from system/options/file-types.

An extension-paths setting and searching this path would be a good 
option (esp. on platforms with weaker loaders). But more about this 
later, gotta run :)

I'm fighting with some "undefined references"

(.text+0x867): undefined reference to `RXARG_SERIES'

The problem is, I'm not sure where it happens in the source-code 
file as the output doesn't tell you. But can't I use the (.text+0x867) 
stuff to locate the usage in the source file?

Or is there a better way to map the error message back to the source 
file?

Search thru all your source files for RXARG_SERIES and replace it 
with RXA_SERIES

OMG... this is a good example of seeing RXARG_SERIES and understanding 
RXA_SERIES... I though I did this already.

But RXARG (the old one) was a shortcut to access the .series union 
member. The new RXA_SERIES one needs a frame pointer and a number. 
Which I don't need. So, the new approach is to access the union members 
directly?

Yes.

Ok.

At least there currently is no set of macros to work with "standalone" 
RXIARGs.

Only with RXIARGs contained within an RXIFRM (or frame-like array, 
like in the callback info).

I built my own macros to do exactly this.  I proposed them to Carl, 
he mentioned he'd put them in the official distro... seems like I'll 
have to put them in git hub myself  :-)

Good aproach, Max. Now If Carl mistakenly uploads r3 core DLL, we 
might get in beta after all :-)

Just a question: with the extension model complete is it possible 
to interface to .NET ?

The answer to that question is as yet unknown. Noone has tried it 
yet. Do you mean calling into the .NET APIs from native code, or 
calling into native code from .NET?