World: r3wp

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

works with whatever extension you like

don't get me wrong, i really like the .rx idea

Cool, like Windows. I can make a mezzanine patch for the platform 
file-types that would work for all supported platforms if you like.

but this minimal change of adding two lines would get things started 
for now

yes, please

but wouldn't that exactly be what i did in rebdev#6258?

heck, osx is not even supported right now :)

No, it wouldn't be the same. Don't take it personally if I deny that 
submission - it's what started this conversation :)

I don't

So you'd get rid of the append in mezz-init.r completely, and add 
the extension filetype some place else?

I'd put it there (I think), but it would be different code.

The mezzanine parts of the extension/module model are where I am 
the most familiar with the code :)

great

just a quick reminder: on osx .dylib and .so are both ok

OK. They're just for convenience though, since every almost dylib 
that is loadable as an extension will have been written specificly 
for that purpose and probably can't be used otherwise, so sticking 
to the .rx filename makes sense.

I'm hoping to prove that wrong with some extensions though.

It might be nice to use .rx as "virtual" extension only

then i could have a single script, say foo.r shipped with bar.dll 
bar.so and bar.dynlib, use import %bar.rx in foo.r and it will select 
the proper platform specific library

this will break down as soon as we have e.g. 32b and 64b builds for 
the same platform