r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 /library] An extension adding support for dynamic library linking (library.rx)

TomBon
10-Feb-2010
[46]
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!)
Robert
11-Feb-2010
[47x2]
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.
BrianH
11-Feb-2010
[49]
Robert, we can do that already. This group is discussing a project 
that is taking another approach, though is built on R3 extensions.
Andreas
12-Feb-2010
[50]
A quick note of success: I've hooked up dyncall as extension to a 
properly linked hostkit
Maxim
12-Feb-2010
[51x2]
@ 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.
Andreas
12-Feb-2010
[53x3]
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
Maxim
12-Feb-2010
[56x3]
@ 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
Andreas
12-Feb-2010
[59x3]
Nope, it's a very nice library
_and_ it's quite small as well
no changes to the hostkit necessary
Maxim
12-Feb-2010
[62]
I'll be using the argVM directly, its easier to setup within a parsed 
spec.
Andreas
12-Feb-2010
[63x3]
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
Maxim
12-Feb-2010
[66]
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.
Andreas
12-Feb-2010
[67x4]
sure
i'll compile this thang for windows somewhen early next week
should work as-is
so, where do i claim part of the bounty :) ?
Maxim
12-Feb-2010
[71x3]
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 .
Andreas
12-Feb-2010
[74]
I've put up my current code for the dyncall extension at: http://github.com/earl/rebol3/blob/master/extensions/dyncall.c
Maxim
12-Feb-2010
[75]
cool thanks, will give it a look.
Carl
13-Feb-2010
[76]
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?
Maxim
13-Feb-2010
[77x2]
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.
Carl
13-Feb-2010
[79x8]
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.
Maxim
13-Feb-2010
[87]
thanks for your feedback.
Carl
13-Feb-2010
[88]
I'm sure I'll have more to say... multitasking right now.  Finally 
got R3 chat moved.
TomBon
25-Feb-2010
[89]
hi maxim, do you have some news about the status of /library ?
Maxim
25-Feb-2010
[90x2]
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.
TomBon
25-Feb-2010
[92]
great, thx for the info.
Graham
5-Apr-2010
[93]
was /library ever finished?  Or did it turn out to be hard?
Maxim
5-Apr-2010
[94x2:last]
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  :-)