World: r3wp

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

to/thru never worked with charsets. that's why we always have those 
complements... :)

Oh crap. Well, it was reported as a bug, and it's staying that way 
until Carl says otherwise :)

given that to and thru do "more" in R3, it probably is not bad to 
consider it a bug. (maybe it should be considered a bug in R2 as 
well, given that FIND does work with charsets...)

Carl seems to think that he can add TO or THRU QUOTE value to block 
parsing too.

this works 


extract-dates: func [ txt 
	/local months dates days month year
][
	dates: copy []
	months: copy []
	digit: charset [ #"0" - #"9" ]
	digits: [ some digit ]
	nondigit: complement digit
	nondigits: [ some nondigit ]
	foreach mon system/locale/months [
		repend months [ mon '|  copy/part mon 3 '| ]
	]
	separator: [ #" " | #"-" ] 
	remove back tail months

 date-rule: [ copy days 1 2 digit separator copy month months separator 
 copy year digits (
		?? days ?? month ?? year
		append dates ajoin [ days "-" month "-" year ] 
		)
	]
	parse txt [
		some [
			any nondigits [ date-rule | any digits ]
		]
	]
	dates
]