World: r3wp

some space 
is even better to my mind

>> spam: "[15/May/2010 17:59:56] IP address 190.101.1.10 found in 
DNS blacklist SpamHaus SBL-XBL..."

== {[15/May/2010 17:59:56] IP address 190.101.1.10 found in DNS blacklist 
SpamHaus SBL-XBL...}
>> replace/all spam "]" "" replace/all spam "[" ""

== {15/May/2010 17:59:56 IP address 190.101.1.10 found in DNS blacklist 
SpamHaus SBL-XBL...}
>> blk: parse/all spam " "

== ["15/May/2010" "17:59:56" "IP" "address" "190.101.1.10" "found" 
"in" "DNS" "blacklist" "SpamHaus" "SBL-XBL..."]
>> date: blk/1
== "15/May/2010"
>> time: blk/2
== "17:59:56"
>> ip: blk/5
== "190.101.1.10"

nice ....

trim/with "[]" is better to remove things...

rebol and logs are like bread and butter

yeah ... I used it often ... read/lines is your friend :-)

yep nothing in the world can beat this combination

Structured data like logs, but Rebol shines even when parsing unstructured 
data

Yep, this is my script to dig the IP's inside the log files. I was 
quiet excited to see how natural it was to write this:

digits: charset "0123456789"

ip: [some digits "." some digits "." some digits "." some digits 
]

newList: [] 
existingList: []

files: []
foreach file read %. [
	if find file "security.log" [
		split: parse read file none
		foreach it split [
			parse it [[ip] (append newList it) ] 
		]
	]
]

Then, I said, read only from the last read, and pare the date/time. 
I wanted to parse date AND time at the same time" [15/May/2010 17:59:56] 
But I hit a snag because of the space in between. I don't want date 
and time separater beause rebol can parse the string into a date-time 
easy. The space gave me trouble, and the brackets too.

I would write th ip rule more strictly.
ip: [1 3 digits 3 [#"." 1 3 digits]]

Using the charset did not work. So I did this: parse/all txt [thru 
"[" copy found to "]" ]. And said to myself, time to learn more and 
could not find resources.

g so helpful.

Thanks.

What is the problem in parsing date and time at the same time? I 
somehow don't understand, if the solution does what you need, or 
you need further help?

lines: read/lines file
foreach line lines [ ... ]

Pekr, I'm done. Thanks. Initially I could not figure out how to escape 
the space character.

the funny thing (that confused Pekr) about it is, that you did not 
realize, that there was no need to escape the space character :-)

for Graham : delimeters = delimiters

I should've read the entire core manual before posting. Chapter 15 
addresses this clearly.

Processing text and rules seems so natural to rebol. I think I'm 
going to enjoy this.

Once you get used to PARSE, it's very hard to use other languages. 
:-)

I've uploaded my old Whitespace interpreter that I implemented in 
PARSE to GitHub: http://github.com/hostilefork/whitespacers/raw/master/rebol/whitespace.r

What's interesting about it is the comparison that can be made to 
implementations in other languages.  I've collected implementations 
of whitespace interpreters in several other languages (by other people) 
in that project: http://github.com/hostilefork/whitespacers/

Ok, continuing the discussion from "Performance" group, I'd like 
to ask for some help with parsing rebol format files.

Basically, I'd like to be able to extract a block near the beginning 
or end of a file, while minimizing disk access.

The files to be parsed could be large, so I don't want to load the 
entire contents, but chunks at a time.

So my parse rule should be able to detect when the input has been 
exhausted and ask for another chunk.

(When extracting a block near the end of a file, I'll have to parse 
in reverse, but I'll try to implement that later.)

And why you don't want to use the load/next which was advised?

Using LOAD/NEXT, I still have to use a O(n^2) algorithm. I'd now 
like to do my own parse, which can be O(n).

As far as I know, there is no way to instruct LOAD/NEXT to only read 
chunks from the file as necessary to load the next value.

Which is why, in that algorithm, I had to iteratively: load a chunk, 
append it and try LOAD/NEXT until it succeeded.
Which gives the algorithm O(n^2) performance.

My question for this O(n) parse algorithm is:
What rebol syntax do I need identify?
I suppose all I need is:
 - Comments (lines beginning with semi-colon ; )

 - Strings (single-line "" and multi-line {} ) watching out for escape 
 sequences eg. {^}}
 - Blocks

yes

Have I missed anything ?

just that comment may not be on line beginning so far

and you want to get just the first block? Skipping any content before 
it?

Ok, yes, it may be preceded by whitespace. That seems easy to deal 
with.

Well, I'd like the algorithm to be general enough to get any number 
of block in the file. So far I need just the first, second and last 
blocks.

And you need to parse the Altme's *.set files or something else as 
well?

The *.set files are what I need it for, yes.

I imagine it could be useful in other similar situations, so I'd 
like it to be pretty general.

I suppose a bonus functionality is to be able to get nested blocks.

(And a super bonus will be to get any datatype at any level, but 
I won't bother doing that until I need it.)

Um, actually, I remember years ago I wanted to load the rebol header 
of many files, avoiding loading the whole of each file.

Also char! must be supported:  #"["

So this algorithm could be used for that, too.

Must it ?

I think if I can parse single-line strings correctly, then a bracket 
inside won't cause a problem.

This means I'll be basically ignoring datatypes which allow strings 
in their syntax, and just jumping to the string part.

you are right

I don't think there's any way to make any type with a literal bracket 
in it (except blocks, of course). (But I am worrying about that a 
bit.)

I tried to make some words with a single unmatched literal bracket, 
or literal string delimiter, but I failed so far. They don't load, 
so they won't be in well-formed rebol format files.

And then I tried issues, files, and I can't do it there, either.

One caveat:

Misidentifying as a block, types like (what are they called?) "inline 
types"?
eg.  #[none]

If I don't recognise it as none! (or maybe issue!) , then I might 
accidentally take it as a block.

Or how about this:
#[block! [hello]]

I would probably want to extract  [hello], but if I don't recognise 
this form, then I'd get  [block! [hello]]  instead.