Обсуждение: Odd historical fact about Bison
I've been poking at the project of using a reentrant flex scanner for PG. In order to make this work in a non-klugy way, it turns out that we have to also upgrade our Bison parser to be a "pure parser" --- otherwise Bison doesn't want to pass the additional scanner pointer to yylex(). I haven't finished getting it to work, but we're going to need at least these additions to gram.y: *************** *** 140,149 **** --- 147,160 ---- %} + %pure-parser %expect 0 %name-prefix="base_yy" %locations + %parse-param {base_yyscan_t yyscanner} + %lex-param {base_yyscan_t yyscanner} + %union { int ival; Now what surprised me about this is that it appears to work just fine in our oldest supported Bison version (1.875), although %parse-param and %lex-param are not documented in the 1.875 manual. Some digging in the bug-bison archives (hurrah for open source and the Internet --- it took only a few minutes to find this information) revealed that they pulled the documentation at the last minute before releasing 1.875, because they didn't want users to depend on these features just yet. This appears to have been due to some argument about whether the API was right, plus noticing that the documentation wasn't up to date everywhere. As best I can tell, they ended up not changing the API, and there is no reason we shouldn't depend on the feature and continue to claim that we work with bison >= 1.875. Does anyone feel uncomfortable with that? (It may be of mostly academic interest anyway, since I bet few people are still using such old bison versions. The only reason I've got one is for intentional trailing-edge compatibility testing...) regards, tom lane
Tom, > As best I can tell, they ended up not changing the API, and there is no > reason we shouldn't depend on the feature and continue to claim that we > work with bison>= 1.875. Does anyone feel uncomfortable with that? > (It may be of mostly academic interest anyway, since I bet few people > are still using such old bison versions. The only reason I've got one > is for intentional trailing-edge compatibility testing...) The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD and Solaris. What version of Bison are they shipping with? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com
Josh Berkus <josh@agliodbs.com> wrote: > The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD > and Solaris. What version of Bison are they shipping with? I don't know about them, but just so you know: kgrittn@INHOUSEAPPS:~> cat /etc/SuSE-release SUSE LINUX Enterprise Server 9 (i586) VERSION = 9 PATCHLEVEL = 3 kgrittn@INHOUSEAPPS:~> bison --version bison (GNU Bison) 1.875 . . . Now, this doesn't cause a problem for me, because if I'm not building from tarballs I can run "make distprep" on a more modern machine. And we've almost finished upgrading to SLES 10, anyway. -Kevin
On Friday 10 July 2009 00:58:01 Josh Berkus wrote: > Tom, > > > As best I can tell, they ended up not changing the API, and there is no > > reason we shouldn't depend on the feature and continue to claim that we > > work with bison>= 1.875. Does anyone feel uncomfortable with that? > > (It may be of mostly academic interest anyway, since I bet few people > > are still using such old bison versions. The only reason I've got one > > is for intentional trailing-edge compatibility testing...) > > The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD and > Solaris. What version of Bison are they shipping with? Most current solaris 10/5.10 ships with 1.875 Andres
Em Thu, 09 Jul 2009 19:58:01 -0300, Josh Berkus <josh@agliodbs.com> escreveu: > The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD and > Solaris. What version of Bison are they shipping with? In AIX 5.3: bison (GNU Bison) 1.875 []s Dickson S. Guedes http://pgcon.postgresql.org.br http://www.postgresql.org.br
>> The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD and >> Solaris. What version of Bison are they shipping with? Mac OSX 10.4.11 - GNU Bison version 1.28 -- Shane Ambler pgSQL (at) Sheeky (dot) Biz
On 7/11/09 12:24 PM, Shane Ambler wrote: >>> The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD >>> and Solaris. What version of Bison are they shipping with? > > Mac OSX 10.4.11 - GNU Bison version 1.28 Hmmm, given the number of other OSS things which won't install on 10.4 (like Firefox 3), I'm not that worried about this one. People can still install and run the binaries, yes? And Bison is easily upgraded via Fink or MacPorts. Plus we've required 1.875 for years anyway. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com
Shane Ambler wrote: >>> The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD >>> and Solaris. What version of Bison are they shipping with? > > Mac OSX 10.4.11 - GNU Bison version 1.28 > We have not supported any version less than 1.875 for as long as I have been working on Postgres. cheers andrew
On Sat, Jul 11, 2009 at 03:43:02PM -0400, Andrew Dunstan wrote: > >Mac OSX 10.4.11 - GNU Bison version 1.28 > > We have not supported any version less than 1.875 for as long as I > have been working on Postgres. We switched to 1.50 at some point in 2002 because we had to, ecpg had reached the limit of older bison versions. So OSX 10.4.11 doesn't work anyway. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!