World: r3wp

(and doing the same thing, at least in principle)

Yes, and a good point it was too.

Steeve, I'm sure that the reason it was so easy for me to come up 
with workarounds off the top of my head on a weak-brain day was because 
I had seen them before when you pointed them out and didn't remember 
it directly. In any case, I'm sure your stuff was great.

The ticket was for documentation purposes, as well as a request. 
It was to summarize the conversation from before.

Steeve, Ladislav... sorry, but your version is not working. The main 
SOME rule finds only one match and than stops. Maybe I should give 
you a simple test string so you could test it first.

hm.. it works on simple test, don't know why it stops for my real 
data.

that is interesting, (my version differs from Steeve's), but should 
be as similar to your version as possible

My simplified test is:
parse test: {[{1}{2}][{3}{4}][]} [
	some [
	    thru {[} 
	    ; copy the DOC
	    copy doc to {]}
		; remember the DOC-END
		doc-end:
		; switch to DOC parsing
		:doc
		(print "start")
		any [
			thru "{" copy n to "}" (probe n)
		]
	    ; switch to original input
	    (print "end")
	    :doc-end
	]
]
that's working as expected.

I understand the principe, but as I say, on real file it stops.

may be a Parse bug, e.g.

so, it is worth testing

What does "stops" mean, BTW?

you can test real data as well:)

print "loading data"
data: read/string http://www.imagemagick.org/api/magick-image.php
ask "parsing version 1"
parse/all data [
	some [
	    thru {<h2><a} thru ">" copy name to {<}
	    doc-start: to {^/ </div>} doc-end: :doc-start
		[
	        thru {<pre class="code">} copy code to {</pre} (
	            probe name
	            probe code
	        )
	        any [
	            thru {<h5>}
				here: if (lesser? index? here index? doc-end)
				copy arg to {<}
	            thru {<ol><p>} copy arg-desc to {</p></ol>}
	            (printf ["  * " 10 " - "] reduce [arg arg-desc])
	        ] 
	    ]
	    :doc-end
	]
]
ask "parsing version 2"
parse/all data [
	some [
	    thru {<h2><a} thru ">" copy name to {<}
	    ; copy the DOC
	    copy doc to {^/ </div>}
		; remember the DOC-END
		doc-end:
		; switch to DOC parsing
		:doc
	    thru {<pre class="code">} copy code to {</pre} (
	        probe name
	        probe code
		)
	    any [
	        thru {<h5>} copy arg to {<}
	        thru {<ol><p>} copy arg-desc to {</p></ol>}
	        (printf ["  * " 10 " - "] reduce [arg arg-desc])
	    ]
	    ; switch to original input
	    :doc-end
	]
]

aha, it needs to be written this way:

parse/all data [
	some [
	    thru {<h2><a} thru ">" copy name to {<}
	    ; copy the DOC
	    copy doc to {^/ </div>}
		; remember the DOC-END
		doc-end:
		; switch to DOC parsing
		; we need OPT to be able switch back
		:doc opt [
	        thru {<pre class="code">} copy code to {</pre} (
	            probe name
	            probe code
		    )
		    any [
		        thru {<h5>} copy arg to {<}
		        thru {<ol><p>} copy arg-desc to {</p></ol>}
		        (printf ["  * " 10 " - "] reduce [arg arg-desc])
		    ]
		]
	    ; switch to original input
	    :doc-end
	]
]

since OPT was needed, it is provable, that the "inner parse" fails 
sometimes, which does not look desirable, and may provoke your attention, 
Oldes

I've got it.. there is missing <pre> in the third doc so that's why 
Steeve's version fails.

(I wonder what they use to document the ImageMagick project.. it 
does not look like fully automated documentation. There are also 
some typos in the spec names.)

I'm working on an incremental lexer able to perform line-by-line 
analysis of any plain text documents.

the idea is to allow editing without having to reparse all the document.

The syntactical rules will be regular parse rules easy to understand 
and to modify, to facilitate
the creation of different model of document.

Of course, the first target is a rebol parser, but the make-doc format 
is also in my short range.

If anyone already have deep thoughts about the subject, please share 
your opinions.
I will come with a proto soon enough.

Will the REBOL parser be using the R3 incremental parser, TRANSCODE 
?

Btw, if you are using PARSE for incremental parsing, watch out for 
this: http://issue.cc/r3/1787

what is the equivalent in R3  of disarm ?

Nothing, it's unnecessary in R3.

You have to DO an error explicitly to trigger it. Otherwise, you 
can just reference it directly as if it were an object.

value: disarm :value 
 how i translate that ?

you  don't need to, just use the /error refinemeent with transcode.
>> transcode/next/error
and you get an error object if any

[!REBOL3 Parse group now exists for specific R3 Parse discussions]

ok thx

steeve it's in the colorize function code of area tc ...

either error? :value [
                        value: disarm :value

how do I adapt that ?

value: disarm :value 
Just get rid of the line.

ok ...

and this how i use transcode in it ? instead of load/next here ? 
>> error? set/any [value end] try [load/next start]

Shad, I will do it if you wait a little

I can do it now either way i need to understand the way R3 handle 
things

since the disarm is gone this like don't work anymore either value/arg2/1

It depends on the circumstances. Once an error is triggered it can't 
be referred to again until it is caught by TRY, which disarms it.

You don't need disarm in R3:

>> if error? set/any 'err try [1 / 0][ probe err true]
make error! [
    code: 400
    type: 'Math
    id: 'zero-divide
    arg1: none
    arg2: none
    arg3: none
    near: [/ 0]
    where: [/ try]
]
== true

Do we need the set/any or is enough just:
	if error? err: try [1 / 0][ probe err true]

how to copy a parsed stream into a object instead a string var?
this fails
parse page [thru <tag1>  copy obj-buffer/result   to <tag2>]

** Script Error: Invalid argument: obj-buffer/result

ok, looks like this is working.


parse page [thru <tag1>  copy a  to <tag2> (obj-buffer/result : copy 
a)]

Common parse patterns request - http://www.rebol.com/article/0508.html

Thanks Pekr for drawing that to my attention.

If it's a patterns page, it shouldn't be R3 specific. If patterns 
require different implementations in R2 and R3, those can be filled 
in, or stubbed out with a note as to why it is either not needed 
or not worth the effort in one version or the other.

Every pattern should have an R2 and R3 version, with explanations.

Also, every new R3 operation should have an R2 equivalent in the 
pattern list. The parse proposals page can be mined for examples.

IIRC there's only one new R3 op that doesn't have an R2 equivalent, 
but it might not be implemented yet. Let me check.

I just didn't want to remove the R3-only comments without some discussion, 
in case there was a reason for them being there.

Yup, agreed. Just checked, LIMIT, the one proposal with no R2 equivalent 
hasn't been implemented yet.