World: r3wp

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 ;-).

uff, sounds complicating. I think robert could have some practical 
experience or advice with that.

I just found a few good references.  so I will test some of this 
later this week.  I am pretty confident its going to work  :-)

the rebol part of things should be pretty straightforward.

I might even be able to support C++ object methods  :-)

cool maxim, I have a significant interest in connecting a powerful 
lib for 
complex financials analysis with rebol. A very dry area but

if I can support your activities in the way I have mentioned before, 
please 
let me know.

maxim the thing you are looking for is known as ABI, application 
binary interface

basically the ABI specifies (among other things) the calling conventions

and yes, that's extremely platform-dependent stuff

for windows, the calling conventions used by the OS seem to be pretty 
standardized and simple.  which is nice.  So far it seems to be a 
bit more sprawled for linux.


first release of the /library extension will be 32 bit only, but 
when we have a 64 bit REBOL it will be pretty easy to adapt... in 
fact, MS/intel did their homework for 64bit, it seems, and there 
is only ONE calling convention for that platform.

afaik microsoft has different calling conventions for x86 and x64

and iirc they have at least 3 support cconvs anyway (cdecl, stdcall, 
fastcall; maybe more)

yep, the x64 is better in fact.  x86 has three official conventions, 
some on the stack, some using registers, and different cleanup.  
 the x64 has only one and is based on __fastcall