Here is the gist https://gist.github.com/jalvo2014/9816011
I will get started on that debugging documentation, thanks John Alvord On Thu, Mar 27, 2014 at 11:13 AM, Jeffrey Kegler < [email protected]> wrote: > I may need the gist (minimal if that's convenient). If the lexer > patterns are right, the left paren inside a string should be slurped up > with the string, so that the rule match does not happen. You may also want > to check, now that you are using LATM, to see if you're actually looking > for a string at the right point. > > There's a doc that outlines how to go about tracing/debugging a grammar: > https://metacpan.org/pod/distribution/Marpa-R2/pod/Tracing.pod -- > particularly useful in this case may be the trace_terminals argument and > the show_progress() method. > > Hope this helps, jeffrey > > On 03/27/2014 10:51 AM, John Alvord wrote: > > I am making steady progress thanks to your help. Now parentheses require > some different logic > > I have a text fragment > > *VALUE NT_Services.Display_Name_U *IN > ('MSSQL$SQL027301','SQLAgent$SQL027301','SQL Server Agent (SQL027303)','SQL > Server (SQL027303)') > > BNF rule looks like this > > <value_condition_in> ::= '*VALUE' <attribute> '*IN' '(' > <comma_separated_list> ')' action => do_value_in > > The problem I have is that there is a ')' within the quoted string and > it is matching on this rule... so only a partial string is worked on. > That results in a parse error. [The good news for me is that this is > happening on maybe 0.5% of the data.] > > I will put a gist if needed, > but was hoping someone could point me to an example of handling this sort > of case. > > > John Alvord > > > > > > > > > On Wed, Mar 19, 2014 at 10:23 AM, John Alvord > <[email protected]>wrote: > >> Thanks also, Ron. I have a lot to learn about good Perl style. My >> examples are just the starting point in an investigation. >> >> After some head scratching, I installed Marpa::R2 2.082000 [instead of >> 2.080000 - current Activestate level] and things started working very much >> better indeed. It was an Activestate on Windows learning experience - had >> to install mingw64 and then run cpan. Not a big deal. >> >> Now things are moving along nicely. >> >> This mini language translates to SQL of sorts. That SQL is used to >> gather performance data - mostly from Linux/Unix/Windows/zOS agents. There >> is filtering involved and sometimes filtering happens on the agents and >> sometimes the data gets transmitted to a server for filtering. BIG >> performance differences. There has been a question forever about how to >> determine agent filtering or server filtering - so people can fix/avoid >> performance problems. This will be folded into a public example tool which >> any customer can use... and I can use on problem reports. >> >> Also, I have collected dozens of categories of cases that cause >> performance problems or just plain do not work. A later extension will >> expose those in sort of a "critic" report. >> >> Thanks again!! >> >> John Alvord >> >> >> On Tue, Mar 18, 2014 at 5:48 PM, Ron Savage <[email protected]> wrote: >> >>> Actually, I made some other changes: >>> >>> use Data::Dumper::Concise; # For Dumper(). >>> >>> And: >>> >>> sub My_Actions::do_attribute >>> { >>> my($hash, $t1, $t2, $t3) = @_; >>> >>> =pod >>> >>> print "do_attribute()\n"; >>> print '$t1: ', Dumper($t1); >>> print '$t2: ', Dumper($t2); >>> print '$t3: ', Dumper($t3); >>> >>> =cut >>> >>> return [$t1, $t2, $t3]; >>> } >>> >>> sub My_Actions::do_basic { >>> my ($hash, $t1, $t2, $t3, $t4 ) = @_; >>> >>> =pod >>> >>> print "do_basic()\n"; >>> print '$t1: ', Dumper($t1); >>> print '$t2: ', Dumper($t2); >>> print '$t3: ', Dumper($t3); >>> print '$t4: ', Dumper($t4); >>> >>> =cut >>> >>> return [$t1, $t2, $t3, $t4]; >>> } >>> >>> The output is: >>> >>> Setting trace_terminals option >>> Setting trace_values option >>> Lexer "L0" accepted lexeme L1c1-3: '*IF'; value="*IF" >>> Lexer "L0" discarded lexeme L1c4: ws >>> Lexer "L0" accepted lexeme L1c5-10: '*VALUE'; value="*VALUE" >>> Lexer "L0" discarded lexeme L1c11: ws >>> Lexer "L0" accepted lexeme L1c12-33: id; value="i5OS_IOA_Cache_Battery" >>> Lexer "L0" accepted lexeme L1c34: '.'; value="." >>> Lexer "L0" accepted lexeme L1c35-39: id; value="State" >>> Lexer "L0" discarded lexeme L1c40: ws >>> Lexer "L0" accepted lexeme L1c41-43: '*EQ'; value="*EQ" >>> Lexer "L0" discarded lexeme L1c44: ws >>> Lexer "L0" forgave lexeme L1c45-49: id; value="Error" >>> Lexer "L0" accepted lexeme L1c45-49: literal_word; value="Error" >>> Popping 4 values to evaluate R2:4@1-7C11@6, rule: 2: basic_condition -> >>> [Lex-1] attribute comparison compare_string >>> Calculated and pushed value: [ >>> '*VALUE', >>> [ >>> [ >>> 'i5OS_IOA_Cache_Battery' >>> ], >>> '.', >>> [ >>> 'State' >>> ] >>> ], >>> [ >>> '*EQ' >>> ], >>> [ >>> [ >>> 'Error' >>> ] >>> ] >>> ] >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "marpa parser" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- > You received this message because you are subscribed to the Google Groups > "marpa parser" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "marpa parser" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
