World: r3wp

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.

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

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