World: r3wp

Well normally fifo files are created in blocking mode, so yeah a 
write won't complete until a read occurs and a read will wait for 
a writer (by default).  I'll be honest, I've not done this from REBOL, 
but with 2.7.6 and LOAD/LIBRARY freed, we can do any libc6 calls 
that we want, so you should be able to set a non blocking mode and 
get true multiple writes and reads that will return empty if no data 
is queued.


For OpenCOBOL I implemented POSIX Message Queues; as MQ_NOTIFY will 
make a callback when the queue goes from empty to non-empty and you 
don't have to worry about spinning on a read.


If you don't mind playing with  make routine!  take a look at mq_open 
and friends (man mq_overview) it might offer more control for IPC.

thanks btiffin for such great explanation, yes I was looking at message 
queues too at first but then someone proposed pipes and they do seem 
more accessible/simple to start in a way.

Is there any article or blog post about 2.7.6 being able to load 
native libraries? I searched and couldn't find any info on this.. 
I found docs for REBOL/Command/SDK version so this would be a place 
to start experimenting probably

Janko; yep.  It's weird, docs wise, but  make routine!  is a new 
bonus layer that hasn't made it's way to the main documentation. 
 Our good Gregg is a goto guy when it comes to knowing some of the 
foibles invovled.  If you like learning by example http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=capture-screen.r
or http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=capture-screen.r
  There are other examples.

great, I love learning by example :) .. btw .. both of your links 
are the same I think

Sorry Janko;  the second was supposed to be http://www.rebol.org/view-script.r?script=sqlite3-protocol.r
  that's what I get for not reading what I'm writing.

oh, great just what I need... I was fixing/modding a sqlite binding 
in factor already

so I can compare a little , and I will probably need it also

>> a: copy []
== []
>> b: 'test
== test
>> append a :b
== [test]
>> type? first a
== word!
>> find a 'test
== [test]
>> c: ['test]
== ['test]
>> find a first c
== none

That just bothers me.

type? first ['test]
== lit-word!

Yes I know.

My point is that REBOL is not consistent.

Why can I do a find using a lit-word but not get results when using 
the lit word from a block?

find a 'test works but find a first c doesnt.

I would have to use find a to-word first c to get a match.

I think it is a bug. But we will probably see gurus trying to find 
an excuse, why sometimes you can't code in REBOL different way than 
to simply try some stuff in console ...

And - imo if RT would post some formal specification to the language, 
we could fix some gotchas and surprises, not trying to find academic 
theories, why it work certain way ...

insert as an operation does not preserve datatype. It reduces litword 
to word. Not sure there is a reason to do so ...

Yeah, that to me would be a bug.

>> append [] to-lit-word 'a
== ['a]

Yeah Henrik but that is a workaround really.

the 'a was already a lit-word to begin with.

Henrik - but - that is exactly the excuse I was talking about

why should I use to-whatever for one datatype, but not for the other 
one?

the question is probably which operation is more common.

I'd bet Carl did it that way, because it is something he does more, 
than the other way around.

hmm, but it can really lead to surprises, as Paul got - trying to 
find something by reference ....

To me it is one of the exceptions to the rule things.  With REBOL 
you gotta have all these exceptions to the rule.

I'm not defending it, just trying to come up with a theory.

... but yes, REBOL is dynamic, so it might be a problem, to have 
all cases working as expected ...

lol

because I know that Carl works alot more with cases of usage rather 
than theoretical correctness, as long as the result isn't completely 
backwards/illogical.

Well, at least I know how to get around it which is why I just mentioned 
that it "bothers me".

Now someone clever should answer, if it would have some consequences 
to not reduce lit-word upon block insertion?

But to me Henrik the append or insert should be able to look at the 
argument and see it is already a lit-word and append it as such.

I was going to write something clever about that, but I think trying 
to fit such a change in has some pretty big ramifications for how 
words are used in REBOL. :-)

anyhoo, I can't defend it, so I'll let BrianH take over.

Heh.

Well at least you didn't try to give excuses.

Thanks Henrik.

It's not the insert that changes the litword to a word, it is the 
initial evaluation of the litword. By the time insert sees it it's 
already a word.

But couldn't insert be modified to see that it is appending a lit 
word to a block and make the appropriate modification?

INSERT wasn't appending a lit-word, it was appending a word. DO converted 
the lit-word to a word, not INSERT.

In the example, I gave I showed that b was a lit-word being appended 
to a.

well at least in my understanding of it.

But I already get the idea.  That the idea is that it it is now a 
word and  not a lit-word!

No, it was an expression of the words append and a and a lit-word 
'b. DO evaluated the expression, and while doing so evaluated the 
'b to create b. Then it passed the b to the function referenced by 
the word append.

Back to this issue, I checked replace and it doesn't support replacing 
word! in a block with lit-words.

Code? A lit-word is an active value, like a function. You need to 
use get-word references if they are assigned to variables, or to-lit-word 
if they are literal in a place where they will be evaluated.