Ply-2.4 release candidate

[David Beazley]

I've put a Ply-2.4 release candidate online at:

http://www.dabeaz.com/ply/ply-2.4.tar.gz

Mostly this release just has a bunch of minor bug fixes. However,
the CHANGES file goes into more detail. If you're using PLY, please
give this download a try and let me know if anything breaks. I'll
probably make an official release in a few days or so.

Cheers,
Dave

[dhendriks]

This version is not python 2.3 compatible.

See issue #11: http://code.google.com/p/ply/issues/detail?id=11

[Michael Foord]

Hello Dave,

At Resolver Systems we've noticed a performance regression in the version 2.4 RC.

In a large spreadsheet here is the time spent inside PLY in 2.2, 2.3 & 2.4:

Ply version   Time (s)
--------------------------
2.2           ~3.8s
2.3           ~3.0s
2.4           ~3.5s

We haven't yet tried any of the optimisation flags.

Michael Foord
http://www.ironpythoninaction.com/

2008/5/4 David Beazley <da...@dabeaz.com>:

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk
http://www.ironpython.info

[David Beazley]

I would be quite interested in getting to the bottom of this
performance difference. I'm not aware of huge differences between
Ply-2.3 and Ply-2.4 other than a few very minor bug fixes (outlined
in the CHANGES file). Here are a couple of possibilities for things
that might affect performance in that way:

1. In Ply-2.3, The Lexer object is declared as a classic (old-style)
class. In Ply-2.4, it's a new-style class that inherits from object.
I have noticed a performance difference between the two styles of
classes.
2. Ply-2.4 added the ability to signal errors from within production
rules (see CHANGES 11/27/07). Adding this requires an extra check in
the parser which takes place around line 318.

If I had to guess, I'm going to say it's (2), but I'll need to do
some more careful benchmarking to study it. I'll go on record by
saying that I *DON'T* like the fact that you're seeing a 16%
performance hit going from 2.3 to 2.4. I want PLY to be fast as
possible within the constraints of still being usable.

If there is any way to separate your benchmark into lexing versus
parsing timings, that would be very useful to me. Also, if anyone
else has performance numbers of benchmarks to share, I would
definitely be interested.

Cheers,
Dave

[Michael Foord]

Thanks Dave.

I've forwarded this email to our developers list and we'll see what we can come up with.

Michael Foord
http://www.ironpythoninaction.com/

2008/5/6 David Beazley <da...@dabeaz.com>:

[Juanjo Conti]

I have dowload ply-2.4 and run the test of a project I am using it:

Ran 83 tests in 0.199s

FAILED (errors=83)

All errors are the same:

Traceback (most recent call last):
File "test.py", line 532, in test9
r1 = self.yacc.parse(s1)
File "/home/juanjo/python/ply/logic/ply/yacc.py", line 255, in parse
t = actions[state].get(ltype)
KeyError: 0

That line of code is from ply itself.

Juanjo
--
mi blog: http://www.juanjoconti.com.ar

[David Beazley]

Make sure you delete any previously generated parsetab.py files and try it again. If any stale data is left over from a previous PLY release, it can
cause it to fail miserably like that.

-Dave

On Wed 07/05/08 3:54 PM , Juanjo Conti jjc...@gmail.com sent:

[Brian Clapper]

On May 4, 2:47 pm, David Beazley <d...@dabeaz.com> wrote:
> I've put a Ply-2.4 release candidate online at:
>
> http://www.dabeaz.com/ply/ply-2.4.tar.gz

Thanks for the ability to preload the parsertab.py module, Dave. It
makes
distributing a PLY-based tool via an egg much nicer.

-Brian

Brian Clapper, http://www.clapper.org/bmc/
An idea is not responsible for the people who believe in it.