pyggy Google Group

issue implementing the following in a .pyl file

socrat...@gmail.com (SocraticD@gmail.com) — Fri, 08 Feb 2008 19:46:40 UT

I'm parsing IIS logs and am having a hell of a time getting a regex
that will work for the page portion of the file.

given something like : 2007-02-09 23:59:59 GET /ABC.aspx or
2007-02-09 23:59:59 GET /Search/Styles/XYZ.css

i need to match on the blah.aspx, blah/blah.css, etc.. portion of the

Re: Getting some more info about from ParseError.

v.hais...@sh.cvut.cz (Václav Haisman) — Fri, 26 Jan 2007 08:22:12 UT

No activity at all :(
C'mon, somebody say something...

Getting some more info about from ParseError.

v.hais...@sh.cvut.cz (Václav Haisman) — Wed, 29 Nov 2006 08:42:33 UT

Hi,
I am using Pyggy to parse our simple DSL. Most of the time it is just
simple expressions. While the expressions are by the grammar everything
works fine. The problem is that when the expression is bad i.e. '(1 + 2'
or '1 + / 2' the thrown ParseError exception has very little info about
the error except the bad token and its text. It would be very useful if

Parsing incpmplete statements?

ned...@gmail.com (Ned Batchelder) — Wed, 29 Nov 2006 01:58:18 UT

I would like to use PyGgy to parse command-line input, similar to the
way SQL is parsed by a database command-line utility. When entering a
SQL statement, if no semi-colon is encountered, then the prompt changes
to indicate the statement is incomplete, and more input is collected.
I'm not that familiar with the interfaces between PyGgy and PyLly. Is

Re: Contextless between the grammar and the lexer

news...@lava.net (Tim Newsham) — Tue, 01 Aug 2006 17:37:51 UT

I don't have time for a full reply right now, I'll try to give
a more complete reply in about a week, but I wanted to mention
a few points...
This is the intended behavior. If the parse can be ambiguous the
grammar rules will have to be written differently. The number of
possible trees can grow quite large and I didn't want to separate

Re: Contextless between the grammar and the lexer

hum...@gmail.com (Humberto Abdelnur) — Tue, 01 Aug 2006 08:18:04 UT

Hi back,
As i told you early i was planning to modify the code in order to solve the
problems that i had.
During that i found and fix what i think was a bug.
It is when we have an ambiguous grammar and it is asked to process the tree
with the ambiguous flag. The problem is that it call the grammar function

Re: Contextless between the grammar and the lexer

hum...@gmail.com (Humberto Abdelnur) — Tue, 18 Jul 2006 19:09:10 UT

thanks for the quick reply.
What you say is right but I guess it does not apply to the use i want to
give to my tool. To let you understand my problem, what i want to do is to
take the ABNF of a RFC and automatically generate the parser (among with
other stuff) for the protocol in question. In such case i imagine that it

Re: Contextless between the grammar and the lexer

news...@lava.net (Tim Newsham) — Tue, 18 Jul 2006 18:00:47 UT

Yes. The parser will handle ambiguous grammars, but the lexer
does not handle ambiguous lexing rules. However, in your case
you can disambiguate entirely in the lexer:
Alternately you could separate the tokens into non-overlapping
tokens and then use those in your grammar. For this problem its
not very ideal, but it may be useful in other situations.

Contextless between the grammar and the lexer

hum...@gmail.com (humbol) — Tue, 18 Jul 2006 13:58:09 UT

Hi all,
I want to use this tool in order to generate from an ABNF grammar a
parser for it and i m running to some problems. My election was due
that together with DParser are the only GLR parser generators.
So far i saw that the rules specified earlier have precedence. My
problem is that there is no context with the grammar. To be more

Re: Yet Another ambiguous grammar

news...@lava.net (Tim Newsham) — Fri, 26 May 2006 15:56:09 UT

Sorry for the delay in replying. Rewriting your grammar in this
way should remove the ambiguity from your grammar. Its only the
case where something could be either a tuple (starting with
a parenthesis) or an expression (potentially starting with
a parenthesis) that should give rise to ambiguity.
Here the parser cannot disambiguate look at the lookahead

Re: Yet Another ambiguous grammar

d...@waveform.plus.com (Dave Hughes) — Sun, 21 May 2006 07:04:34 UT

Hi Tim,
Thanks for the quick response. I think it is possible to tell the
difference between a singleton tuple and a parenthesized expression,
but only within the context of some other operation. I'll try and
expand on my prior example to demonstrate:
The VALUES statement in DB2 allows one to generate a temporary table on

Re: Yet Another ambiguous grammar

news...@lava.net (Tim Newsham) — Sat, 20 May 2006 08:53:17 UT

As you describe it, the grammar is ambiguous. How do you tell the
difference between a singleton tuple and a parenthesized expression? As a
human, I cant tell the difference, so I can't really tell you how to make
a machine tell the difference. Can you provide an example of a case where
it is clearly a tuple and another case where it is clearly a parenthesized

Yet Another ambiguous grammar

d...@waveform.plus.com (Dave Hughes) — Fri, 19 May 2006 20:09:00 UT

I've been attempting to put together a parser to recognize a
substantial subset of an SQL dialect (specifically the DB2 dialect),
but have run into ambiguity problems fairly early on.
Here's a (much) reduced grammar demonstrating the issue (the constant
and identifier non-terminals are omitted, but I can provide the

Re: more ambiguous parser help

news...@lava.net (Tim Newsham) — Sun, 23 Apr 2006 18:14:12 UT

No. This is an entirely different grammar which does not have
any ambiguities.
Tim Newsham
[link]

Re: more ambiguous parser help

idade...@gmail.com (idadesub@gmail.com) — Sat, 22 Apr 2006 18:29:34 UT

So I found that if I move the commas down into the list branch, pyggy
no longer considers the grammar to be ambigous:
expression -> list;
list ->
COMMA CONSTANT COMMA
| COMMA CONSTANT COMMA CONSTANT COMMA
;
So does pyggy only consider the multiple branches under the same
grammar branch?