World: r3wp

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

If LOAD-EXTENSION can be changed to look for .rx first then for .dll 
(or whatever) then this can be seamless. Otherwise it will require 
ugly changes to LOAD. It might be better to make a platform wrapper 
module for your app.

Fortunately the module system is based around importing into the 
system, rather than importing into modules directly. This means that 
you can have all of your platform-specific requirements handled by 
one module or script and then have the rest just reference by module 
name, not file name.

There won't be 32 and 64 bit builds on the same platform, in theory; 
32bit builds get one platform number, 64bit builds another.

We'll see if they mess that up though.

Andreas, what do you think of this code instead?

append system/options/file-types [%.rx extension]
switch fourth system/version [
	3 [append system/options/file-types [%.dll extension]]

 2 [append system/options/file-types [%.dylib extension %.so extension]]
	4 7 [append system/options/file-types [%.so extension]]
]

Whoops, that's a little too verbose.

switch/default fourth system/version [
	3 [append system/options/file-types [%.rx %.dll extension]]

 2 [append system/options/file-types [%.rx %.dylib %.so extension]]
	4 7 [append system/options/file-types [%.rx %.so extension]]
] [append system/options/file-types [%.rx extension]]

append system/options/file-types switch/default fourth system/version 
[
	3 [[%.rx %.dll extension]]
	2 [[%.rx %.dylib %.so extension]]
	4 7 [[%.rx %.so extension]]
] [[%.rx extension]]

?

Better. I wrote the original before I wrote the default.

I like .rx name for an extensions. I also seem to understand, what 
is your motive for it. But - will not it confuse users? I mean - 
if I try to run R3 under Linux, I might be tempted to copy extensions 
to linux, becase I expect .r script to be cross-platform, so some 
ppl might expect .rx is just cross-platform too. But that surely 
is not the case - those are platform specific, no?

I have some extension macros (simple stuff) how to submit to Carl?

and why not submitting it to our eyes too ?

R3 Chat ...

Ok, because posting source-code within AltME is really no fun.

Further it's lost within the discussions at some point. I just wanted 
to provide the file so that it can be reviewed and included in the 
next release.

Some people put files on a website and post a link.

AltME File Sharing?

Not enabled here ..

You could always post it to Qtask's REBOL SIG project.   It has been 
there for about 5 years...

That's a good one!

So I can choose between 5 different ways. And I don't know which 
way will be the best that the contribution is taken into account... 


Guys, you know that I'm a real Rebol supporter but as long as the 
most basic things (like submiting a patch, and being sure it's taken 
into account)  are not made clear and simple and people can see it's 
looked at we don't have to wonder about "low participance".

Robert - R3 Chat is official SVN for R3 and soon even for R2. I would 
learn to use the Chat. Hopefully once R3 Veiw is available, GUI client 
will emerge ..

I'd agree on using R3 chat. Contributions directly to Carl is what 
it's for. If I could figure out how to upload sources, surely Robert 
can. :-)

Remember that R3 chat is the direct replacement of Devbase we had 
for R2.

Years, ago I said that information channel fragmentation in a small 
community is evil. We still have the same situation or add new channels.

But OK, I use R3-Chat and will post to Extension group.

R3 chat is just not being advertised enough, I think. And even if 
Carl forgets to check there, be sure to let him know, so he doesn't 
forget his own tools.

BrianH: looks good. Maybe we should add platform-linux? platform-win32? 
and platform-osx? predicates to get rid of those evil magic numbers 
in cases like the above.

That won't work when we have support for a hundred platforms, which 
is more likely than you might think.

ARM, ARM, ARM :-)

Apple has two slightly incompatible ARM platforms for the iPhone 
OS alone. Even though they're both ARM, they still go Universal.

With a hundred platforms you'll have a hundred numbers. What's wrong 
with having at least a hundred predicates hiding those numbers?

If the influx of gobal words is a problem, use some universal predicates 
(os? cpu? arch?) returning symbols instead, allowing e.g. `if os? 
= 'win32 [...]`

Reported a boiled-down version of this wish as bug#1454 and submitted 
an initial implementation in chat#6785.

so did anyone start on the R3 /library  extension?  if not I can 
work on that for windows, and make it so its very easy for someone 
else to map it to linux ( as a few stubs to re-implement  ).

good news maxim, this would be highly appreciated .

I never understood why the lib development is not forced muched stronger. 

A functional interface will double the value of rebol. Unfortunatly 
my

knowledge is not sufficient to create it by myself.  therefore I 
would like 

to support this with the commitment I made before, even if this is 
not the 
first motivation for you.

so I've been looking into this a litle bit, and it seems like a portion 
of the /library extension might be a pain to implement... so far 
it seems like I will have to add in-line assembly, since I haven't 
found any C routines or macros which handle the puch/call/pop aspect 
of the program stack (not saying it doesn't exist, just that I haven't 
found any).

and since this code is totally compiler dependent... it means, the 
extension will be tailored to be compiled on one specific compiler... 
(but will be useable by others AFAICT).

I'm still looking for a definitive dll calling convention example... 
AFAIK this has to be pretty set in stone... or dlls would quickly 
be incompatible between vendors.  

Then again, its possible the DLLs contain some calling convention 
parameter...   if anyone has a bit of experience in this (and can 
point me to understandable docs) I'd welcome a few pointers (pun 
intended ;-).