World: r3wp

R3 will run as a CGI under OSX though, it doesn't yet do so on Windows.

about chat ... i always said it was hard to have a precise location 
of interresting exchanges ... but that's the same in altme...  in 
fact any discussion here or in chat when it pops out interresting 
ideas should then be resume into a temporary task list  but ... that's 
normal most of the time discussion here are mixed we don't only propose 
enhancements we try to figure out how things works then  we try to 
give how things could or should be working in order to make our lifes 
easier... It's a difficult task to keep tracks on every good idea 
passed throught altme or Chat  system...

i don't understand the "it will work as cgi ..." does it means outside 
an apache server and through a html page rebol won't work ? then 
rebol would be something like a custom php ?

REBOL3 cgi scripts don't work on Windows (under Apache or IIS) but 
do run on OSX (under Apache).

Are there any rebol based R3 web servers yet?

There's barely a client. Web server support was originally intended 
to be built in, but we'll see whether the work gets done. Openning 
the source doesn't magically provide more people to do the work. 
We need help.

Shadwolf, most of the code in R3 is open already.

Why does this take over a minute to complete?
    dt [
        parse [1] [some []]
        ]

(There is a similar time issue with R2)

I thought that was fixed...

it's the same with an empty ANY rule.

A SOME or ANY rule that does not advance is an endless loop. [some 
[]] is equivalent to [some [none]].

can this not be fixed? I can't see why one would want such a rule.

and I imagine a lot of beginners getting stuck in this.

Endless I can understand....but 90 seconds run time is something 
else :)
Perhaps Secure will handle it one day.

well, we can't either protect again someone coding 
>> forever []

This is on purpose (the "fix" was reverted). Sometimes, particularly 
when your loop contains modifiers or productions you don't want it 
to advance.

they do the mistake, one time, two times, but no 3 times.

It's a documentation problem, not a dialect problem. Parsing is only 
a beginner task to a limited extent.

I disagree on unfixing this. It's hostile towards the beginner to 
allow hanging the parser and I ran into this quite a few times, before 
finding out what went wrong.

and I still occasionally accidentally activate it when building parsers 
in the console.

Parsing is not a beginner task. There are many ways you can shoot 
yourself in the foot with PARSE, and we just added more. Live with 
the fact that some concepts require some explanation :)

This is why we have the ?? operation and TRACE function.

can you show me an example where SOME [] is useful?

some [remove "a"]

not some [], but empty rules

oh, I find the new stuff makes much of the engine much less exponentially 
guru level.  its like... in R2, parsing a number in a string is easy... 
extracting a chain of them requires some thought, beyond that... 
people bleed from their eyes   ;-)

Rules that don't advance.

if a rule constitutes the part in the block and the block is empty, 
I don't see how that is useful.

I think the 'some loop highlights the important need to extend 'secure 
to cover parse.

That's an effective way to rein in loops on dynamic / user contributed 
parses -- such as Henrik's / Kaj's "Try REBOL 3" web sites.

as steeve says... forever [] isn't usefull either.  at some point 
you have to understand a bit of what you are doing.


the only thing that really happens to me is hitting the end, and 
not realizing that something in my some or any is preventing the 
rule to go "past" the end.

if the empty block is constructed later, it can be useful to not 
prevent their existing

Sunanda, yes, that's one reason I halted the project.

Steeve, would it be empty right at parse time?

Henrik, the problem is not that the rule is empty, it is that the 
rule doesn't advance the position. Complex rules can not advance 
too.

yes, but not with some [ ] or any [ ]

BrianH, but empty rules do per definition not advance. Why not per 
definition then cause an error?

I can see that all situations can't possibly be avoided, but these 
stupid little ones, I'm sure they can.

It's irrelevant. Empty rules are easy to debug, so that won't be 
a problem for beginners. It's when complex rules don't advance that 
is the problem.

I disagree that it's irrelevant. It's hellishly annoying to have 
to wait for the parser to finish on an empty rule, when you are working 
with PARSE in the console.

Don't be that short-sighted, Henrik. Since the Parse dialect is intended 
to be Turing complete, there is no way how to "automagically" detect 
all such cases!

Removing support for PARSE [some []] means removing support for PARSE 
[] - inner blocks work through recursion.

Ladislav, how hard is it to detect an empty rule and cause an error?

you really mean it, that forever [] should be automatically implemented 
to cause an error?

Sunanda, SECURE 'eval already covvers PARSE.

Ladislav: I don't know? It seems like a good idea and it's a bad 
way to pause a script. Rather use WAIT. But it's unrelated to empty 
rules as they are a side effect of PARSE.

not for PARSE currently IIRC

Secure doc say: <For example, PARSE cycles are not yet counted.>
http://www.rebol.com/r3/docs/functions/secure.html

Ah, well that should be fixed then :(

i hope they will be never counted, because it will slow down the 
process...

Henrik, forever [] and some [] are unrelated just for you; not for 
me.