World: r3wp

Something like this? (it's not parse based though)

    flatten: func [block] [
        head forall block [
            if block? block/1 [change/part block block/1 1]
        ]
    ]

I have a problem with parse not terminating the parsing. Here is 
my code for parsing CamelCase words:

rebol []

; CamelCase Test


test-text: "FirstWord test. This is a CamelCase test Text. CamelCase2 
is the base idea for a WiKi. CamelcasE"

upper-case: charset "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
delimiters:	charset " .,;|^-^/"
rest-chars: complement union upper-case delimiters

text: ""

parse/all/case test-text [
	some [

   copy camelcase-word [upper-case some rest-chars upper-case any rest-chars] 
   (
		 	if not empty? text [?? text clear text]
		 	print ["CamelCase word found:" camelcase-word]
		)

  | copy flowtext [any [rest-chars | upper-case] any delimiters] (
			append text flowtext
		)
	]
]

halt

Any idea why parse doesn't return?

[any [rest-chars | upper-case] any delimiters] is always true, even 
if there is no char left  at the end. But it does not move the cursor.

rebol []

; CamelCase Test


test-text: "FirstWord test. This is a CamelCase test Text. CamelCase2 
is the base idea for a WiKi. CamelcasE"

upper-case: charset "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
delimiter:	charset " .,;|^-^/"
rest-char: complement union upper-case delimiter

text: copy ""


camelcase-rule: [some [upper-case some rest-char upper-case any rest-char] 
delimiter]

parse/all/case test-text[
	some [ 
			copy camelcase-word  camelcase-rule
				(if not empty? text [?? text clear text]
		 		print ["CamelCase word found: " camelcase-word]
				)
			| 
			copy flowtext upper-case 
				(append text flowtext)
			|
			copy flowtext[any [rest-char | delimiter]] 
				(append text flowtext)
	]
]
halt

what about camelCAse?

Personally I prefer the way mediawiki does it ... using [[ .. ]] 
... instead of having strange cases in words

yes, I was also concerned about  A1CamelCase  but figured Robert 
 just needed to get thru his first question first

Thanks, for the fix. Sometimes it helps to get some distance by asking 
others :-))

I like CamelCase words. Simple to remember and use. IIRC camelCAse 
is not a valid CamelCase word. But anyway, it depends how I teach 
my users :-))

http://en.wikipedia.org/wiki/CamelCase... CamelCase is referred 
to UpperCamelCase, and camelCase is referred to as lowerCamelCase

Tom, your example doesn't terminate, like mine. The thing IMO is 
that the last Word is a CamelCase word and the 'end condition is 
somehow missed. It nevery reaches the halt.

If you do not want to change the parse rules, you can just add
	if not flowtext [halt]
before
	append text flowtext

I can change the parse rules. This is just a test script, the rule 
needs to be included in a broader parsing engine. So, it must return 
TRUE.

Robet you also have to worry about  YaBaDaBaDoCamelCases  (even and 
odd) 

to get it to return true ,  figure out what is left when the outter 
most  some finishes.
parse ...[
	some [
		...
	]
	copy remenant to end ( print remenant)
]


then make  the  your rule cpnsume the remenant ok if you  don't care 
just put a  
	to end
there

You can either put your parse in a catch [] and throw a true if not 
flowtext 
or something like this
parse/all/case test-text [
	some [

   copy camelcase-word [upper-case some rest-chars upper-case any rest-chars] 
   (
		 	if not empty? text [?? text clear text]
		 	print ["CamelCase word found:" camelcase-word]
		)

  | copy flowtext [some [rest-chars | upper-case] any delimiters] (
			append text flowtext
		)
		| copy flowtext [some delimiters] (
			append text flowtext
		)
	] to end
]

addendum/corrected
	] to end (if not empty? text [?? text])

getting the following error  when running Didec's delete email script 
against a mailbox with large number of emails (250+):internal limit 
reached: parse
Near: [parse data maillist
   addr-list]
Where: parse-mail-list

is this a rebol internal limit of should i start debugging?

probably a parse limitation

I think I've opened up mailboxes with over 400 emails before using 
Cerebrus' mailbox manager with no problems

oh well. thanks :)

what you could do, is extract Didier's implementation of the TOP 
command, and then get the first line of each header in your mailbox. 
 If it has the return-path set to <>, then note it in a list.  When 
finished, go thru and issue deletes on all of those.

thanks! I'll have a look at that.

is the To: line very, very long? there's a recursion limit in the 
parser for the address list. since you are probably not interested 
in parsing the To: header, maybe you can disable it in import-email.

Hmm... my parse still not termines the 'some part. I never reach 
the end. The problem is that the rest of the string is "" and this 
seems not to be handled.

Ok, got it. Now it works.

newby here: can anyone direct me to a sample of  code which matches 
a pattern over multiple text lines? I need to process a 5MB text 
file and remove all patterns of multiple consecutive email address 
es eg. [foo-:-my-:-com]; [foou-:-you-:-net] except the multiple email address 
string spans mulitple lines. Thanks for any pointers

and the multiple email address string occurs multiple times ;)

Michael, this is going to be a very general response to your request. 
 Review setting up parse rules and use something like...
   parse text any [rule1 | rule2 | rule3]

Here's some Parse documentation from the Rebol/Core guide to get 
you started.  Share your progress and questions, maybe a line of 
sample data or two and maybe I can be of more help.

link would help!!!   http://www.rebol.com/docs/core23/rebolcore-15.html

thanks Brock.. I wound up doing it in Perl, as I'm more familiar 
with it's regex support. The problem always seems I'm in a hurry 
with crisis response which is not a good learning environment ;)

Sometimes it helps to parse in two steps. a loop for each line-group 
and parsing that group seperately. becaus ethen 'to/'thru work better.

Can anyone give me some insight on how to use Brett's visual parse 
tools?

Can somebody explain me why 'parse fails in the first case and returns 
true in the second case ?

r: [any into ['a (print 'a)]]
t: [[a][a][a]]
print parse t r 
->
a
a
a
false

r: [any [into ['a (print 'a)]]]
print parse t r 
->
a
a
a
true 


In the second 'r(ule) the additional [ ] make it kind of explicit, 
but shouldn't return the first version true as well ? Am I forgeting 
something what 'parse "thinks" when looking at the first 'r(ules) 
? Thanks for hints. :-)

this really looks like violating the principle of the least surprise, 
I suggest you to submit it to Rambo

MichaelB, It is a parse bug for me.

As Ladislav suggested, I put it to Rambo. Thanks.

I have CSV file and I have trouble using parse one-liner. The case 
is, that I export tel. list from Lotus Notes, then I save it in Excel 
into .csv for rebol to run thru. I wanted to use:

foreach line ln-tel-list [append result parse/all line ";"]


... and I expected all lines having 7 elements. However - once last 
column is missing, that row is incorrect, as rebol parse will not 
add empty "" at the end. That is imo a bug ...

btw, why /all? shouldn't excel surround elements with spaces with 
quotes?

anyway, is it really a problem that the last column is missing?

I used csv = semicolon separated values and no quotes in-there ...

yes, it is, as I expect all lines having 7 elements ... once there 
is not such an element, I can't loop thru result ... well, one condition 
will probably solve it, but imo it is a gug .... rebol identifies 
;; and puts "" inthere, but csv, at the end, will use "value;", and 
rebol does not count that ...

gug = bug :-)

hmm, either use append/only, or as you say add it manually. submit 
this example to rambo if you think it's a bug.

append/only will not help, result of parse will varry, and it should 
not ...

I will put that in RAMBO then ...

append/only will, because pick returns none if a column is not present, 
and set works with that too

but I like to use flat structure and foreach [real name of vars here], 
so I need consistent record length :-)