World: r3wp

But I think there's a bigger problem.

:)

We need to find a way to unify various efforts related to REBOL. 
 For example...

BrianH is your second brain and RT should put him under the contract 
:-)

If many users want SQLite inside REBOL, can *get them* to help make 
that happen.

BrianH and I work together well, but the two of us alone are not 
enough!

Why? It can be done via Extensions, or via command line (if the damned 
thing would work ;-)

We need people like Doc or Ashley helping to make, for example, a 
DB better integrated.

Only to say i don't see the interest to have 'remove based on an 
index method.

Because doing that:
parse "..." [ here:  "b"  remove here ]

Is nothing less than doing like currently:
parse "..." [here: "b" (remove here)]

I don't see any gain. 
Oh sorry, we don't have the ( )
Victory !!!!

Steeve... it's something to think about, no?

Such decisions are the most difficult to make.

In one blog thread I pretty much outlined, what really is important 
for ppl. Features at least on pair with R2. Some of them more than 
others:


- CGI - not working under Windows (unicode problem with print -the 
header has to be in ASCII?)
- fixed 'call
- networking (BrianH plans to revamp Schemes)

- console (well, maybe we can live with the current one for a while)


- Some guys are screaming for first words of concurrency. E.g. Doc 
could start with port of Cheyenne - premium REBOL product. Not so 
with missing protocols an concurrency not in place ...

The problem is that up to now, the model for PARSE is: match then 
action.

The victory would be in speed and the fact that your replacement 
code was missing a :here, but your suggestion is nicer I suppose.

I'm OK either way.

The more basic problem is: we cannot do both. So, we must decide. 
 I kind of like Steeve's suggestion, because the old method is always 
a fallback for people who need more advanced methods.

Let's not steal strategic discussion to parse arguments here, no? 
Blog is enough ...

In other words, we are inlining REMOVE to make it simpler for many 
users.

I would miss the integer offsets though.

My summary for what defines the beta is in my 3 posts here: http://www.rebol.com/cgi-bin/blog.r?view=0424#comments
... and even Concurrency is missing ...

Pekr... yes, end of note.

Pekr, let me take each of these points, one at a time....

1. "Missing protocols" -- for me, this simply means, some users need 
to add them, because I'm not going to have the time.  Certainly, 
I can help with deep issues if they come up.

I plan to make the scheme dialect a little nicer to help with that.

2. "Networking/Schemes" - I spent a lot of time on the Scheme model, 
to purify and simplify it compared to R2.  So, I'm not sure what 
BrianH is proposing yet.

Ah, ok... that is good.

Carl - it would be nice to have Uniserve like multiplexing engine 
built directly into language, but I am not sure it would not be too 
much. There is also the other layer we don't know the future of, 
called Services ...

Just a tweak of the dialect. The implementation is good.

Pekr, R3 ports are totally multiplexed.

The R3 model is far superior to R2.

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?