World: r3wp

Sessions are closed for tofay, ihe's doing that on purpose to make 
you go away ;-)

That is some nice video production...

today

hey, I just eat too, so carefull with the camera :-)

where is the video at?

Bye everyone.....We'll be back tomorrow.

not joking ?

Ok, nice work everyone.

going out to drink? record that too

http://ead.ephe.sorbonne.fr/dess-capture.sdp-- but stopped for 
today it seems.

hmm, it is a pity ... wanted to hear about embedding Rebol ....

so no recorded sessions, just live

there will be recordings posted later on, afaik

mchean, there seems to be two cameras

Well done....thanks to Sahores Conseil, again.

yes, take us to the party :-) I will connect via Skype, so we can 
virtually drink all together :-)

i have a few minutes of recordings that i'l post to youtube later 
on too.

hmm, good tip for skype-like rebol 3 based tool :-)

Gabriele, any answer on the transparent events question ?

Sorry, was there any timeline on when we get our grubby little hands 
on R3?

Thanks to all who made the feed available!

cool thanks - wish i was in paris

End of June or a little later Brian.

ply carl with drinks and see what you can learn for us

Gregg;  Thanks.  Pacing starts now....  :)

anton, not directly, if i understand what you mean by that. i guess 
that will be in the open source part, but i'm not 100% sure.

it could be something for 3.x with x > 0

I'll bring it up again when I actually have seen R3's View system.

:)

will there be live R3 demo? ;-)

something like tryint to spawn 1000 tasks from loop in console?

ah, I forgot those are threads .... well, I suggest a refinement 
for make task. I want to choose for the task, or a thread, and task 
to be interconnected via some kind of IPC, not like launch ...

IIRC, Carl said that each new task! will cost around 10Kb of memory

that was not my question :-) The thing is, that when you launch 100 
thread for one process, you get just 1 time for your process, which 
you will divide to those 100 REBOL tasks = threads internally.

I wanted to know, if I can choose between tasks and threads

in R3, tasks are threads

imagine fast-cgi scenario, where you can choose how many instances 
of interpreter will run, and each can handle some things.

do you think it is sufficient solution then? In cheyenne, tasks are 
tasks ...

I can imagine launching e.g. 5 httpd tasks (rebol processes) each 
handling e.g. 100 connections, where 1 connection = 1 rebol task 
= 1 OS thread ...

In Cheyenne, "tasks" are processes

if it can't be scaled that way, it is imo insufficient ...

R3 will help a lot in building a much better support for CGI and 
RSP in Cheyenne.

imo Carl took the easier part - used OS threads, as those can share 
data. In the case of using processes, he would have to come with 
some IPC mechanism ... That is why I asked if 'launch is still there 
....

No, that's not the way Cheyenne works. All static HTTP requests are 
handled by only 1 process, the Cheyenne process. The "helper" tasks 
are only used to handle CGI or RSP scripts.

part=path

Sure, but do you think that e.g. 500 connections, handled by 1 rebol 
process running 500 threads will be better performer than 5 rebol 
processes handling each 100 threads?

imo those 5 separate processes get more time from OS ...

Doc;  Cheyenne is proving itself pretty worthy so far here at peoplecards.ca 
  Thanks.
Not delved too deep, but runs nice and smooth.

pekr, that depends on your os :)

Yes because context switching between processes is much more expensive 
than for threads