World: r3wp

I think the point is being missed. I'm not looking for an error, 
when an empty block is scanned, when the parse expression is being 
built. I would of course want to modify my parse rules as I see fit. 
It is *right during parse time*, that I think there should be some 
kind of indicator that, we've hit a road block:

1. We're not moving
2. We're not processing any rules

3. I'll just do this 50 billion times, until my user gets tired of 
it.

Parsing, moreso than regular programming, is something you need at 
least a basic understanding of to do properly. That means learning 
stuff :(

That indicator needs to be resolved at programming/testing/debgging 
time. And you can use SECURE 'eval at runtime if all that fails.

(once that works)

The SECURE bit is only acceptable, if it throws an error rather than 
quits.

SECURE throw

That works already. It's only secure ask that doesn't.

doesn't seem to work for forever []

I meant the throw action of the evals (or is it eval ?) constraint.

I'm not as familiar with SECURE in R3 :(

The syntax, I mean. I'm familiar with its limits.

it seems that you can't escape a forever [] either. oh, so useful. 
:-)

You can't escape while [true] [...] either. What's your point?

works perfectly fine in R2.

well, it could be a console problem.

And in R3 the same, except you need to engage the keyboard handler 
before it reads. You can escape forever [prin ""].

It's a leftover DOS thing :(

I see. Ignore the "oh, so useful" bit, then. :-)

but: Why then can a hanging parse not be escaped in R2?

It's a bug. R2 has a lot of those.

If that is fixed in the final R3 console, then all is forgiven. I 
assumed that it would be unescapable in R3 as well.

No, that bg was fixed in R3. Every once in a while PARSE polls keyboard 
input looking for ^C.

Is it likely that we'll ever be able to parse a map!

parse a map!? You mean map! instead of block!?

BrianH R3 is open source but not open access.... hihihihihihi

My point is if you want dianamic particiapation on enhancements in 
rebol3 anyone should be able to access the  whole code as "reader" 
at least. I mean for example i want to bring a sql-protocol like 
enhancement but able to be used in the inner most layer of  rebol 
VM ...  if i can read the source code of the whole WM that allows 
me to get a better understanding on how the layers are made and how 
to do my intgration then I can come with my proposal and "offer it" 
to RT rt keeps the final word on new things integration based on 
community work . RT so remains the controler and the single diffusion 
source of retail R3 VM ...

shadwolf - nonsense and excuse.

You can implement SQL protocol with the knowledge of REBOL level 
stuff, plus e.g. extensions. For mySQL (socket based), you don't 
even need extensions. The only thing I can see is missing, is good 
enough docs ...

Have you EVER looked into mySQL, postgress or SQLite protocol sources? 
Becuase I did, I even helped to fix them. There is no single bit 
of REBOL VM, which would help me to understand or fix the protocol. 
Hence - I can see your post as typical pro-open-source rant :-)

But, in the end, I just don't know - if it really would make you 
happier, maybe RT should consider at least SDK level read-only licence 
of REBOL :-)

pekr i was one of the first in seeing them :P

and they are made that way because at that time rebol VM  was closed 
and obdc:// layer wasn't a default "open" solution...

Just answer to yourself - if you would get those sources right now 
- would it somehow magically make you more active in rebol scene?

pekr why using net sockets when you have even faster better ways 
to access the data in you base

with mySQL? ok, here we go - tell me :-)

Pekr the difference is that doing a script passing commands through 
net sockets and dialect translation isn't the fastest way ... but 
it's the easier to implement and even so when you don't have access 
to the direct content of the "black box"

What's missing is a REBOL storage mechanism like RIF which would 
enable developers to layer an access API (such as SQL) on top.

I took SQL things as an example because Carl was rubbing his head 
on a the wall trying to figure out what "SQL  like language" was 
the most suited to integer in the VM . But yes my be i understoud 
it the wrong way...  thing is SQL server are out of the box things 
and it would be better imho to keep them as external script doing 
the way we done them until now. I'm not sure we would benefit integrated 
them into the "black box" (R3 VM) if we then don't have the means 
to follow the product update...  If that's to produce a VM able to 
talk to a precise SQL server version under spécific circontancies 
I don't see that as a gain ...  AT least the scripted way is easy 
to maintain and run the same way under most circonstancies.

Shadwolf - I think that parsing SQL commands and results over sockets 
is not the most intensive and time consuming thing in DB area. The 
most of the work is done by the SQL engine itself ;-)

Ashley - I wonder what will happen to RIF ... no words on it, so 
imo it will not be done for 3.0, maybe 3.1

pekr yeah but when you computer is already filled with HTTP request 
adding more "SQL requests" slow downs your HTTP or at least that's 
the way i see it and that maybe too why all the database builders 
created another entry point called odbc

r3.0  will be only core right ?

Shadwolf - I am not dismissing opensourcing REBOL. I just try to 
point out, that open-sourcing it now would not bring us any significant 
advantage. It would not bring us hundreds of coders suddenly, being 
able to add good and quality code, so that Carl could accept it. 
I am for finishing Beta plan = finishing Core to the level of satisfaction 
and THEN releasing the Host code = everything except the interpreter. 
Interpreter code can be released later ...

pekr ... who open source a software in alpha stage ? (a part me but 
i'm special  ^^ )

3.0 beta? Dunno. There will be View in it, but not sure it will be 
finished. I expect it being Core release. But -look at beta plan 
here:

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

Carl even agreed to adapt list, to make it wikified, so that we could 
update it for the final beta list ...

cool so when VID 3 work starts again before or after new year's eve 
?

I think before ...

but we can't be sure. R3 progress in last year is good enough, at 
least for me. I am satisfied. If you will ask folks here, we would 
have some trouble to agree, upon what should be next. I like VID3, 
so I would like if View evolved a bit, but many others might prefer 
core stuff as tasking for e.g.

yeah with often ralpha release at least we have time to test and 
find most of the bugs and that makes the wrok more dynamic... In 
comparasion of the way the rebol implementation was done and how 
it's done now I from far prefere the actual way and it's getting 
our small community tigher to Carl ...

Shadwolf, Carl wasn't looking for a "SQL like language" to embed 
in REBOL, he was looking at projects like SQLite to see if he could 
extract their table engine and use it directly without using SQL 
at all. This was for RIF (REBOL Indexed Files).

who open source a software in alpha stage

 - Most open source projects do this. And most open source projects 
 never get out of the alpha phase, because open sourcing a project 
 doesn't get it done faster - most people don't contribute, period.