World: r3wp

But realistically there will be loads of purpose built non-portable 
extensions

And as allowing them to be used with their native extension does 
no harm as far as I can tell, I'd enable that usage alongside the 
.rx

Doesn't negate my argument. Having them named .rx will mark them 
as extensions, which have a specific calling convention that must 
be supported. Nonetheless, if you do decide to also allow the default 
platform dynamic library naming convention, only allow the name supported 
by the current platform. So no .dll on Linux, no .so on OS X, no 
.dylib on Windows.

Sounds like needlessly complicating the code

.so is correct on osx

simply marking rx/dll/so/dylib as possible extensions for extensions 
sounds perfectly reasonable

Not needlessly - .dylib files don't work on Windows.

Yeah, but who cares?

They even might, if someone wrote a dylib loader for windows

We do. Simplifying the code would be to just support .rx and have 
the LOAD-EXTENSION native in the host code do the translation.

Go for it, then

I'd add some nice magic for .rx

And keep .dll .so and .dylib as they are now

If some use desperately wants to use .dylibs on Linux, I don't care

some user*

I want to keep .dll, .so and .dylib files as they are now. That is 
what we write .rx extensions to wrap.

But a .rx is nothing but a .so

No, it's a .so with a really specific set of exported functions.

Yes, the definition of a dynamic library

If you want a single platform extension: name it foo.so, use it with 
import %foo.so; if you want a multiplatform extension: create libraries 
foo.so, foo.dll, foo.dylib, import with %foo.rx

Sounds reasonable and simple to me

It's the same as .ocx or .exe files on Windows - what matters is 
the specific functions they export. All .rx files export the same 
functions.

That's fine, but they will still be platform specific binaries

But whatever

So what? There's no reason why dynamic libraries should be called 
.dll on Windows and .so on Linux, none at all.

Go for .rx, fine with me

If you add a capability to ship multiple libraries easily, that would 
be great as well

I.e. that i can ship linux, windows and osx extensions along with 
a simple script, and use the proper extension on the proper platform

Universal Binaries or some such?

nope, just simple namespacing issues

if all three extensions ought to be called foo.rx, shipping them 
side by side will be tough :)

There are many platforms that use incompatible .so or .dll files, 
so a packaging/installer format would be good.

yes

the nice thing about my patch: it would enable linux extensions _right 
now_

letting people play with them

We aren't just supporting 3 platforms.

currently you the hostkit supports only 2

i like small, incremental changes

No, it wouldn't because LOAD-EXTENSION doesn't work on Linux yet.

load extension works great on linux

Check if it works with .rx named files, I'm curious.

$ file ext/sample.so 

ext/sample.so: ELF 32-bit LSB shared object, Intel 80386, version 
1 (SYSV), dynamically linked, not stripped

that's the sample extension from the R3 extension zip released some 
months back

$ ./r3 -sq
System object protected
>> append system/options/file-types [%.so extension]

== [%.bmp bmp %.gif gif %.png png %.jpg %.jpeg jpeg %.dll extension 
%.so extension]

>> import %ext/sample.so
>> add-mul 10 20 30
== 900

and that's a hostkit compiled with my posix loading patch

And have you tested by adding .so to system/options/file-types at 
runtime and then using IMPORT on an extension?

...

Never mind, it was an AltME delay.

thought so :)

>> append system/options/file-types [%.rx extension]

== [%.bmp bmp %.gif gif %.png png %.jpg %.jpeg jpeg %.dll extension 
%.rx extension]

>> import %ext/sample.rx
>> add-mul 10 20 30
== 900