World: r3wp

when I said "a bit in the integer" I meant in the integer's internal 
datatype... but a quantity! type would be even better.

If you want user-defined datatypes, they're planned. Or you can just 
fake them using techniques similar to those in R2/Forward.

yeah... but quantity! should be a default type... its just such a 
basic part of programming.

returning an errror whenever math operations would make it negative.

Its a complicated thing to manage manually.  I know how negative 
values work... but its a REAL pain to work around it.

anyhow.  I wonder, can anyone tell me if its easy to load dll and 
map functions dynamically on LINUX?

(*.so)

Possible, yes. Easy, that's up to you to decide.

on windows its a simple function call,   does it require to have 
an extra package installed, or it part of the basic kernel?

There are simple APIs, though they might be different depending on 
which object format the distribution uses. ELF is common.

That's ok, its up to platform distros to accomodate.

I recall something about "dynld" being the key word to look for.

I can make a simple /library like dll loader for windows if anyone 
really needs it.    I won't put time on this unless there is a real 
need, but if you need it, just speak up, its fairly easy for me to 
do.


a simple struct dialect would take a few hours to iron-out tops. 
 it would be much more flexible than the struct! datatype for sure.

I can make a simple /library like dll loader for windows if anyone 
really needs it.    I won't put time on this unless there is a real 
need, but if you need it, just speak up, its fairly easy for me to 
do.


a simple struct dialect would take a few hours to iron-out tops. 
 it would be much more flexible than the struct! datatype for sure.

Maxim: loading and using shared libs on linux is rather trivial. 
dlopen(3) and dlsym(3) are what you need

they are part of POSIX, and you'll have to link against the dl library

Maxim, here are the Cheyenne stuffs that use /library http://code.google.com/p/cheyenne-server/source/browse/#svn/trunk/Cheyenne/misc
if you come up with something that would make -1 on requirements 
to port it to R3 8-)

Max - any interesting info for you in following proposals? http://www.rebol.net/wiki/DLL_Interface

I think that some users and especially novices might still welcome 
a bit improved /library interface to the full fledged Extension possibilities 
...

Maxim, rebdev message #6257 points to a patch of mine along with 
other needed fixes for the hostkit to enable R3 extensions to work 
on Linux.

thanks everyone.

pekr... looked at it quickly. not sure, it looks most like a resume 
of potential approaches.

can anyone confirm that debian is working/ported under R3?

Max: "on windows its a simple function call" Could you tell us which 
one? I don't remember seeing such thing in win32...but I didn't looked 
at it since a long time.

debian is working fine, yes

doc, i guess maxim is referring to LoadLibrary and GetProcAddress 
in win32

Then, that's not /Library.

GetProcAddress uses static argument passing.

what do you mean by '"static argument passing."

/Library is tricky to implement, it requires constructing a C function 
call dynamically (using so-called trampoline functions) unrolling 
arguments in right format and order on the stack, then calling the 
C function, then retrieving result from stack.

AFAIR.

yes, but here, we can do it in C instead.

we can implement that ourself in the extension.

I was talking about the C part.

the extension would create a stub in REBOL which calls the C created 
function, just like /library does.

Using command! type?

how I see it, that is what /library does anyways.   and when you 
look at the host code includes, a lot of it is dynamically created 
vector lists.    so I bet the host  is loosely based on /library 
in fact.  :-)

yep.

So the hard part is already done.

hmm, i don't think so

to get something like /library in R3, you'll either need to write 
some platform specific code or use something like dyncall or libffi

still a complex system of registering functions, converting arguments 
and stuff, but for simple first tests, it can be done.

and we can expand as we go.

I think the pointers stuff is the most complex, then again, I've 
been surprised by REBOL  more times than I can remember.

maybe, I could use the parser I have in Sea to use actuall C code 
as the argument definitions :-)


this would mean, no convertion to a rebol dialect by the programmer... 
it would all be handled by the extension  :-)

so you'd say:

define "mystruct {int index, int count}
myfunc: declare "libname.myfunc (int data, struct *mystruct)"
myfunc 12 1024

oops!

myfunc 1000 [12 1024]

or even easier  ;-)

include cstub.h

myfunc 1000 [12 1024]

oops again...

include %cstub.h

note, I've got the whole C language mapped into PARSE ... its just 
the emitter which is giving me headaches... 

because of REBOL's backtracking, you may end-up declaring/defining 
things several times, until the right match is found.

so I'm in the process of rewriting the rules differently which is 
quite complex ATM.