World: r3wp

I simply re-make the object with itself plus the new branch inside 
rel-obj. works fine, but there's some stuff to manage.

I think you might have found a bug. I see something which I find 
hard to explain:

oh?

well, I have to go to bed now, so good luck with the bug hunting 
:-)

>> obj: none
== none
>> path: [obj]
== [obj]
>> code: reduce [to-set-path path 'make to-path path [new: 123]]
== [obj: make obj [new: 123]]
>> print code/1/1 = 'obj
true
>> ?? code
code: [obj: make obj [new: 123]]
== [obj: make obj [new: 123]]
>> do code
== none ; <-- what a strange result !
>> ?? obj
obj: none

Same here. Sleepies :)

a path with only one element is probably not supported.

(btw, you're doing make none [new: 123] so obviously you get none, 
Anton :)

isn't a path with one element pretty useless then? I just wish that 
set would work on paths. it makes sense to me.

+1 for set on paths!

a path with one element is useless indeed. you cannot create it normally; 
it's like words with a space, or issues with a space, and so on. 
they exist, but they are not "valid" in a strict sense.

%/C/
Pretty useless directory path - it's only got one element.

Gabriele, oops about the none.

I see the problem.  A path can represent different things, so if 
your path is not representing anything yet, then REBOL won't know 
how to deal with it as opposed to setting a word with 'set.

No, wait a minute, this code is what I meant (just changes the first 
line):

obj: make object! []
path: [obj]
code: reduce [to-set-path path 'make to-path path [new: 123]]
print code/1/1 = 'obj
?? code
do code
?? obj

OBJ seems not to have been changed by doing the code.

Gabriele has seen that a set-path! with only one element doesn't 
work, but you can use a set-word! instead, because they're conceptually 
the same, and they look the same:
>> to-set-path path
== obj:
>> to-set-word path/1
== obj:

So this seems to work:

 code: reduce [either 1 = length? path [to-set-word pick path 1][to-set-path 
 path] 'make to-path path [new: 123]]

Hmm.. I think I agree with Gabriele - the path with one element molds 
just like a word, so it would not load back correctly. Mold/all could 
be made to handle 1-element paths specially, writing the datatype 
eg:  #[path! [obj]]  Is it worth it, though ?

well, it does seem to work, but it's only the first step of a few 
more. I hope it'll be worth it :-)

no, actually it doesn't work. I may be attacking the wrong problem. 
whenever I need to use the set-path part of your code, it, just like 
before, doesn't work.

the to-set-path part, sorry

so it's not a one-element-path problem but a "simple" issue of binding 
the path to the right context.

BTW you can manipulate a path like a block. And it may help to use 
'in.

But still ugly.

Henrik, what would rel-obj look like after issuing this ?
	add-relation [users male "Joe" age-group "Senior"]

make object! [
	users: make object! [
		male: [
			"Joe"
			make object! [
				age-group: ["Senior"]
			]
		]
	]
]

%/C/ actually has more than one element. %/ only has one element, 
in the file sense, but it also has a special meaning. A path with 
one element is just a value, most likely a word.

That said, I don't think they would be entirely useless, but the 
need for them seems very small.

%/C/ is a file! not a path!
A file! is a string type.

the first element of a path! must be a word! (i'm not aware of any 
other ways to build a path, except for using make path! directly), 
and there must be a second element.

:) I understand Brian, it was just my first retort. :) Of course, 
a 1-element path! would be indistinguishable from a word!

I'm trying to log into an FTP server with \ in the user name. Is 
that legal to use? I've tried a few different clients and only Total 
Commander will accept it. Rebol will not accept it as a valid URL, 
unless the \ is removed.


The problem is that the webhost Talkactive apparently use \ in all 
their usernames...

seems that Cyberduck can log in too

that's a bit of a problem

then just merge \ with urlchars

how?

try the following:

net-utils/url-parser/user-char: union net-utils/url-parser/user-char 
make bitset! #"\"

well, at least it worked for merging @ and # in ....

or simply use non one-liner - use port spec ... the limitation is 
there only with url format ....

amazing. it works.

but what is going on? :-)

so it changes which chars are legal in an URL?

yes

I have patched my user.r and never care once again

is this in RAMBO or not generally something that would be considered 
a good idea?

no, RT claimed that their url parser is ok, according to RFC ....

well, it's a problem if you want to access certain webhosts, then...

if \ breaks something in the URL parser, then it would be a problem 
of course, but then again, you can't rely that much on the FTP system 
in rebol