World: r3wp

I also want to add A LOT of comments to make the source more litterate. 
 in fact I expect the source to contain more comment bytes than code.

What file did Carl say contains the new documentation?

not aware of any.

reb-ext-lib.h seems to be it

#define RXI_SET_FIELD(a,b,c,d)      RXI->set_field(a,b,c,d)

Maxim, well, not too literate... or it gets in the way and starts 
looking like XML.

G: that's it.

its just a massive amount of comments, the reason being that I want 
this tool to be easy to maintain in the long run and or it to be 
easy to modify for people who have special needs.

things are explained everywhere so that little is left "hanging in 
the air" .  I want cause and effect to be explicit everywhere in 
the source.

you can always save/load the code to strip it  ;-)

Max - please define, WHEN are you going to be ready with your "last" 
feature, because judging upon your Glass project, which should be 
delivered months ago, we can only see a constant teasing, but nothing 
conrete being delivered ...

it should be done today.

Wow, I was gone for a few days.  Really exciting developments!

the assimilator is getting quite powerfull, we can now specify litteral 
values in the alternate command formats!


this allows C functions to be called with some of the arguments filled-in 
by default and requires one-less argument from the REBOL side of 
things.

and since we can specify as many alternate command formats as we 
want per C function, we can build a library of parameter-less rebol 
commands which call the C functions with usefull values built-in 
to the extension.

Has anyone else considered what needs to be done for intertask communications 
... are we thinking maybe something like a RPC on the Rebol side?

http://www.library.ipc.ac.nz/

Nasa's deep space one IPC library http://www.cs.cmu.edu/~IPC/

Looks like this stuff was originally designed to help various legs 
communicate with each other ...  ( multi-legged robotic landers crawling 
across alien landscapes )

Sounds like a dinosaur approach ...

I've thought about it on and off. There are a million models to choose 
from. I don't think RPC is the way to go at all though. I'm for channels 
and messages. On a larger scale, I like the tuplespace model.

I'd like a tuplespace implementation too - I've had a good experience 
using GigaSpaces Jini/JavaSpaces implementation.  Very intuitive 
(and simple in terms of API) concept.

Go for it guys

Unless someone else wants to volunteer ?

as a testament to what is now possible with the new assimilation 
engine, just look at how insanely flexible it is at allowing you 
to provide just about any interface to a command...

using this information in the C header...

// command-template: [obj [object!]] prefix: obj- suffix: 3
// command-name: rxt-iadd
// command-template: [a [integer! decimal!] b [integer!]]
// command-template: [obj [object! x y]] prefix: xy-
// command-name: plus10
// command-template: [10 [litteral!] value [integer!]]

extern int r3t_integer_add(int a, int b)


;--------------------------------------

one ends up with this command interface... all calling the same C 
function.

    rxt-module: {REBOL [
        Title: {r3-test-extension extension}
        Name: r3-test-extension
        Type: extension
        Exports: []
    ]
    rxt-obj-r3t-integer-add3: command [ obj [object!]]
    rxt-rxt-iadd: command [ a [integer! decimal!] b integer!]
    rxt-xy-rxt-iadd: command [ obj [object!]]
    rxt-plus10: command [ value integer!]

    rxt-r3t-integer-mult: command [ a [integer! decimal!] b [integer! 
    decimal!]]

;----------------------------------------


note that in this setup, auto-exports is set to false and an rxt-prefix 
was added to every command name automatically.

also note that the command templates are not required, they just 
allow you to manipulate how a C function is mapped to REBOL.  there 
are still many features to come, but right now I am working on finishing 
the last phase of assimilation which is the actuall extensigon C 
source code generation.

btw, this command  


rxt-r3t-integer-mult: command [ a [integer! decimal!] b [integer! 
decimal!]]


was automatically generated by a function without any command-template, 
later in the header file.

Max - saw your latest blog post. Hope the redesign of assimilation 
engine does not take too long :-)

the above show the first sings of its power :-)

Max, I can't see the benefit yet. What I write in the C header I 
could write directly on the Rebol side.

well, the fact that you don't have to write the command extension 
code itself in order to implement those 5 different interfaces is 
already a benefit.

But those 5 lines of Rebol are written in 5 minutes.

Adrian, I like the tuplespace model for its simplicity as well.

Maxim, typo:
litteral -> literal

oh yes.

Look here: http://www.rebol.net/wiki/External_Callbacks

thanks for that

It's a discussion page, so it's not in any way complete yet.

I know... I meant thanks for setting it up.

Carl did :)

I just added GC notes..

Graham, on IPC, I think Carl has to be involved in the initial spec. 
I've done point-to-point systems, using TCP ports, but that's not 
a general solution. I've done a tuplespace over Rugby, but it required 
polling. I wanted to revisit Uniserve to replace Rugby in that, but 
it fell off my radar.


Ultimately, I think we need a central process--the tuplespace--that 
apps communicate through. To be general, scalable, and lightweight 
while allowing us to build something like GigaSpaces on top of it 
takes more net guru skills and design effort than I have mustered.

This design-with-discussion model we've been doing lately has worked 
pretty well for modules. Perhaps it can work for callbacks and IPC 
as well. All you need is a lead designer (so it isn't design-by-committee) 
and some quality feedback.

hehe ... I just realized that Carl and I are editing the page simultaneously...

Better edit different sections.

I just added quick notes at the end.  Carl is flusing out the callback 
modes...

Oh, your GC thing should consider concurrency as well. GC won't necessarily 
be the only thing going on.

isn't Carl an author of AmigaOS, a message passing based OS? Aren't 
IPC techniques well known and defined concepts nowadays? Maybe we 
should not come-up with something completly new, just choose what 
fits our model. E.g. we have got async devices ... what about having 
IPC/messaging device?

Obviously, we would be best served by Carl as the lead designer on 
IPC and callbacks :)

If we do IPC through the port model (likely) then there will be a 
device as part of that.