r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Parse] Discussion of PARSE dialect

Claude
20-Sep-2010
[5240]
2.7.7.4.2
Steeve
20-Sep-2010
[5241]
Much easier with R3.
assuming, 
>> src: {Number : 10017
Name       : Disable Message Partner
Application: MXS
Severity   : Info
Type       : Alarm Event
Date-Time  : 20/09/10 12:39:43
GMT        : Mon Sep 20 10:39:43 2010}

then, 


>> construct parse copy src [return while[and[some #" " #":"] remove[some 
#" "]| skip]]
== make object! [
    Number: "10017"
    Name: "Disable Message Partner"
    Application: "MXS"
    Severity: "Info"
    Type: "Alarm Event"
    Date-Time: "20/09/10 12:39:43"
    GMT: "Mon Sep 20 10:39:43 2010"
]
Claude
20-Sep-2010
[5242x2]
thank you steeve but i need it for a production server  to parse 
log file for nagios
i would prefer to use rebol 2
Maxim
20-Sep-2010
[5244x4]
claude it might be because of copy/pasting... you are on linux.. 
did you just copy the code and paste it into the console?
the best is to copy it to a file and run it.
I just (re)tried it and it does work on my system...
(windows xp box)
Claude
20-Sep-2010
[5248]
well i on linux and on linux altme do work well with ctrl-c !!!!!
Maxim
20-Sep-2010
[5249x2]
but here we are parsing and any character code has to be loaded properly.. 
in theory it should work.. but it seems not...

add this just before the ":"

		here:
		(probe copy/part here 20)


it will print what is exactly at that point ... may provide clues 
as to why the ":" isn't matching...
note: I just tried to copy/paste the above in my R2 console .. it 
worked ok..
Claude
20-Sep-2010
[5251]
0>
1>
Number
2>
 : 10017^/Name       
.
done
Maxim
20-Sep-2010
[5252]
strange... it didn't match the spaces!
Steeve
20-Sep-2010
[5253]
parse/all ?
Maxim
20-Sep-2010
[5254x2]
already is using parse/all
claude... so, did you try to run it as a script?


one thing I would do... since this is a strange error is to retype 
this:

 " ^-"


in your editor... to make sure its not using the wrong ascii character 
on your os... it should not be a problem... but there is something 
weird going on here.
Claude
20-Sep-2010
[5256]
i do a copy/paste http://host4.altme.com/altweb/rebol3/chat210.html
into a file.r  and i execut it . i have got the same error
Maxim
20-Sep-2010
[5257x3]
steeve does it work for you?
oh.. he's gone... 

anyone else care to test it?  this is a strange bug...
this is what I get in my console....

0>
1>
Number
2>
3>
4>
5>
10017
6>
v-token: "Number"
v-content: "10017"

0>
1>
Name
2>
3>
4>
5>
Disable Message Partner
6>
v-token: "Name"
v-content: "Disable Message Partner"

0>
1>
Application
2>
3>
4>
5>
MXS
6>
v-token: "Application"
v-content: "MXS"

0>
1>
Severity
2>
3>
4>
5>
Info
6>
v-token: "Severity"
v-content: "Info"

0>
1>
Type
2>
3>
4>
5>
Alarm Event
6>
v-token: "Type"
v-content: "Alarm Event"

0>
1>
Date-Time
2>
3>
4>
5>
20/09/10 12:39:43
6>
v-token: "Date-Time"
v-content: "20/09/10 12:39:43"

0>
1>
GMT
2>
3>
4>
5>
Mon Sep 20 10:39:43 2010
6>
v-token: "GMT"
v-content: "Mon Sep 20 10:39:43 2010"
Claude
20-Sep-2010
[5260]
i will try it on the server tomorrow morning (it is a windows one 
;-) ) i will keep you informed
Maxim
20-Sep-2010
[5261]
k
Claude
20-Sep-2010
[5262]
thanks a lot for your tecahting
Maxim
20-Sep-2010
[5263]
no eprobml  ;-)
Claude
20-Sep-2010
[5264x2]
teaching
;-)
Anton
20-Sep-2010
[5266]
Maxim, your first big code works for me on Linux R2.
Maxim
20-Sep-2010
[5267]
ok, so its definitely somethings screwy with his c&p on that system
Anton
20-Sep-2010
[5268x3]
That is a distinct possibility.
I tested on 
View 2.7.7.4.2  (latest)
View 2.7.6.4.2  (long time favourite prior version)
View 1.3.2.4.2  (much older version)
Ways to identify the problem:

- In AltME, copy Max's entire post which contains the code. You can 
do this with a right click when no text is selected in the message.

  Switch to the rebol console and type:   checksum read clipboard:// 
     and tell us what you get.

- Then you can also type:  print mold read clipboard://    and examine 
what is printed carefully.

- Try to reproduce the problem with shorter code and shorter input. 
Two lines of input should do.
Anton
21-Sep-2010
[5271x3]
(I don't always see consistent behaviour with AltME and rebol on 
linux, by the way.)
(With regards to the clipboard, anyway.)
I copied Max's big message containing the big code.
>> checksum read clipboard://
== 2842420
Claude
21-Sep-2010
[5274]
maxim thank a lot it's works perfectly ;-) . yesterday i was tried 
i think
Maxim
21-Sep-2010
[5275]
cool
Claude
21-Sep-2010
[5276x5]
{Number : 10017
Name       : Disable Message Partner
Application: MXS
Severity   : Info
Type       : Alarm Event
Date-Time  : 20/09/10 12:40:57
GMT        : Mon Sep 20 10:40:57 2010
Text       :
Message Partner AlertsNagios - Disabled}
maxim just a last question
the last token is Text but the message is after a newline. how to 
take it with your parse rules
just for your information. i try this to parse error message of a 
swift alliance server
and check it with nagios
Maxim
21-Sep-2010
[5281x3]
you can replace the ":" rule with this:

		; end of token
		[
			
			[":" spaces newline]
			|
			":"
				
		]
but if you ever have a token without data, the whole parsing will 
fail, cause this rule will effectively (try to)  load the next token 
as data.
obviously we could alter the rules again to account for data-less 
tokens, but this would require a bit different structure.
Claude
21-Sep-2010
[5284]
great working ;-)
Maxim
21-Sep-2010
[5285]
oops... in the above text...    " this rule"   should read..  "the 
next rule"
Claude
21-Sep-2010
[5286]
if you have time to show me how i am ok. but for now i must take 
my children to school and go to work. thanks a lot again
Maxim
21-Sep-2010
[5287x3]
basically you have to create two complete (& and alternate) rule 
structures. and separate them with an "|" .


but you have to be sure that the first rule doesn't "pre-empt" the 
second one.... meaning that the first rule must not also match the 
second rule, or else, you will never reach the second rule.
for example..

some [["a" | "aa"]]


here we will never reach "aa" because "a" will be satisfied and the 
alternative will never be attempted ... so instead of matching "aa" 
you'd always match "a" twice .
where as specifying [some ["aa" | "a"]]  will always match "aa" IF 
there is still more than one "a" to parse... and will only ever reach 
"a" if the sequence is an odd number of "a" characters (or just one, 
obviously).


so "aaaa"  will match the "aa" rule twice, and "aaa"  will  match 
 "aa" then "a" .