World: r3wp

*serialization*

would you expect something else? each little type conversion has 
its own idiom.

IMHO converting to string usually is meant to be used more like FORM 
than anything else.

there are some details which make the datatype conversions different 
than other forms... such as block to string.

Cyphre, my fix for the SPLIT bug is above in this thread, which prompted 
the long discussion on it.

Brian, DELIMIT means something very different to me. My DELIMIT func 
inserts delimiters.


I don't have a problem with using a 'skip keyword. As I said, the 
current behavior wasn't the original design and may be Carl's doing. 
Check with him on that.


There is a conceptual conflict between the treatment of splitting 
into parts by length and splitting by delimiter...

 -- I don't see that, but I'm biased. I'm always happy to see alternative 
 designs.

I checked a half-dozen online dictionaries to get that definition 
of DELIMIT. Perhaps you're checking different dictionaries.
The conceptual conflict:

- Dialected splitting has incompatible dialects, which makes both 
more limited than they should be.

- Splitting a block based on a delimiter of one of the types used 
by length-based splitting isn't allowed.

I think that the word for inserting delimiters the way your old DELIMIT 
function did is "intersperse", but we can do better than that.

DELIMIT sounds OK to me for inserting delimiters, with TOKENIZE probably 
its reverse

what about SIFT ?

That sounds identical to FILTER

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 ?