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

World: r3wp

[I'm new] Ask any question, and a helpful person will try to answer.

Maxim
14-May-2009
[2318]
if you need parts of the data in your parens, the you add pointers 
to the data within the rules (use copy or here:) and se those within 
the processing parens.
mhinson
14-May-2009
[2319]
Do you know where Ladislav was heading with his suggestions? I understood 
what he was saying, but not what he was going to do with the structures 
he recomended.
Maxim
14-May-2009
[2320x4]
I understand his rules... look at steeve's rules, they already include 
parens, where he lists the data.
that is where you execute stuff.
so you'd just create a block before the parse, and dump the data 
which you want in there, using your new structure.
Am I making sense?
mhinson
14-May-2009
[2324]
So do you think Ladislav thought he had described everything he needed 
to? because he had a rule that would match part of the data & could 
be skipped on finding each match in turn somehow...
Maxim
14-May-2009
[2325x3]
it looks complete for a single record
but steeve's might actually be simpler and already includes the basis 
for what you want to do... it you try his rules on your data?
it = did
mhinson
14-May-2009
[2328x2]
I tried Peters rules & Steves first rules, then Ladislav gave me 
some more structure to it which seemed like a good idea when things 
get more complex. But I cant quite fit it all together.
This AltME client is hard work too, why dosn't the group have a web 
based forum, then I could access it on the PC where my development 
is being done too. AltME is a NoNo for corperate use.
Henrik
14-May-2009
[2330]
reboltalk.com would be a possibility if it wasnt so embarassingly 
full of spam
mhinson
14-May-2009
[2331]
I think one of the most confusing things about leaning Parse, is 
the occurance of  some & any & | , and the use of [ ]  

the constructs are quite straight forward, but the need for [ ]  
etc is a raw mystery to me.
Maxim
14-May-2009
[2332x4]
[ ] identifies rules which must ALL match as a group.
or a roll back occurs at the start of the [ ]  and tries the next 
rule following a "|" in the current rule (if any)
its pretty much the same as parens in regexp actually.
altme should use port 80 :-(
mhinson
14-May-2009
[2336x2]
it is installing non aproved applications that is the issue, and 
the need for a proxy config? perhaps that is covered.  I may just 
install it I suppose.
So the parse keeps going inside the [] till all the | are exhausted 
or it gets a match. then looks for the next | in the outer nesting 
of [] ??
Maxim
14-May-2009
[2338]
almost.  if one of the options match (  [option1 | option2 | option3] 
)

then the rule itself is considered a match and it won't attempt the 
other option.
mhinson
14-May-2009
[2339]
That is what I meant to say.
Maxim
14-May-2009
[2340]
so if the current rule is an option, then it will match too.

read the "|"  as: "continue if  previous rule didn't match"
mhinson
14-May-2009
[2341x4]
I read "any" matches 0 or more occurances --- I dont understand what 
that means in practice. it sounds like a loop perhaps?
I can see any digit  makes sense
but not any [long expression]
parse {aaa} any [[here: "a" (print here)] | [skip] ]  does not work 
for how I imagine.. I expect it to return aaa aa a
Maxim
14-May-2009
[2345x5]
it simply means that the following rule won't cause the current to 
fail even if it doesn't match any  [long expression]
that's what it returns here... ' :-/
note: above should be...

parse "aaa" [any [[here: "a" (print here)] | [skip] ]]
any outside of parse is something else.
even if it's similar in intent.
mhinson
14-May-2009
[2350]
my first any needs to be inside the [ ... that would seem to mike 
it apply to the "a"
Maxim
14-May-2009
[2351x3]
>> parse "aaa" [any [[here: "a" (print here)] | [skip] ]]
aaa
aa
a
== true
>> parse "zaz" [any [[here: "a" (print here)] | [skip] ]]
az
== true
>> parse "zzz" [any [[here: "a" (print here)] | [skip] ]]
== true
mhinson
14-May-2009
[2354]
that seems logica, but this does not
 parse {aaa}  [any[here: "a" (print here)] | [skip] ]
aaa
aa
a
Maxim
14-May-2009
[2355]
note that the rule returns true everytime.  it did not fail.
mhinson
14-May-2009
[2356]
why does it skip in my example?
Maxim
14-May-2009
[2357]
it doesn't... each time it hits "a" the first rule matches.
mhinson
14-May-2009
[2358]
which moves the Parse pointer on
Maxim
14-May-2009
[2359x2]
in your example, you have two rules, the any only applies to the 
first rule.


 the | skip basically will never be used, cause any will never fail.
any will repeat until it doesn't match, but it still doesn't fail.
mhinson
14-May-2009
[2361]
& if i use data of zzz it returns false...  I see why now, I think 
this is key to why I have been so frustrated with getting these rules 
to work.
Maxim
14-May-2009
[2362]
now be carefull... the parse function returns false IF it didn't 
match all of the input string.
mhinson
14-May-2009
[2363]
oh, no I dont, not if   any makes it always return true
Maxim
14-May-2009
[2364x2]
so the any actually didn't fail, and thus the skip never go to do 
its stuff.
other examples.

 >> parse "aza" [any [here: "a" (print here)] | skip]
aza
== false

>> parse "aza" [any [here: "a" (print here)]  skip skip]
aza
== true
mhinson
14-May-2009
[2366x2]
so why did the parse return false?
>> parse {zzz}  [any[here: "a" (print here)] | [skip] ]
== false
is it because the skip never get called so the parse is stuck on 
the first position or match & parse needs to move to the tail to 
return true?