World: r3wp

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

so the file may look like %localhost_atport_88/test.php_query_id=100

anton: yes, seems that the crash is gone

#3623 the proposed split-path fails in some situations

for example here: %file or here: %e./

this is a different version which use parse and is > 4X  on my system

rebol[
	Author: "Romano Paolo Tenca"
	Date: 10/02/2005
]
split-path-3: func [

 "Splits a file or URL pos. Returns a block containing path and target."
    target [file! url!]
	/local dir pos
][
	parse/all target [
		[#"/" | 1 2 #"." opt #"/"] end (dir: dirize target) |
		pos: any [thru #"/" [end | pos:]] (

   all [empty? dir: copy/part target at target index? pos dir: %./]
			all [find [%. %..] pos: to file! pos insert tail pos #"/"]
		)
	]
	reduce [dir pos]
]

it also fix this split-path bug:
>> split-path %""
** Script Error: Out of range or past end
** Where: split-path
** Near: last target
>> split-path-3 %""
== [%./ %""]

Oldes, good ideas. Do you think the "?" -> "%3F" is a replacement 
which is more prone to collision (than a longer string such as "_query_" 
) ?

Or perhaps you think it could cause problems of automatic decoding 
when ( if it ever happens ), the public cache path is converted back 
to a URL! ?

Anyway, I think the "?" replacement is the one that fixes the most 
common problem. I think ports are not such a common problem. Obviously 
you needed it to work for something..., but I wonder what your opinion 
on it was.  We shall need to make a total solution at some stage...

Gosh! now I think it might be better to replace the "?" with a slash 
"_query/"  (<-- note the slash), so it becomes a new directory.

eg: path-thru http://www.dom.com/cgi.r?hello
;== view-root/public/www.dom.com/cgi.r/hello

Anton, if you do that, how do you convert it back?

I guess you can't, unless you know more. I just leapt at that idea 
because I thought it would reduce the amount of repetition in path 
and filenames.

(so all the cgi.r queries would be grouped as files in the cgi.r/ 
directory)

Mmm.. similar to Oldes' method, you could replace "?" -> "_query/", 
  then directories that end with "_query/" are converted back to 
"?"

Ahha! I just re-read my previous post... :) Duh!

The example should have been:

eg: path-thru http://www.dom.com/cgi.r?hello
;== view-root/public/www.dom.com/cgi.r_query/hello

I just found a strange bug:
>> read %rebol.r
== {
REBOL [
    Title: "REBOL Extended Definitions"
    Date: cvs-date "$Date: 2001/04/29 16:00:17 $"
    Rights: "Copyright (C)...
>> read %rebol.r.
== {
REBOL [
    Title: "REBOL Extended Definitions"
    Date: cvs-date "$Date: 2001/04/29 16:00:17 $"
    Rights: "Copyright (C)...
>> read %rebol.r.....
== {
REBOL [
    Title: "REBOL Extended Definitions"
    Date: cvs-date "$Date: 2001/04/29 16:00:17 $"
    Rights: "Copyright (C)...

Trust me, these files do not exist: [ %rebol.r.  %rebol.r..... ]

I'm on WInXP NTFS, can anyone try linux or another filesystem ?

No such problem on Win98   -- tried it with the live and latest betas.

I'm on Win/XP and got this with Core 2.5.6

>> print read %rebol.r
REBOL[
    Title:   "REBOL Extended Definitions"
]

feedback: func [
    "Send REBOL feedback."
][

    print "Go to http://www.rebol.com/feedback.htmlto send feedback."
]

There is a file rebol.r in the directory where rebol0301.exe

Actually, this looks like a WindowsXP or NTFS problem, not a problem 
of rebol at all, because I can "Run D:\Anton\Dev\Rebol\View\rebol.r...." 
and my text editor (associated with .R files) pops up to edit rebol.r

Peter, now do this:

print read %rebol.r.......

(including all those extra period markers.....)

When I tried the same with Rebol 2.5.8 which is just sitting on my 
desktop and got 

>> print read %rebol.r

** Access Error: Cannot open /C/Documents and Settings/Peter/Desktop/rebol.r
** Near: print read %rebol.r

Same results with the periods

That's a different issue. Try the bolded code exactly as above.

Ok. So you see the bug too.

Sunanda, are you using NTFS ?

No, just plain FAT

So problem on WinXP/NTFS,  no problem on Win98/FAT. Definitely not 
a problem of rebol. I hesitate to post a RAMBO ticket.

Anton: what "list-dir" give you as result ???

And "what-dir" ???