World: r3wp

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? :-)

me, I am in with 100 usd

and another  100 usd if nested structs and clean pointer handling 
are included

ok, thats 250 + 100 USD, upon above defined conditions :-)

I'm in with 100USD for the os x version of /library if that is usefull 
for porting Che

that will be difficult, as we don't even have an osx hostkit right 
now :)

It's not difficult to start; that's just a matter of doing the research 
on dynamic library loading and mocking up some code. And once extensions 
(not the host kit) are available on OS X, then the code can be tweaked 
and compiled.

You can start by going through R3 chat and helping Carl with his 
difficulties with porting the host kit and extensions to OS X.

That's exactly what I did

See rebdev message #6332, from 39 days ago

Cool.

The extensions are not the problem, they will work on OSX just as 
they work on Linux.

And in rebdev message #6257 I explain how to get extensions working 
on Linux.

(45 days ago)

Good. So once we resume work on such things (we're working on bug 
fixes and tickets now) the information will be there. Thanks.

Besides that I have 10 more patches lined up, which I held back to 
not overwhelm anybody.

Um, Carl is *right now* working on integrating community patches 
into a new host kit. Don't hold back.