World: r3wp

Robert, it can do both sync and async. But no callbacks, async is 
done using a WAIT-style (or select/epoll-style, if you prefer) approach, 
using zmq-poll.

Just to be sure I understand: 0MQ makes async call however it does 
it, and between 0MQ and Rebol the async is that I have to poll from 
Rebol side to check if the call is already done?

0MQ binding.. that is awesome! Does/will this work for R2 also maybe? 
:)

And big kudos for making the Redis library!

Robert: you have two primitives send & recv. Both _block_ per default: 
send until there it manages to enqueue the message in an internal 
buffer, recv until it fully read a message. You call both functions 
with a NOBLOCK flag, in which case they won't block but return immediately, 
with an EAGAIN status code in case they did not manage to write/read 
anything. Finally, you also have a poll primitive, to which you pass 
a list of sockets you are interested in and an (optional) timeout. 
Poll returns you a list of sockets which are "active", i.e. which 
can be safely read from (or written to) without blocking.

ddharing: The 200kmsgs/sec results are from a run on Linux.

Very cool Andreas! Can't wait to play with the new examples.

Andreas - let us know when you port LNS to run over zeromq :)

Great work, Jocko! Any R3GUI problems or bugs you want us to fix? 
:)

Why not leave panel and hpanel as synonyms, and group/hgroup ?

Moving to REBOL3 GUI...

Thanks to the RMA team for their progress posts and updates.

Very cool script Massimiliano!

I clicked on the "Draw" button for the plotterdemo and nothing happens 
??

MaxV: remind me a script I made 8 years ago :
d http://membres.lycos.fr/didec/rebsite/whoswho/whoswho.r

do http://membres.lycos.fr/didec/rebsite/whoswho/whoswho.r

Didier.... Very nice.

Kaj, when cloning your fossil repository:
fossil: *** time skew *** server is fast by 13.1 seconds

Odd, it doesn't warn me if the skew is within a few minutes or so. 
Anyway, it seem to be just a warning, and I wouldn't worry about 
13 seconds

You might want to fix the system time on this machine.

13 Seconds? I can live with that

13 seconds today, half a minute next month, ...

NTP not an option?

Sure, and Fossil will nicely warn me when it gets significant, and 
then I'll adjust it

NTP is on the roadmap for this server, but with low priority

Does Fossil issue a warning when you update?

yes

Strange, not for me, and the time of my workstation is routinely 
off

What system are you on?

Why would that matter?

Because I can't replicate it

My systems are properly time-synced.

Various Linuxes, fossil 047e06193b on all of them, all of them synced.

Mine aren't, so that must be the solution :-)

The esperconsultancy httpd is ~14 seconds off.

That's much better than I expected :-)

What's the date of your Fossil version?

This is fossil version [047e06193b] 2011-04-13 12:05:18 UTC.

I'm on the previous version of a month before, so maybe that makes 
a difference

Not really.

You're reporting a difference, aren't you?

2011-03-16 reports the same warning.

The difference is most likely that my systems have a synced time, 
whereas your workstation has not.

Yes, that's what I suggested

Exactly. The fossil version doesn't matter much.

So, I can't replicate your problem, and it doesn't prevent Fossil 
from functioning, does it?

You can easily replicate my problem: sync your system time properly.

Why would I?

It does not, but it'll give everyone with a synced time a warning 
on each and every clone/pull.

To replicate the problem. Of course, if you don't want to, that's 
fine.