World: r3wp

It will me (me at least) to make things concrete. Put together your 
versions and we can all compare and discuss A versus B.

http://en.wikipedia.org/wiki/Delimiter


I'm open to better words, but INTERSPERSE implies an element of randomness.

It will me
 == "it will help me"

(I need help)

Oy. You get what I mean...I hope. Time to sleep.

wouldn't DELIMIT/ENLIMIT make sense? We have already en/decloak, 
de/encode, de/enbase, en/deline ....

Hm, good suggestion

delimit:  set, mark, or draw the boundaries of something 

ENLIMIT doesn't make sense to me.

Agreed, but neither do REBOL words such as enbase and enline

Agreed, so we shouldn't emulate them. :-)

Short update, we received a R3 Core version for OSX / Linux with 
the WAIT bug (consuming 100% CPU time) fixed. I still need to give 
it a try but I expect it to work. With this we now can use R3 on 
the non-GUI server side with our event driven BEEP based communication 
layer.

This is great in the sense that this will make it possible to use 
R3 for all kind of server side stuff.

Great Robert ! Don't hesitate to communicate. That what was missing 
to Carl last months...

Robert: could you explain shortly what is "event driven BEEP based 
communication layer" please? I'm just curious.

BEER 3?

yes, BEEP is based on BEER.

I thought the other way around :-)

I may have the acronyms confused but on the other hand, I'm from 
CZ. There's whole republic based on BEER ;-)

:-)

BEER was / is a Rebol implementation of BEEP (the protocol). Our 
communication layer is a C based multi-threaded BEEP implementation 
that we make available to R3 as an extension.

As it's multi-threaded it works via callbacks with R3. For this we 
need a working WAIT on the Rebol side since it WAITs until something 
happend, that is signaled via a callback. Than the Rebol side can 
handle the request and send an answer via the C level.

Robert - nice, thanks for update. btw - what type of application 
you are using it for? IIRC, BEEP(R) is high performanace solution 
(although I found it quite difficult to handle/utilise).

We use / will use it for all applications that need to communicate 
between a client, server or peers. It's high-performance and pretty 
simple to use. Just send a message of any size :-)

Could be used to get Altme faster :-) (although I think that the 
throughput is not the problem, but message store is).

there's an extension for that too :-)

Hmm, SQLite? We also have ODBC one, although only for Windows ....

When I call a callback from C to R3 can I return a result from R3 
to C from the R3 callback handler?

I understand it in that a SYNC callback can return something to the 
C side.

And for ASYNC case I somehow can use RXICBI.result to return something. 
But there is not much doc how to use it. Any exmaples out there?

On the DELIMIT func name topic, my original suggestion, long ago, 
was to add /SKIP to INSERT, but that never went anywhere. What is 
the current feeling toward that (knowing that getting it added might 
be an obstacle).

I generally like /skip. Just recently I used find/skip - very usefull, 
as it treats series as a set of records.

It's currently associated with fixed length records. I'm not sure 
that's flexible enough for DELIMIT

Interesting... Carl wants R3 to run on DirectFB.

where?

presumably for the project he's working on

That makes sense. It's the only Linux video system that's not incredibly 
bloated. It's in Syllable Server and they claim it's in WebOS

I was planning to port R3 to it until it all went poof

+1 for DirectFB. although it required callbacks, thats why i had 
hard time to interface it with gforth many years ago.

It's a low level subsystem. But it's written in C, so it shouldn't 
be too hard

Is Carl trying to run R3 on some embedded system ?

I think he wants to do that.

a TV probably

mm.... close :-)

I thought he would blog about it, but I guess he forgot.

Trying to get back a result from an async callback to Rebol. This 
is the code I use:

	int cb_error = RL_CALLBACK(cbi);

	// check error
	if(cb_error==0){
		printf("to_rebol_processor: R3 callback failed");
		return false;
 	}

	// let's access the result from the callback (string! for now)
	char *callback_result;
	RL_GET_STRING(cbi->result.series, 0, (void**)&callback_result);


The problem is that I get back a (null) pointer for callback_result 
and not the string.

Any idea? The rebol call just returns a fixed a string at the end 
of the callback function.

Ok, as usal I just need to post my problem to solve it :-) I did 
return the string! from a wrong place. Works.

If I use an async callback from C to R3 and want to access the result 
from the Rebol callback on the C side, how do I find out, if the 
async-callback has been executed by R3?


If not, I think I need some kind of active waiting / polling on the 
C side until the callback was executed.

I think the events system supports that

This works: if (GET_FLAG(cbi->flags, RXC_DONE)) {

reply to the statement of past month "No It's not in my imagination 
that rebol is a financial faillure. R3 isn't sold so how can it bring 
money ? r2 is less sold than 10 years ago it's a matter of fact...Last 
point Carl had no remorse to take another job and disapear without 
announcing it publically... This is just basic respect  you say goodbye 
 when you leave ..."