World: r3wp

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

Bring it up in the !CureCode group.

I want to extract all the dates ( dd-mmm-yy, dd mmm yyyy d mmmmmmm 
yy )


extract-dates: func [ txt 
	/local months dates days month year
][
	dates: copy []
	months: copy []
	digit: charset [ #"0" - #"9" ]
	digits: [ some digit ]
	foreach mon system/locale/months [
		repend months [ mon '|  copy/part mon 3 '| ]
	]
	remove back tail months
	parse txt [
		some [
			to 1 2 digits copy days 1 2 digit [ #" " | #"-" ]
			copy month months
			[ #" " | #"-" ]
			copy year [ 4 digits | 2 digits ]
			( repend dates rejoin [ days "-" month "-" year ] ) |
			thru 1 2 digits ??
		]
	]
	dates
]


extract-dates "asdf sdfsf  11 Jan 2008 12-January-10 fasdfsaf asdf 
as 11 2 3 3  13-Feb-08 asdfasf "

not working ...

R2 or R3 ?
In any case, the first rule may fail.
you can't do "TO 1 2 digits"

TO and THRU have limited argument syntax, and don't support full 
rules. Both R2 and R3 support literal value arguments (that don't 
count as rules). R3 also supports a block of literal values delimited 
by |, and those values are less limted.

Something weird !
Using a simple charset with TO or THRU should work.
But it fail here with R3.

digits: charset "134567890"

Something weird !
Using a simple charset with TO or THRU should work.
But it fail here with R3.

>> digits: charset "134567890"
>> parse "azaz 34" [to digits ??]
end!: "azaz 34"

Oh my !!!!!
It fail with R2 now too...

R2 & R3 ... I tried
nondigit: complement digit nondigits: [ some nondigit ]

some [
	any nondigits 1 2 ....
]

but it gets stuck on the year

Steeve, that's a bug that I reported yesterday.

I was using r3 as it's easier to trace the parse ... but perhaps 
i shouldn't!

Maybe i'm wrong ,I can't  remember if TO or THRU ever worked with 
charsets.
Alzheimer catches me...

XRatio is right .. parse is too difficult!

hehe