World: r3wp

#3436 OK - 2.5.58.3.1 on WinXP

I just noticed:

mold ['return:]  ;== "['return]"    <-- missing the colon ":"

mold/all does not help.

simplifies to:

mold 'return:   ;== "return"   (note no leading single quote, we 
are expecting that as normal though.)

mold 'hello:   ;== "hello"     (same idea)

lit-words like 'hello:  only just became valid recently (since View 
1.2.55.3.1)

I don't see any Rambo ticket for this issue (searched rambo for "word", 
looked at all 36 items.)

But, can somebody confirm if it is a bug or not ?

It would appear to me to be a bug.

(not that that means anything. ;-)

>> a: 'hello:
== hello


The colon seems to be removed. So it's a lit-word thing, nothing 
with mold, I guess.

actually, ['return:] should be marked as a bug, because you are trying 
to create a "cross" between lit- and set-word

what type should it have? - the interpreter seems to take it as a 
set-word

... wrong, the interpreter takes it as a lit-word

that should probably throw a syntax error... anyone submitting it?

What if you want to generate code, eg:
>> reduce ['return: [integer!]]

== [return [integer!]]   ;  I wanted this --->  [return: [integer!]]

I know you can use to-set-word, but that's not very concise is it 
?

But as Ladislav pointed out above, it seems that  'return:  would 
have to be interpreted as a new datatype ( a lit-set-word! )

Maybe it's not worth it now to add such a new datatype.. or maybe 
it does not hurt at all, speedwise, because if the parser is going 
to catch the syntax error above then it may as well just assign the 
new datatype. The cost, I think, will be in maintaining a new datatype; 
bug-testing, docs etc.  So ok, I agree with Gabriele.

Ok, I posted RAMBO Ticket #-131   (waiting to be reviewed)

Anton: What if you want to generate code, eg:
>> reduce ['return: [integer!]]

try reduce [first [return:] [integer!]]

Yes, that's better, but still a workaround.. thanks :)

If you want something to be reduced and not others, you can use compose.

or use my http://www.fm.vslib.cz/~ladislav/rebol/build.r

Ok thanks, but it's no longer a problem.. :) I just noticed that 
it's a strange inconsistency, that's all.

just found a nasty bug!    if you call browse 5 times in any of the 
rebol view beta versions, rebol crashes.

on window 2k... not sure about other platforms

I posted it on RAMBO...

Same Happens here on rvdraw57e.exe & WinXp proffessional

I get the same as PhilB: "**Crash : expand series overflow"  rvdraw57e, 
 WinXP

Alan just found this issue:

>> site: http://www.dom.com/
== http://www.dom.com/
>> site/1.r
** Syntax Error: Invalid decimal -- 1.r
** Near: (line 1) site/1.r
>> site/1-r
** Syntax Error: Invalid date -- 1-r
** Near: (line 1) site/1-r
>> site/1-1-1r
== http://www.dom.com/1-Jan-2001
>> site/1_r
** Syntax Error: Invalid integer -- 1_r
** Near: (line 1) site/1_r

Actually, just looks like the rebol lexical parser doesn't like it. 
Something I can live with. Just work around using JOIN.

Anton, what 1.r should be, for you?

standard (= load known) rebol words cannot start with a number ('1a 
is not permitted).

Yes, that is what I realised.

the rebol parser could be more relaxed (what it is not an integer, 
an url, a file and so on) must be a word!, but so you will never 
see an error! for invalid integer! invalid url! and so on, and the 
parser would be also more slow

Ah yes, that makes sense.

RAMBO ticket #3244
http://www.rebol.net/cgi-bin/rambo.r?id=3244&

On WinXP: With Rebol/View 1.2.57.3.1c & e betas I can no longer demonstrate 
the bug. :-)  The older View 1.2.56.3.1agg9  still crashes at about 
9000 for me.

View 1.2.57.3.1c  completed successfully three times in different 
sessions, and three times in the same session.
View 1.2.58.3.1e  completed successfully twice.

The test code just scans HKLM, I wonder if I dare scan the entire 
registry ?

But I would like to stress-test by starting several rebol sessions 
to compete for the same keys at (hopefully) the same time.

In Firefox, the Example code section in the link above is shown with 
an extra newline for every line. Looking at the rambo-generated source:

<pre>rebol [
<br>	{
<br>		2.1.24 crashes windows XP at n = 214 in my system
<br>	}
<br>]
<br>n: 0
<br>scan: func [name blk /local y][
<br>	probe name
<br>	probe n: n + 1

<br>;	write clipboard:// name ;if this line is not commented, crash 
appears after more iterations
<br>	foreach x blk [
<br>		y: list-reg/HKLM join name [x "\"]
<br>		if y [scan join name [x "\"] y]
<br>	]
<br>]
<br>
<br>scan "" list-reg/HKLM {}
<br>halt
<br></pre>

You can see all the <br> tags, which are not needed when using the 
<pre> tag, as far as I know. (I thought html tags in the scope of 
a <pre> tag were supposed to be ignored).

If they are, then only some are ignored - I know <a> tags still work 
insire <pre> tags.

inside*

#3626 - path-thru - I'm using "_query_" instead of #"?" char in the 
path and "_atport_" to recognize different port of the url