World: r3wp

Pavel, I pulled out my old QNX manual and it lists Messages, Ports, 
and Exeptions as their three IPC mechanisms. Messages can be sent 
on "virtual circuits" which have a node ID in addition to the task 
ID to send to; no implementation details given. Ports were like named 
pipes it seems, with 16 being numbered and reserved by the OS.

Gregg thx for info

Do you really need a daemon if you're just doing IPC on the one PC?

http://www.rebol.net/r3blogs/0328.html


Missed this one ...  "So, what I need to know from you is what functions 
published in the r3lib API should also be provided in the extension 
API. No, you cannot have them all, because many are only relevant 
to the host bootstrap itself."

Graham, you don't for a single machine, but you would need a memory 
mapped file, named pipe, or something else. The question is whether 
you want an IPC system that is limited to the local machine.

So, there is the possibility then of two ipc mechanisms .. one for 
local ipc, and for one distributed ipc ...

Graham, one advantage of using a daemon approach to inter-process 
communication is that it is very easy to upgrade an application from 
single-user, single-machine to multi-user, multi-machine.

Is Carl prepared to do this though?

http://msdn.microsoft.com/en-us/library/aa365574(VS.85).aspx

I don't know Carl's thoughts. I also don't know how ARexx ports worked 
on the Amiga. They may have just been named pipes, but I don't think 
that's enough today.

If we want to pursue IPC chat, make suggestions, and get Carl involved 
(at least get some his thoughts), we should do it in a different 
group or somewhere else. Should we do it on AltME or somewhere else?

a good thing is to make a wiki open discussion about it.  collect 
ideas, wants, needs, gotchas, known tools... whatever.  when Carl 
addresses this, he will have a document to review and analyse.

Carl reacts quickly, when he has all the information in front of 
him.

Agreed, with the goal of gathering information, though I'm also a 
bit hesitant as he may have strong feelings and ideas already. 

I'm good with a wiki though. Where?

where all the others are being placed...  somewhere under here... 
http://www.rebol.net/wiki/Main_Page

for example: http://www.rebol.net/wiki/External_Callbacks

Draft IPC wiki page is up: http://www.rebol.net/wiki/IPC_-_Inter-process_communication

wow, looks like the framework for a thesis  ;-)

I have a lot of notes. :-) I tried to keep it minimal, focusing on 
a few key questions to start, with an eye on the bigger things that 
would be built on the foundation.

I added a threading section to the IPC document.

just notes and questions.  IIRC we talked about this at some point.

The most important questions are probably missing: _what_ kind of 
"processes" are we talking about. Is it about communication between 
R3 tasks (within a single process), about multiple R3 processes on 
the same machine, R3 processes across a LAN? WAN? Heterogenous processes?

The daemon question is the primer for both threading and processes. 
The "what are we talking to?" question. I'll add that to the wiki.

I also added a little section on implementation specifics (directly 
in the host, as extension, embedded?, etc)

all the IPC I've done with rebol where TCP socket based, some per 
connection, others with persistent and fault-detection wrappers similar 
to ip packets.

Its actually quite fast when running on the same host.

one advantage to using TCP/ip is that users/admins have some control 
over them using standard firewall HW & software.  also, if one needs 
to he can use port 80 so messages can to through normal HTTP messaging 
routes.  This improves flexibility of the IPC, without it being a 
requirement.

One enterprise service I did used EDI formatted information and allowed 
queued message sending and receiving, with order detection and re-sending 
on time-outs or connection errors.


funny thing is that I had to throttle my REBOL app because it parsed/replied 
messages faster than the remote service could handle :-)

Has anyone tried to build a .NET DLL that can be used from Rebol? 
Is this possible? IMO it should be possible.

I dont know if we can used managed code from within an un-managed 
app.

That's possible.

until host-kit-a100, the extensions that I produced worked properly. 
With a102, the tests fail at a certain point (r3 found a problem 
...), even with the sample extension example produced by Carl. Any 
other experience on compatibility problems ?

I just built r3.exe from A102 and was able to load in the extensions 
I produced from A101 ...

windows or  linux ?

Windows 7

not tested with a101

Sample extension works just fine for me with (Linux) A102.

But as parts of the extension API have changed, I don't think that'll 
be the case in general.

I.e. as soon as you use any of the RXI_* functions, as almost any 
"real" extension will, you'll have to recompile against the A102 
headers

jocko, I had assumed you had recompiled them....


you must recompile them for A101 and up, many enums and offsets have 
changed, so they don't correspond anymore.

The external sample extension works partly (apart from several string 
and word functions, like t-word-map)I understand that I have to recompile, 
but  it's not so easy to find the proper headers. Furthermore, I 
am not sure that the old make-ext.r script which generates the init_block 
is still usable. It would be useful to actualize the external sample 
extension. By the way, where is the page giving the main changes 
from a101 (changes from char * to REBSER*, t-word-map etc) ? I am 
not able to find it out.

Having had a look to the extension pages of the R3 documentation, 
I see that the use of make-ext.r to generate the init_block is no 
more relevant.

The necessary headers are in src/include/: reb-c.h, reb-ext.h, and 
reb-ext-lib.h

(In the hostkit, that is.)

And I fear that some parts of the extension docs are currently outdated.

Regarding the changes, Carl's official docs are here: http://www.rebol.com/r3/changes.html

My personal summary for the extensions API:

- A100 is basically the same as the previous extensions-only API 
release (A77).

- A101 adds map_word, word_of_string, words_of_object, get_field, 
set_field

- A102 adds make_image and gc_protect, renames the constants used 
for series_info from RXI_INFO_* to RXI_SER_* and adds RXI_SER_DATA

Andreas: thanks? With A100+, it seems that we need some other headers: 
ext-types.h, reb-defs.h (also present in src/include ). However, 
although they compile, it seems that they cannot be opened under 
r3 ( access error: cannot open %xxx.dll ... reason: none). I suspect 
the absence of a given #define flag, but not easy to debug. Anyway, 
I think that it would be useful  to clarify. If anybody already succeded, 
please give us the set of files and the config used. If not, could 
somebody do the test ?

Jocko, here's an "add-mul" sample extension that works with A102: 
https://gist.github.com/bc820cc3eb301c79c1ef

Compiled with `gcc -shared -fpack-struct=4 -Isrc/include/ -o sample.so 
sample.c`.

You'll possibly want to adapt the -I, make sure it points to the 
A102 hostkit's src/include/ directory. For Win32, you'll also want 
"-o sample.dll".