World: r3wp

lol :-)

yes it works perfect in R3. Thanks again.

>> parse [ <tag> ] [ copy t tag! ]
== true
>> t
== [<tag>]

never noticed it made a block! before

>> parse [ <tag> ] [ set t tag! ]
== true
>> t
== <tag>

There's a difference between COPY and SET in block parsing mode.

From the docs:

SET - set the next value to a variable
COPY - copy the next match sequence to a variable

Good the remember when dealing with "sequences":

>> parse [ <tag> </tag> ] [ copy t [ tag! tag!] ]
== true
>> t
== [<tag> </tag>]
>> parse [ <tag> </tag> ] [ set t [ tag! tag!] ]
== true
>> t
== <tag>

the = to.

I've always used 'set ... not sure why I used 'copy this time!

<?xml version="1.0"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><SelectResponse 
xmlns="http://sdb.amazonaws.com/doc/2009-04-15/"><SelectResult><Item><Name>2010-01-29T09:54:48.000ZI3s3NjIxRjZERDI1MUY0QzQyMDk4M0JDMzkwMERGOEQxQTVDRDY5MzEwfQ==</Name><Attribute><Name>Subject</Name><Value>hello?</Value></Attribute><Attribute><Name>Userid</Name><Value>Guest</Value></Attribute><Attribute><Name>UTCDate</Name><Value>2010-01-29T09:54:48.000Z</Value></Attribute></Item><Item><Name>2010-01-29T09:58:36.000ZI3swMTZBODg3QjAxNDQ2NEU5OENCNTA3OTc5OTg0Mjc1MTJGQzkxQTc0fQ==</Name><Attribute><Name>Subject</Name><Value>First 
Message</Value></Attribute><Attribute><Name>Userid</Name><Value>Graham</Value></Attribute><Attribute><Name>UTCDate</Name><Value>2010-01-29T09:58:36.000Z</Value></Attribute></Item><Item><Name>2010-01-29T11:06:18.000ZI3tFREFCRUYwNTY4OTdBMzcwODM2NzJGQUE5MzAwRUE3NjYwMTMwMTY5fQ==</Name><Attribute><Name>Subject</Name><Value>Index 
working</Value></Attribute><Attribute><Name>Userid</Name><Value>Graham</Value></Attribute><Attribute><Name>UTCDate</Name><Value>2010-01-29T11:06:18.000Z</Value></Attribute></Item></SelectResult><ResponseMetadata><RequestId>14873461-626a-44bf-2d7d-c1b23694b2e0</RequestId><BoxUsage>0.0000411449</BoxUsage></ResponseMetadata></SelectResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>

results: copy []
	parse result [
		thru <SelectResult> 
		some [
			thru <Item> copy item to </Item> (
				?? item

    if parse item [ thru <Name> copy itemid to </Name> thru {<Name>Subject</Name>} 
    thru <Value> copy subject to </Value> thru {<Name>Userid</Name>} 
    thru <Value> copy userid to </Value> thru {<Name>UTCDate</Name>} 
    thru <Value> copy utcdate to </Value> to end ][
					repend results [ utcdate itemid userid subject ]
				]
			)
		]
	]

This parse works fine in R2, but doesn't work in R3 ... I coudn't 
see why last night ... still can't ...

Is that result a block or string ?

because in a string you can't find tag! values

i'm wrong 
T_T

It's a string ...

but i'm still wrong ;-)

Yes, tags are a type of string ...

this is what I get for item 


e>2010-01-29T11:06:18.000ZI3tFREFCRUYwNTY4OTdBMzcwODM2NzJGQUE5MzAwRUE3NjYwMTMwMTY5fQ==</Name><Attribute><Name>Subject</Name><Value>Index 
working</Value></Attribute><Attribute><Name>Userid</Name><Value>Graham</Value></Attribute><Attribute><Name>UTCDate</Name><Value>2010-01-29T11:06:18.000Z</Value></Attribute>

>> parse "<a><item>" [thru <a> ??]
end!: "item>"
== false

a bug

I'm not familiar with that ... what should it say?

It should say:
>> parse "<a><item>" [thru <a> ??]
end!: "<item>"
== false

parsing thru a tag eat one more char

Ah .. ?? is a new debugging function

yep

Should have known about it last night!  Would have saved me sometime 
:(

Well, this looks like an unreported bug ...

exactly

Shall you or I curecode it?

you

;-)

okey dokey

Now I know I can't use r3 for parsing xml .... :(

http://www.curecode.org/rebol3/ticket.rsp?id=1449

you can, just replace <tag> by a real string "<tag>"

ugly !  :)

Point taken ...

Is there any likelihood of the parse enhancements making it to r2? 
 Anyone know?

( without the bugs of course )

0%

And there is a great likelihood of the bugs being fixed in R3. And 
there aren't many in PARSE, just that tag bug afaik.

Graham, I deleted bug #1449 since it was already reported as #682. 
See also #854 and #1160 (and #10, which was incorrectly "fixed").

your response says it was fixed ...

Partially - it used to be worse. That's why it's marked a "problem".

only eats one char instead of two ... so that's a 50% improvement

The worst was when someone "fixed" #10 to make it compatible with 
R2's buggy behavior. Bad fixes get marked as a problem.

Check out #666 for R3's official policy on bug-for-bug compatibility 
:)

at least it should not introduce new bugs

Agreed (and the policy agrees too).

I looked for a previous report on this bug but couldn't find it .. 
4 pages of bugs with parse in them.  I wonder if they can be filtered 
to only show active bugs