[!REBOL3 /library] An extension adding support for dynamic library linking (library.rx)
and to complete it before I promise to stop bothering with this again, a blocking user interface in 1985 was acceptable but today? (task! please!)
Transforming the C side from R2 to R3 is pretty simple. I have enhanced my "in-house" DLL with a R3 interface in a couple of hours. So, now it can be used from R2 and R3. Same interface, some functions.
So a good way could be to generate a R3 C based extension wrapper around the R2 used function and use the R3 extension interface. It's much better and simpler to use.
Robert, we can do that already. This group is discussing a project that is taking another approach, though is built on R3 extensions.
A quick note of success: I've hooked up dyncall as extension to a properly linked hostkit
@ Robert, the reason for this /library (which is an extension) is that most REBOLers do not want to mangle with compiling C stuff (most probably don't even now where to begin). and for most tasks, the speed hit isn't really noticeable.
cool, I was going to start working on that very concept this week end. I've looked at all the Dynamic function linkers and its really the best best designed one out there.
It works nicely, here's an example of how it currently looks: import %ext/dyncall.so dyncall %libm.so 'cdefault "sqrt" "d)d" [64.0] ; == 8.0
dyncall %libm.so 'cdefault "pow" "dd)d" [2.0 8.0] ; == 256.0
Currently I only handle decimals and ints, both as argument and return type
@ BrianH, if you looked at my /library API example, you see it would be pretty easy to wrap the call into LOAD/library ... it would just be a question of supporting the refinement and calling the extension's function... but it would have to check for the extension's availability.
Andreas, its nice to know that it works.
:-) was it hard to setup? it looked pretty easy when I looked at the dyncall docs (and source code) earlier this week
Nope, it's a very nice library
_and_ it's quite small as well
no changes to the hostkit necessary
I'll be using the argVM directly, its easier to setup within a parsed spec.
so do I
my dyncall.so extension which has all the necessary dyncall parts statically linked into it is currently only 22K
for comparison: libr3.so is 405K, the hostkit binary is 31K
would you agree to share the work you've done so far? It will save me some time for sure ' :-/ and I'll be working on a Win version, so its going to be a parrallel effort in any case.
i'll compile this thang for windows somewhen early next week
should work as-is
so, where do i claim part of the bounty :) ?
ehehe... the dyncall is the easy part hehe... ;-)
if you can send me the code you have so far, I'll be working on it this very week-end, on windows and that means starting to build the /library API itself, including struct support and stub function mapping and all.
my email address here is the best way to send me stuff, if you are so inclined .
I've put up my current code for the dyncall extension at: http://github.com/earl/rebol3/blob/master/extensions/dyncall.c
cool thanks, will give it a look.
Maxim asked me to take a look here... it would be good to throw the main parts of this into www.rebol.net/wiki -- because it's hard to dive into the details in an evolving discussion, do you agree?
yep... but I'm mainly interested in a quick critique of the code snippet I post above (the long post)
once I have parts of this working, I'll do a wiki post and release alphas so people can test.
Should the spec block of a lib func be similar to the spec of a normal func ?
If so, then all the help features might work ok.
I should note that there's a pending change to func specs. Namely, the use of set-words for special options.
For example, there's no way to describe the return value of a function, or trace options, or catch/throw handling.
I was planning to use set-words to do those. For example: sum: func [a [integer!] b [integer!] return: [integer!]]
This is also important to give us localized returns, because the word return here can hold the binding to the function's defined context, the necessary link to make it work.
But, I've yet to post all this up for discussion... however, you may need to think about that. I would be good to have spec blocks work over all functional values.
Just a note.
thanks for your feedback.
I'm sure I'll have more to say... multitasking right now. Finally got R3 chat moved.
hi maxim, do you have some news about the status of /library ?
got dyncall compiled on windows and working on integrating it with the extension... not done though as I'm concentrating all my dev time on finishing a contract.
should resume work on this next week.
great, thx for the info.
was /library ever finished? Or did it turn out to be hard?
as this is driven by client requirements... it was temporarilly bumped by more pressing stuff... but its still on the top of the list. it will resume when this temporary new development is working (which is also REBOL-related).
ironically, this new development is something I put on hold for years... so its a good turn of events in any case :-)