World: r3wp

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 ..."

seeing the glass of water half empty or half full don't changes the 
core truth of it's nature ... the glass only contains half of it 
of the liquid it could contain as maximum :).

I'm tired  of being over optimistic and supportive and see the poor 
results that brings ...

you take carl's abandon as you want so let me free to interprete 
it as I want too and on my own point of view what he did is a slap 
in our face ...

Carl could not do anything worst to rebol ... and neither the less 
it was a logical conclusion of a pharaonic oneman driven project...

expressing my opinion is all Carl eventually allowed us when it comes 
to direct interaction to rebol/core  all what isn't rebol/core deeply 
related was cut short by carl ...

now can we ask why and hope to have a frantic reply on that matter 
or  do we have to play happy face   forever ?

by the way banning me from here will just have as effect to had my 
name to the over long long list of people that don't express anything 
anymore for rebol ...