World: r3wp

re GUI - I proposed to set-up wiki page similar to Parse proposal. 
We have few request for View kernel itself, as well for VID.

I think, that everybody is waiting for your go. I think that most 
ppl here prefer you working on Core. Most of devs here will prefer 
complete Core, along with parse, extensions, host code released, 
networking protocols, cgi, console and especially some FIRST words 
on concurrency ...

it is easy to state - we are in beta, while missing on some features. 
As for BrianH, I think he wants to move to Scheme dialect revision, 
once parse is done.

Actually - ppl still think, that before the host code is released 
(and hence host using Extension api (I think)), we are still dependant 
on you doing all the work ....

The question is, if it makes sense to jump to GUI anytime soon, without 
Core stuff not being finished to beta status ...

I think there are a few ways to slice the pie.  Here are my main 
motivations:

Before you move on though, check CureCode - there's 4 new parse bugs 
:(

BrianH: parse is still not done, no? To/thru multiple is not in there 
yet :-)

First, it's easier to get a Core completed, so that those of us (and 
I include myself) can start using R3 for our servers and other such 
tasks.

Of course, there is also group interested in GUI - shadwolf, Steeve, 
me, maybe Henrik ....

It is for string parseing

Carl - I agree on that - Core first ...

I agree

So, we must then look at it: what critical things are missing from 
Core?  And...

How can we make it possible for other developers to help with what 
is missing?

there is - projects-plan.html. We should vote on features, update 
the projects-plan, and go for it.

Let me give an example...

Noone can help, if Host is not released, and host is not released, 
as it does not use Extensions. Extensions might require few requested 
features, etc. I think those things are obvious ...

Device extensions - that will makee it possible to start the database 
debate.

*Exactly*

BrianH stole my words.

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.