World: r3wp

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

it is the same as my email adress contains dot, - it is not according 
to RFC, but used so often, the parser has changed IIRC

I prefer out-of the box functionality, and not a strick adhering 
to standards, if the usage is pretty common ...

That's a problem with FTP in general. There are some servers which 
break the standard (which is also open to interpretation in some 
areas). RT's url parser is doing the correct thing, but supporting 
FTP in the real-world means also dealing with "rogue" standard-breaking 
servers. You could argue that if RT includes FTP in the language 
they should go the whole way with it to prevent dashed expectations. 
On the other hand, you can see rebol is more about breaking with 
the past and coming up with new, more modern (and hopefully more 
reliable) protocols. (Of course, it is possible to have both.)

I would suggest an FTP powerpack then with as many bells and whistles 
as possible.

I would check out FTP-Gadget, which was open-sourced by Reichart. 
(Where did I get it..? Qtask .. ?)

So, I expect there to be a number of servers supported by FTP-Gadget.

henrik, use a block, not a url, i.e. open [scheme: 'ftp user: "\\\" 
...]

anyway, the problem is that rebol decodes percent-encoded characters 
in urls way too early, otherwise you would just encode the problematic 
char. (block format is still easier imo)

is it faster to load a string to see if it is a date, or try make 
date! and catch the error to peform the alternate action ?

I do error? try [date: to-date date]

to-date!

no to-date:-)

>> t: now/time/precise loop 10000 [error? try [to-date "sss"]] now/time/precise 
- t
== 0:00:00.047

>> t: now/time/precise loop 10000 [date? load "sss"] now/time/precise 
- t
== 0:00:00.016

>> t: now/time/precise loop 10000 [error? try [to date! "sss"]] now/time/precise 
- t
== 0:00:00.047

so, it appears to be more than twice as fast to use 'load

I remember a discussion where it was concluded that load would sometimes 
not be useful for determining date validity.

but then if the string is not a valid datatype .. you could cause 
an untrapped error.

So, you have to wrap the whole operation around a try block anyway

Does 'load affect the global name space at all?

Henrik .. you're suggesting use to-date instead ?

haven't tested it. I just remember the discussion. :-)

to date! supports more date formats than load (for obvious reasons)

got a quick example?

of what you mean ..?