World: r3wp

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" ???

Just the one file, trust me :)

The bug is shown for any file, not just rebol.r

i can confirm your observation

eg. rebol.exe....

looks like ntfs ignores leading dots

what can you expect from ms...

yeah... trailing you mean. :)
>> exists? %...rebol.r
== false
>> exists? %rebol.r....
== true

has anyone found out the cause for red icons in IOS?

I noticed one entry in RAMBO from Oldes or someone else, describing 
incorrect handling of timezones or something like that ...

but dunno if it is realted or not ....

I think so. Bad timezone found by QUERY (as used by INFO?). Replacement 
is to use GET-MODES file 'modification date.

(from memory)

(my brain memory, that is)

Red icons ...usually a problem with syncing when Daylight Saving 
Time goes on or off.

reset-dates.r utility available from RT to correct them (doesn't 
always work).

(Ups, I did not notice the trailing dot. My wrong)

oops, that should be GET-MODES file 'modification-date,  but Sunanda's 
answer is more relevant..

Sunanda - but t hat problem of bad syncing happens only on certain 
systems. Here in CZ for most or all Win versions ... bad timezone 
or something must be the reason. I remember RT stating Win98 returned 
incorrect (shifted) time-stamp under some conditions, but that is 
not only W98 related imo ...

I'll stop promoting IOS here, if that issue is not resolved! I would 
not hesitate to push my client to use some correction script, but 
it does not work always :-( ..... I need proved solution and full 
resync is not that ...

It's a wierd problem, and RT don't seem able to fix it/
reset-dates.r is a sort of symptom suppressant.


I've had to do full reysncs a couple of times.....Not a good thing 
to ask **everyone** to do.

Who thinks that maybe load parser should be mroe relaxed with paths 
? eg:
>> view-root/public/
** Syntax Error: Invalid path -- public/
** Near: (line 1) view-root/public/

The parser doesn't know that VIEW-ROOT is a valid directory name, 
so why should it assume that it's a bad path ?

(Obviously, I know that the error disappears when the final slash 
is removed, but I want the slash there.)

(Also, it helps me make dir-utils commands like:   CD view-root/public/

I would like that too. but a path! is a series, maybe that is tricky? 
but we could set the last element to unset.

Can anyone think of any reason why it shouldn't be allowed ? I can 
only speculate that *maybe* it slows down the interpreter in some 
way, but I don't think so.

it might help with file paths, but what about object paths?  How 
should a typo like system/view/ be handled? or face/text/ ?

Yes... that is the main issue: since a path can be represented as 
a block, how does the trailing slash get indicated in a block?