World: r3wp

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.

False and none are treated the same in many cases, so I think it's 
fine the way it is; otherwise you have to consider all the other 
cases as well.

well:

pick [do-this do-that] false ; == does 'do-that

pick [do-this do-that] none ; == error

This came from a function where I had a refinement:

f: func [/act] [
	pick [do-this do-that] act
]


You can't do that, since /act is none. Sure you can then use EITHER, 
if do-this and do-that are not necessarily in one block, but you 
couldn't extend the existing code with:


>> pick [do-this do-that] any [act false] ; == still none, which 
gives error

So you have to use something less clean like:

>> pick [do-this do-that] any [act 2]

you can do
>>pick [do-this do-that] found? any]

I pulled out the question, sorry, it was a misread at my side

argh, again:

>>pick [do-this do-that] found? act

I am content with it as it is

rebolek, thanks. as long as there is a way to discern between none 
and false with one function

some interesting block "quirks":

    block1: #[block! [a b] -1] none
    block2: #[block! [a b] 4] none
    mold/all block1 ; == "#[block![a b]-1]"
    mold/all block2 ; == "#[block![a b]4]"
    index? block1 ; == -1
    index? block2 ; == 3
    length? block1 ; == 4
    length? block2 ; == 0

all and any are extremely capable as they are.  and I  don't see 
why they should change.  all and any are NOT boolean operations, 
they are program flow just like if and either.

'ANY on returns a non false or non none value.  it does not return 
such a value from the block itself. if you specify only none and 
false value, it effectively assumes all is bad and returns none.


'ALL is the same, but will only return a value unless one value equates 
to false or none (in which case it considers the block a failure 
and returns its own value, not the value from the block itself).

Gab, the same applies for:

This doesn't look very consisten to me:

>> to-integer none
== 0
>> to-decimal none
** Script Error: Invalid argument: none
** Where: to-decimal
** Near: to decimal! :value

yes, i agree. i think other cases like that have been pointed out 
in the past.

I don't know how INDEX?/XY works. Help, please.

(is it meant for IMAGE! datatype?)

Ladislav: it seems so:

>> n: make image! 100x100
== make image! [100x100 #{
000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000...
>> n: skip n 300
== make image! [100x100 #{
000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000...
>> index?/xy n
== 0x3

thanks

I'm curious, if there's also some function for setting position in 
image! - something like AT/xy

There is:
>> at logo.gif 12x10
== make image! [100x24 #{
7C7C7CF5F5F5FEFEFEFEFEFEB5B5B5020202020202020202020202020202
020202020202BDBDBDFEFEFEFEFEFEF5F5F5A5A5A59B...

Ah, thanks

>> index?/xy at logo.gif 12x10
== 12x10

mail: read pop://user:[pass-:-mail-:-example-:-com]


How should the above line be written when the user name is an email 
address?