Thread: bison news
I just got the latest beta and it compiles ecpg grammar correctly! I had to make one change to my source though as bison no longer accepts a comma inside the token list. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> I just got the latest beta and it compiles ecpg grammar correctly!
This is good. Any word on when it will go to an official release?
BTW, I spent some time looking at the problem, and it seems the issue
is not overrun of any bison internal table, but failure to compress the
resulting "action table" into 32K entries. This means that the required
expansion from short to int is not just a cost paid while you run bison;
the actual table in the ecpg executable will double in size. I trust
they did not fix the problem in a way that causes *every* generated
parser to use an int[] rather than short[] action table ...
Also, it seemed to me that the most leverage on the size of the
compressed action table would be gained by reducing the number of
terminal symbols, more so than the number of rules. Dunno if there
is a lot you can do about that, but it's a thought.
regards, tom lane
On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote: > BTW, I spent some time looking at the problem, and it seems the issue > is not overrun of any bison internal table, but failure to compress the > resulting "action table" into 32K entries. This means that the required Ouch! This of course is not so much a problem for ecpg but for the backend should we run into the problem there too. > ... > Also, it seemed to me that the most leverage on the size of the > compressed action table would be gained by reducing the number of > terminal symbols, more so than the number of rules. Dunno if there > is a lot you can do about that, but it's a thought. Will look at it. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote:
>> BTW, I spent some time looking at the problem, and it seems the issue
>> is not overrun of any bison internal table, but failure to compress the
>> resulting "action table" into 32K entries. This means that the required
> Ouch! This of course is not so much a problem for ecpg but for the
> backend should we run into the problem there too.
As of CVS tip a few days ago, the backend's action table was about 27K
entries. So we have some breathing room, but certainly in the
foreseeable future there will be a problem...
regards, tom lane
OK, now that _a_ bison exists that works, how does this effect our release? I don't see preproc.[ch] in CVS. Do we need this new bison version on postgresql.org because Marc generates these as part of his install script? --------------------------------------------------------------------------- Tom Lane wrote: > Michael Meskes <meskes@postgresql.org> writes: > > On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote: > >> BTW, I spent some time looking at the problem, and it seems the issue > >> is not overrun of any bison internal table, but failure to compress the > >> resulting "action table" into 32K entries. This means that the required > > > Ouch! This of course is not so much a problem for ecpg but for the > > backend should we run into the problem there too. > > As of CVS tip a few days ago, the backend's action table was about 27K > entries. So we have some breathing room, but certainly in the > foreseeable future there will be a problem... > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, now that _a_ bison exists that works, how does this effect our
> release? I don't see preproc.[ch] in CVS. Do we need this new bison
> version on postgresql.org because Marc generates these as part of his
> install script?
I don't think we want a beta bison on postgres.org. Let's see if we can
hold out for a release...
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, now that _a_ bison exists that works, how does this effect our > > release? I don't see preproc.[ch] in CVS. Do we need this new bison > > version on postgresql.org because Marc generates these as part of his > > install script? > > I don't think we want a beta bison on postgres.org. Let's see if we can > hold out for a release... Well, we had better get it on or it will get zero testing, and we _need_ it for the 7.3 release of ecpg, because as I remember, we didn't have any other good backup plans. ;-) This may be a case where we have to do some beta testing on our own. I will grab the bison beta myself for my machine. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > This may be a case where we have to do some beta testing on our own. I > will grab the bison beta myself for my machine. I imagine that bison doesn't get a lot of beta testing, since people don't have a whole bunch of production grammars lying around that they want to upgrade at the earliest possible moment. So if we want to test it more, we could propagate it to our beta testers. -- Peter Eisentraut peter_e@gmx.net