Re: MAXTABLE & Serious issues with bison 1.30

[Akim Demaille]

>>>>> "Tim" == Tim Van Holder <address@hidden> writes:

Hi Tim!

Happy new year.

Tim> We're in the process of stripping down a third-party yacc file
Tim> (i.e.  removing all actions) so we can use the grammar to do our
Tim> own processing.  But bison complained that the maximum table size
Tim> was exceeded.  Recompiling bison (1.28) with a greater MAXTABLE
Tim> (64K-1 instead of 32K-1) helped, and the grammar compiled fine.
Tim> Of course, it would be a LOT nicer if bison dynamically increased
Tim> the table size; depending on any hard-coded limit is sub-optimal.

This is something upon which we will all agree.  First of all, what is
the exact limit you're hitting?  There are several dependencies over
short, some of which being unsigned short.  That would be easy to
overcome.  The other limitations are much more delicate and require a
walk through the code.

Part of it has already been done, and Bison Next Generation is almost
ready.  But Bison 1.31 is scheduled beforehand.  As soon as we're done
with the noise around Bison, we will be able to release it.

Tim> Then I thought I might as well upgrade to bison 1.30, so I
Tim> downloaded the source, increased MAXTABLE again, and compiled.

1.30 is dead broken.  Give a try to the betas on alpha.gnu.org/gnu/bison.


Tim> So I thought I'd try CVS bison (knowing how Akim likes to add all
Tim> kinds of cool stuff to CVS versions of tools :-) ).  

:)

Currently there are two branches.  The trunk is much more
experimental.  Nonetheless, I _recommend_ it.

Tim> While the latter two problems were fixed, the crash still
Tim> existed.  

I am interested in getting the grammar, if that's possible.

Tim> In addition, the CVS repository had two other (fairly major)
Tim> issues. First off, it requires a pre-release version of autoconf;
Tim> this is unacceptable, as bison has no relation to autoconf.  

Yes, it has: me.

Tim> I don't mind if bison _uses_ a prerelease version, but then the
Tim> generated files should also be in CVS.  

That is the case of the 1.30 branch.  As far as the CVS experimental
version goes, it's OK to use it.  And to be honest, I'm fine with
releasing Bison using a beta of Autoconf too.

In other words, I'm not really sensitive to this being an issue.  We
need help and feedback and experience on Autoconf to release it.  GNU
M4, GNU Bison, GNU a2ps have all served to this end, and still do.

Tim> Secondly, a similar, but much worse situation exists in the src
Tim> directory, as parse-skel.y can ONLY be processed by CVS bison.

Wrong, it can be processed by the other branch, or, if you prefer,
1.31.


Tim> </rant> There.  I thinks that's all for now :-) Well, there is
Tim> one more thing: what about also renaming YYSTYPE when a
Tim> name-prefix is specified?  

I agree.

In a few words, Bison is being revisited.  There is still work, but
the past work is buying our freedom.  There are free lance developers
talking a lot on the Bison lists with plenty of ideas.  These people
don't realize their ideas were not implementable properly before, nor
was it even imaginable before all that dust was removed.

We are almost done, but we won't change anything (serious) before
we're completely done.  In particular, we aim at (i) more freedom upon
the output so that people can chose their skeletons, and (ii), more
techniques (not just LALR(1)).  Before, neither was _possible_


Tim> PS 1: I'm planning to update the Dutch translations to be more
Tim> palatable and up to date; do I send in a patch to you, or should
Tim> I go through li.org?  

The latter.

Tim> Do I need FSF papers to update a .po file?

Yep.  See the translation project.