World: r3wp

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.

pekr, read Ladislav's DLL document a bit, and yess, it provides usefull 
information ...  gotcha's mainly which point out a few things, not 
to forget when defining the struct! dialect and other details.

I would also be very happy if there was /library in R3. I think many 
of use really don't want to write and compile c code (especially 
for multiple platforms) unless it's really really necesarry (thats 
why we use rebol).  Max I don't work in R3 for now, but if you make 
/library I will port the libharu pdf binding to R3.

Amen :-)

and although you say library is limited is is *good enough* for many 
things.

once again - why not have best of both worlds? Carl stated, that 
Extensions might be internalised (packed into main distro). So - 
let's use default interfacing method - Extensions. And let's make 
/library extension. Should work no? If it would allow many ppl to 
wrap thing here or there, and even if it will not be so powerfull 
as full fledged extensions, why not to have it, right?

( as it was demonstrated by many comunity members with many bindings, 
and I could also make a pdf binding that is already used for serrious 
stuff, and works on linux and windows without me ever touching the 
hairy low level stuff)

OK, I am donating 100 USD to the developer, who brings /library interfacing 
method to R3. But - it shold be developed in cooperations, so that 
it is acceptable for many ppl.

... and if it will a bit more powerfull, than R2 version, even better 
(referring to Ladislav's proposed enhancements)

The thing is, if we can come up with corrent architecture. R3 plans 
on handle! type, as well as custom datatypes (not sure it is needed), 
but surely is R3 not planning to use routine! and struct! ones (IMO)

I am without money currently so I donate 50 USD but happily for same 
thing that Pekr

license - BSD or MIT - simply for devs being able to use it freely 
...

OK, so we have got 150 USD ... who's next? :-)