World: r3wp

Carl - protocols/networking is the stuff community can work on. I 
suggest you concentrate on low-level stuff:

- finish parse changes

- back to Extensions and closer to Host interface, prepare for release 
and first porting efforts

- please let's at least outline, what the concurrency model is going 
to be. Without it, Doc will not waste his time trying to port Cheyenne 
to R3, if R3 concurrency model is not at least defined?

So, the question would be: what higher level models, such as Uniserve, 
can be implemented on top of R3 model?

I've already stated the R3 concurrency model. But, it may have been 
lost in the web.

OK, so let's forget the higher level models right now - there can 
be many over time :-) But multiplexing is one aproach, whereas combining 
it with concurrency is the other thing. So far Cheyenne spawns processes. 
We want R3 to be distributed computing king, no? :-)

ah, yes, task! using threads one?

So: task! is a thread, undefined sharing model, undefined intertask 
comm model. That's what we have so far.

http://ulf.wiger.net/weblog/2008/02/06/what-is-erlang-style-concurrency/

Correct: the model is: threaded CPU, shared memory, shared symbol 
space, shared system function space, separate evaluation stacks, 
separate user contexts.

Synchronization?

Intertask comm is via Ports.

Sync is via ports.

BTW, "ports" does not need to mean "sockets"

The host level can provide a more direct mechanism for inter-task 
sync and comm.

Locking? With shared memory, mods could trounce each other.

Carl, about parse, is that a pain (in the ass)  to have access (read-only) 
to the rule stack  while parsing ?

Wow, sounds interesting. Why would you need that?

I'm not a fan of locking, but sometimes it's necessary. Otherwise, 
mods can be "cloned" for multi-task uniqueness.

to know, if we can break the parsing in any place, and continue it 
later

to have async parsing possible

Copy-on-write?

So, you want "parse continuations".

sort of... ::-)

streamed parsing? :-)

Incremental parsing.

Yes, I understand. That would need to be 3.1.  We do not want to 
delay 3.0.

sort of... :-)

Anyway... Pekr.... I want to note one final thing.

listening :-)

I figured out how to do PARSE on seekable ports, so that might handle 
a lot of the problems.

We need a way to make the "todo list" accessible and we need users 
to help us maintain it.

An example is this...

Carl, you mentioned a while ago that you urged us to work on the 
docs. Does this mean we can fill out the function reference with 
examples without them being overwritten?

Maxim needs some changes for extensions... and has posted them somewhere, 
but I'm not sure where.

Chat ... it was about callbacks IIRC and some ideas ...

Henrik, yes... please!  Every edit is saved.

In R3 chat, plls a referenced web address.

#5045 in Chat ...

But, we can also add locking to the docs... if we want.

Pekr, for some things, I need more of a todo list rather than message 
thread.

I think it is ok to post it in CureCode, since that's easy to track.

Speaking of which, add finishing the PROTECT changes to the list. 
All details in CureCode.

Even if I've said, "don't post it there"... I now say, better there 
than nowhere.

so why just not to chat upon some areas and fill in already good 
project-plan?

Pekr, yes good.

So, when and where?

Carl - R3 Chat is not nowhere, no? It was created to be a developer's 
tool too. But - we can make projects-plan.html a wiki page, so we 
can edit it and fill it with detail?

http://www.rebol.com/r3/project-plans.html

Using the docs wiki, not DocBase.

(I am quite sure that BrianH has some kind of microwave beam and 
reads my thoughts.)

:-)