World: r3wp

Re the Read handler issue: I found a way how to make it work in a 
"standard" way - how should I post it there?

is it too big to be posted directly? maybe you could just post a 
link to the code...

it isn't big, but i can't change my post, can I?

your post in RAMBO? you can't. I'll have to change it for you, or 
we can dismiss the old ticket and create a new one.

Regarding async speed: I posted a note in the async group to look 
at that closer.

Just noticed: HIDE stopped minimizing a window face some time after 
1.2.5.3.1, eg:
	view lay: layout [button [hide lay]]
Is that a bug, or intended? (I'll check this out more later.)

i got lately this
dir: %somewhere/
probe  dir/042
== %somewhere/42 ; the 0 is killed
on 1.2.48.4.2

This is the same problem as I reported earlier, with
	dir: %somewhere/
	dir/1.s3m
** Syntax Error: Invalid decimal -- 1.s3m
** Near: (line 1) dir/1.s3m

This happens because the path elements are each evaluated by rebol 
first.

*smackme* right, its turned in a rebol-value..

See http://www.rebol.net/cgi-bin/rambo.r?id=3642&

yup. good trick with the %

Mmm.. yes it works but I don't really like it. The problem is the 
usual way almost always works without errors.

almost always
 - when it is a valid word. :)

On HIDE: sounds like could be a bug. So add to RAMBO if not already 
there. Thanks.

Yep, path requires valid REBOL.  So, use dir/"042" if you need to 
do that.

(Or, % ok too.)

Why couldn't paths do that for us ? ie. to-path "042" becomes a word...

HIDE minimizes window faces up to View 1.2.8.     Does nothing (that 
I can see) in View 1.2.10 and all subsequent versions.

OK, submitted the HIDE bug to rambo.

Anton: that would be quite bad, how could you then use numbers in 
paths? like block/3 to get the third element.

Gabriele, I mean, that a path component should be converted to a 
"string" word only when it can't be parsed into a normal rebol value.

but 042 can be parsed..

ah!  I have to add a bit extra:  ".... which molds back to the original 
path component string."

anton: that doesn't seem to make much sense, does it? :)

I found that there is probably bug in the native DISARM function 
- I'm explaining it in Rambo

Oldes, interesting one.

Gabriele, here is some code which summarizes my idea very well:

load-path: func [str [string!] /local result val][
	result: copy []
	foreach component parse str "/" [
		either any [
			error? try [val: load component] ; loaded doesn't parse it
			component <> mold val ; or it looks a bit different
		][
			append result to-word component ; make a "string" word
		][
			append result val
		]
	]
	to-path result
]

load-path {my/path}
load-path {my/path/042}
load-path {my/path/1.s3m}

Oldes, maybe port handlers are not expecting PRINT to be used when 
they use ATTEMPT ?

I am wrong, it doesn't look like they use ATTEMPT.

Anton: I still don't see why that should be done for paths, and not 
for blocks.

oldes: i don't think it's disarm, it's more likely that you hit a 
GC problem. btw, most of the code in the errors seems to come from 
some handler.

anyway, it's not something easy to reproduce, so it won't be easy 
to fix. also, is that on the betas or on the alphas? if you don't 
get the same results on the alphas the bug might be already fixed.

because pathes are often used for filenames. dir/file.r . and this 
datatype-exceptions slip easily through attention. and then we think 
"hu?".

Volker, yes exactly. Gabriele, it's the path behaviour I feel the 
user really expects. After so long using rebol, I am not glad to 
find out this underlying relationship between blocks and paths affects 
the allowed path notation.

It's interesting, surely, but it doesn't make me feel any better 
about it. It's like I have discovered a scratch on the nice smooth 
surface which is the rebol user interface.

All I want to do is smooth it out, so sparing others these surprising 
error messages.

Anyway, now I should try to sink my ship; I don't think adding the 
above functionality (of load-path above) to LOAD would slow things 
down at all. But maybe there are some cases where such allowances 
would cause problems. I am thinking if such a loaded path was converted 
to a block, molded, then loaded again, it would cause the error then. 
That's just moving the load error - from the path to the block. I 
think this contrived case would not occur very often - less than 
using new path notation.

I need someone else to chime in here with any scenario which would 
cause a problem using this path notation, because I don't currently 
see any serious problems with it.

that could be solvable: convert the part to a string (or file). block 
then has a string. if you do to-path block, you get dir/"042", but 
that should be ok (with new pathes). its not more "buggy" than making 
42 from 042 IMHO. would be nice to get this, and pathes ending with 
"/" :)

Yes, ending with slash, too. Solve two issues at once.

i think that paths were and are not intended for file paths. that's 
what file! is about.

IMHO, Paths were definitely meant to be able to files you just have 
to realize that you are dealing with a path not a file datatype.

they CAN be used for file paths too but their PURPOSE is not that 
of being used for file paths :)

so, i don't really see where's the problem in using a file! instead 
of a word when a component is not a valid word

Their purpose is to simplify the referencing of values and since 
files are just values that are stored on disk then I'm sure it was 
intended to work that way. ;-)

but of course this is just MHO

Ah, so we are arguing the same point then. ;-)

i'm against adding special rules for paths, not against using paths 
with file values :)