World: r3wp

A message about WAITing is quite appropriate ;-)

delightfully ironic that its Carl asking us about waiting  :-D

It's been quite long time, since someone worked with R3
 - certainly true, if you replace "someone" by "I, Pekr"

I suspect Pekr is referring to the R3 core development vs R3GUI ...

Ladislav: it really does not matter, how accurate is my message or 
your reply. If we want to be 100% correct, than you are of course 
right :-) My message was a general claim meaning, that even in the 
time of active R3 development, there were not many ppl using R3, 
and there was even less ppl using R3 actively under linux imo (which 
is quite logical, as for a long time R3 was primarily developed for 
Windows only). 

Is there any related ticket

 was important part of the message re possible WAIT problem underl 
 Linux. The only possibly related is http://curecode.org/rebol3/ticket.rsp?id=1861&cursor=2


So - before I download R3 for Linux, drop it to my linux server, 
and spend my time experimenting, my question could translate as - 
what should be the mentioned problem with WAIT under Linux all about?

The fix seems to be under way by Carl himself.

Good to hear that. Could someone please remind me, what was/is the 
status of hostkit repositories? IIRC, there was some experimental 
version from Carl, then IIRC some ppl established their own repos. 
Which one's the official one?

Pekr, the official hostkit sources are the one available for download 
from rebol.com (http://www.rebol.com/r3/changes.html).

The WAIT-related ticket is cc#913: http://issue.cc/r3/913

ah,I saw the ticket, but that's OSX related, no? Carl was asking 
about the Linux,but maybe those two OSes share the same WAIT symptoms, 
as can be seen in the comments ...

That ticket is for Linux as well: every platform without an event 
device is experiencing that issue. That is every platform but Win32, 
at the moment. I would have changed the ticket title already, if 
I could.

Hmm, so chances are, that Core might finally get some event/timer 
mechanism, even if used without the GUI? :-)

R3/Core for Win32 already has the foundations for such a mechanism 
(the aptly named event device).

Apropos serilization and constructs, we discussed in the "Core" group. 
Is this expected behaviour?

>> make string! #[true]       
== "true"

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