World: r3wp

>> 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 ,"", ...

Gregg's, and Bo's and mine  don't report an error and parse it incorrectly

Joel Neely's ... written in Sep 2000 takes the prize for parsing 
by reporting an error in the line in question.

Excel managed to parse the file correctly ...

Moving to parse group

I'm attempting to add a "repeat command" button to an app but I need 
to capture the what was sent to a function including the refinements. 
I'll put that capturing code inside the function called and store 
it in a global. The arguments, of course, are no problem to save.

When you import data using "data: read/binary {sometextfile}" you 
seem to get a string of hex values.  Ex:

probe 'data' of a file containg the word "Hello"  results in #{48656C6C6F} 
but if you 

probe first data it returns 72.  So when you probe the entire data 
stream it returns it in hexidecimal format
but when you probe each character it returns a decimal value.


At any rate how do you convert the characters in the variable 'data' 
back into ASCII values?  IOW, how do you convert the decimal value 
of 72 back into an "H" or the #{48656C6C6F} back into "Hello"?

>> a: 72
== 72
>> to char! a
== #"H"
>> b: #{48656C6C6F}
== #{48656C6C6F}
>> to string! b
== "Hello"

sometimes REBOL is to simple.  we forget that it can be as simple 
as that.  ;-)

graham: i think mine dies because of the wrong quoting, not empty 
fields, but i haven't tested it. i would actually be surprised to 
see a csv parser that handles quoting that way, because the only 
way to handle them is to ignore them.

Gordon, use TO-STRING or AS-STRING.

Gordon, This may be too obvious to mention but if you know it is 
not a binary file then don't read it with the /binary refinement 
then you won't need to convert.

Hi guys;
  Thanks for the input.


PeterWood & Anton:  I could have sworn that I tried both to-char 
and to-string.  It is the obvious answer, but I have been trying 
so many things in solving a parse problem that I missed it.  Now 
I remember, I did try them but at the time I complicated the character 
testing by using quotes and brackets and braces, or in the case of 
the hex string - not using the #{}.  Anyway, thanks for your time 
in answering. 


Gabriele:  As I was waking up this morning, I was thinking about 
modifying your CVS parser to make it work with (improperly) quoted 
strings.  That may be the simplier answer to my parsing problem.


MikeL: I started by not using the /binary but then the 'read' converts 
the #{0D0A} sequences to just #{0A} so I was going to try using the 
/binary option to preserve the original #{0D0A} and got sidetracked 
into changing the rest of the file back into a string.  Turns out 
that I will be going back to just using the 'read' without the /binary 
option and try modifying Gabriele's, CVS parser to handle improperly 
embedded quotes.

gordon, can you just ignore the quotes? (if you know they are not 
really relevant in your file)

(ie in my code allow " in the charset and remove the quoted field 
rule)

I'm not sure, if I like that:

>> to integer! ""
== 0

would you prefer an error to be caused?

maybe a list of  how rebol converts empty values to other types would 
be in order

1.2.1 and early do give an error in this case.
So, at the very least., its an undocumented change of behaviour.

RAMBO it?

Ladislav I expected error! but I'm not sure about that

>> to decimal! ""
** Script Error: Invalid argument:
** Near: to decimal! ""

one of the two needs to be changed. :)

(i believe this is in rambo already, you should do a search first)

I think I prefer the error.

this is where as-integer and as-decimal make sense IMHO.   return 
the most logical representation of supplied value, with a defined 
fall back when no sense can be made of input.

but the rules must be clearly documented, in any case.

The bug is in RAMBO (RAMBO Ticket #3928) for 352 days. Seems hard 
to fix ;)

if you guys think it should have a higher priority, i can raise it.

It will be good to know what is typical longevity of bugs according 
to their priority.

Ladislav posted on 18. sep.: do you like this: any [1 true] ; == 
1 ?

I have a variant: any [false none] ; == none


Would it make more sense to return FALSE? It seems to me that FALSE 
should have precedence over NONE.