World: r3wp

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 :)

Dido

IIRC in the bbs-project Carl prefered [data-file: dir/file] over 
[data-file: join dir file]. i prefer that too, but currently no "/", 
so [data-dir: dirize dir/file], ugly IMHO.. And now comes changing 
file-names when they are numbers. thats a bit risky to me.

The advantage of using dir/:file is that if dir has no ending /, 
it will be added.  JOIN does not have that feature.

Literal filenames within paths are a bit of an exception -- the standard 
method should be to use % or " around them.

Eg: dir/"123.txt"  or dir/%123.txt

Well, I'm sticking to my guns - I have some supporters, and the opposition 
is weak :) so I'm making a rambo ticket.

I've just noticed this:

o: make object! [type: 'face]
third o
; == [type: face]  ; <---- should be a lit-word!   ?

type? 'face == word!

because 'face gets evaluated.

Ah yes...

third face
;== [type: face .....

I guess I'm just pointing out the difference between THIRD and MOLD 
again.

(I wanted to clone FACE without the TYPE attribute)

OK, submitted a ticket "Load paths in a more relaxed manner".

Gabriele: sorry, can you add to the ticket  {refer also to existing 
ticket "Allow final slash on path - eg. 'hello/" http://www.rebol.net/cgi-bin/rambo.r?id=3637&}

callback

crash: "Root block overflow"

DLLIMPORT void test_callback(
	void (*pFunc)()
){
	pFunc();
}

loop 7  [
	test-callback: make routine! [
		c [callback! []]
	] lib "test_callback"
]

Open the library, make the routine 7 times, crash guaranteed on my 
system.

That as infinite loop isn't it. Why will this be an error? I am not 
sure rebol can catch that problem.

There is a limit on the number of callbacks available I think is 
16.

Not infinite loop, the function hasn't even been called yet. Only 
in routine making stage.

The limit maybe lower.

Other types of routines can be made thousands of times with no problem.