World: r3wp

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

>> to date! "10 10 06"
== 10-Oct-2006

oh .. interresting.
Didn't know you could do that.

>> to date! "2006.10.10"
== 10-Oct-2006

In fact I didn't  know u didn't need the "-" in to-date !

are 'to and 'make the same words?

no, but they should be the same in this case.

>> to block! 10
== [10]
>> make block! 10
== []

(as an example of the difference)

I'm goingt to stick to my to-date and error trap it ... :)

I am just transferring many files via ftp to a FTPZilla on Windows.
Aftert some time the ftp hangs.
If I use one steady connection, it hangs writing.

If I use one connection per file, it hangs with the message connecting.
Anyone seen a similar behaviour ?

are u using Romano's patches?

Latest core etc ?

I use the ones based on 2.6.3

trace/net ?

It seems, that it is dependant of system/console/break.
With false, it hangs, with true it works.

Graham: as I need the date conversion again, I found that to make 
it useful, you have to add the error check anyway so it's:

>> t: now/time/precise loop 10000 [all [not error? try [d: load "sss"] 
date? d]] now/time/precise - t
== 0:00:00.031

>> t: now/time/precise loop 10000 [all [not error? try [d: load "1-1-2007"] 
date? d]] now/time/precise - t
== 0:00:00.047

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

I would not use loading. to-date is more clear, shorter and with 
same speed.

I agree.

Anyone got a csv parser that works with embedded quotes?

I tried Bo's, Gabriele's, Gregg's ... all fail as far as I can see.

Gabriele's parser dies with empty fields eg ,"", ...