Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On Sun, Jan 23, 2022 at 02:08:00PM +0100, Andreas Metzler wrote: > On 2022-01-16 Andreas Metzler wrote: > [...] > > I will probably followup with further wishes/comments later, not today > > but hopefully in next week. > [...] > > Hello Thomas, > > I think there are just two thing left pre upload: > > 1. The upload introduces an epoch because the upstream version went from > mmdd to 2.0.mmdd. Given that the new version scheme seems to > have found acceptance in e.g. Fedora /I/ do not see a better way. Could > you ask about the epoch on debian-devel (as per policy > https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly > ) - TIA. thanks - I will do this. > 2. It would be nice to merge the changelog entries for 1:2.0.20220109-1 > and 1:2.0.20220114-1, listing only the changes relative to what was yet > uploaded to Debian. (I would not consider this a must for sponsorship.) okay - a single upload comment would be simpler -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On 2022-01-16 Andreas Metzler wrote: [...] > I will probably followup with further wishes/comments later, not today > but hopefully in next week. [...] Hello Thomas, I think there are just two thing left pre upload: 1. The upload introduces an epoch because the upstream version went from mmdd to 2.0.mmdd. Given that the new version scheme seems to have found acceptance in e.g. Fedora /I/ do not see a better way. Could you ask about the epoch on debian-devel (as per policy https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly ) - TIA. 2. It would be nice to merge the changelog entries for 1:2.0.20220109-1 and 1:2.0.20220114-1, listing only the changes relative to what was yet uploaded to Debian. (I would not consider this a must for sponsorship.) cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On 2022-01-16 Thomas Dickey wrote: [...] > I reviewed the test-data differences, didn't see a problem, and verified > with cproto (which uses lex/yacc) that there are no differences. > So I updated the debian files to combine the two (just packaging one > "byacc" with backtracking). Great. [...] > For now, I'm just working on the Debian package of the current release :-) I will probably followup with further wishes/comments later, not today but hopefully in next week. cu Andreas
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On Sun, Jan 16, 2022 at 05:34:42PM +0100, Andreas Metzler wrote: > On 2022-01-16 Thomas Dickey wrote: > > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > [...] > > > > I would like to question the introduction of another binary package: > > > * "byacc2" seems to be a (newly introduced) Debiansm. Googling for > > > "byacc2" only finds links related to this RFS. > > > Ultimately that's because Debian's the only place where the older "btyacc" > > is packaged. > > [...] > > > Is /usr/bin/byacc2 incompatible with /usr/bin/byacc2? A quick glance > > > at the yacc.1 seems to suggests that /usr/bin/byacc2 is a backward > > > compatible extension of /usr/bin/byacc the only difference being > > > that it additionally supports > > > | -B create a backtracking parser > > > I've made some effort to keep > > the two compatible, but sooner or later will get some bug report related > > to their differences. Debian's the usual place for that sort of thing. > [...] > > ...with these caveats: > > > a) because of the backtracking support, the skeletons differ. > > > b) backtracking can be slow > > > However, Mageia and OpenSUSE provide packages for byacc with backtracking > > enabled. > [...] > > Hello Thomas, > > afaict from > https://src.fedoraproject.org/rpms/byacc/blob/rawhide/f/byacc.spec > Fedora also builds without backtracking: > | # Revert default stack size back to 1 > | # https://bugzilla.redhat.com/show_bug.cgi?id=743343 > | find . -type f -name \*.c -print0 | > | xargs -0 sed -i 's/YYSTACKSIZE 500/YYSTACKSIZE 1/g' > | > | %build > | %configure --disable-dependency-tracking my configure script doesn't use that option. I see it in the initial 2007 commit on Fedora, but it's not been part of any version that I've provided. (it looks like old copy/paste from somewhere). Since the Fedora package is reasonably up-to-date (last August), I didn't get involved with that (yet). > | %make_build > > I would think that is something you need to solve upstream. It cannot be > a good thing(TM) if the same version of byacc is incompatible between > different major distributions. Don't you agree? yes... but the reminder was useful > With "solve" meaning, that you decide whether you intend to provide a > limited-feature-set binary forever, and starting from there decide on > the naming of old (if it shall exist) and new byacc. I reviewed the test-data differences, didn't see a problem, and verified with cproto (which uses lex/yacc) that there are no differences. So I updated the debian files to combine the two (just packaging one "byacc" with backtracking). I'll probably change the default in the upstream configure script to turn on backtracking, so that the packagers who didn't sign onto backtracking will get it by default. Fedora, for instance. But that's another byacc-update away. I see in my to-do list that I have some documentation issues, as well as improving leak-checking (and the usual wishlist...), but nothing that requires a new release. For now, I'm just working on the Debian package of the current release :-) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On 2022-01-16 Thomas Dickey wrote: > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: [...] > > I would like to question the introduction of another binary package: > > * "byacc2" seems to be a (newly introduced) Debiansm. Googling for > > "byacc2" only finds links related to this RFS. > Ultimately that's because Debian's the only place where the older "btyacc" > is packaged. [...] > > Is /usr/bin/byacc2 incompatible with /usr/bin/byacc2? A quick glance > > at the yacc.1 seems to suggests that /usr/bin/byacc2 is a backward > > compatible extension of /usr/bin/byacc the only difference being > > that it additionally supports > > | -B create a backtracking parser > I've made some effort to keep > the two compatible, but sooner or later will get some bug report related > to their differences. Debian's the usual place for that sort of thing. [...] > ...with these caveats: > a) because of the backtracking support, the skeletons differ. > b) backtracking can be slow > However, Mageia and OpenSUSE provide packages for byacc with backtracking > enabled. [...] Hello Thomas, afaict from https://src.fedoraproject.org/rpms/byacc/blob/rawhide/f/byacc.spec Fedora also builds without backtracking: | # Revert default stack size back to 1 | # https://bugzilla.redhat.com/show_bug.cgi?id=743343 | find . -type f -name \*.c -print0 | | xargs -0 sed -i 's/YYSTACKSIZE 500/YYSTACKSIZE 1/g' | | %build | %configure --disable-dependency-tracking | %make_build I would think that is something you need to solve upstream. It cannot be a good thing(TM) if the same version of byacc is incompatible between different major distributions. Don't you agree? With "solve" meaning, that you decide whether you intend to provide a limited-feature-set binary forever, and starting from there decide on the naming of old (if it shall exist) and new byacc. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On Sun, Jan 16, 2022 at 08:07:42AM -0500, Thomas Dickey wrote: > On Sun, Jan 16, 2022 at 07:58:07AM -0500, Thomas Dickey wrote: > > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > ... > > > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 > > > > I thought it would be the safest approach. I've made some effort to keep > > the two compatible, but sooner or later will get some bug report related > > to their differences. Debian's the usual place for that sort of thing. > > fwiw, the reference files in test/*yacc show that backtracking doesn't > simply _add_ definitions: > > 155 files changed, 53852 insertions(+), 1785 deletions(-) > > (presumably reviewing those deletions would tell me whether two binaries > are still needed). reviewing one of those (e.g., a "calc" test-case which doesn't rely upon the backtracking features, and looking at the ".c" file), it seems to be properly ifdef'd so that the extra text is activated when the -B option is supported/used. There are a few spots where the code is reorganized to integrate the two flavors. There's one functional difference: The debugging output in the btyacc flavor goes to stderr, while the byacc flavor goes to stdout. (The manual page doesn't mention this - nor does it mention that -h goes to stderr) -- added a to-do... -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On Sun, Jan 16, 2022 at 02:39:04PM +0100, ابو الغيث عليّ wrote: > Hello Thomas, > > What is the difference between Yacc and Lex GNU tools. > And Byacc or Bison?! bison has a lot of non-yacc extensions. I don't believe any third-party has made a list of differences. Consider this like the difference between pmake and "gmake". > Berkeley still a source of truthful tools and clean mainstream. "Berkeley" is long out of the picture. The various BSDs package both byacc and bison. I see byacc here: MacOS base has this, which isn't the original byacc 1.9, but rather a copy of what was in NetBSD: https://opensource.apple.com/tarballs/yacc/ but ports have this byacc: https://github.com/macports/macports-ports/blob/master/devel/byacc/Portfile https://formulae.brew.sh/formula/byacc (fwiw, Apple rarely updates tools such as this except as required for POSIX certification). FreeBSD has this byacc both in base and ports: https://svnweb.freebsd.org/base/head/usr.bin/yacc/ https://svnweb.freebsd.org/ports/head/devel/byacc/ NetBSD has retired their copy of byacc 1.9 http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/yacc/?only_with_tag=MAIN in favor of this byacc: https://pkgsrc.se/devel/byacc OpenBSD has only byacc 1.9 copied from NetBSD, with minor changes: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/yacc/ (fwiw, OpenBSD's ports are a subset of pkgsrc, e.g., 9453 vs 18329). There's also DragonFly (also using this byacc): https://gitweb.dragonflybsd.org/dragonfly.git/blob/HEAD:/usr.bin/yacc/Makefile https://gitweb.dragonflybsd.org/dragonfly.git/tree/HEAD:/contrib/byacc > Do it keep byacc and blex. there's a similar story for lex, but I think that's off-topic. > Kind regards, > > > > > > > > > On Sun, 16 Jan 2022 at 14:09 Thomas Dickey wrote: > > > On Sun, Jan 16, 2022 at 07:58:07AM -0500, Thomas Dickey wrote: > > > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > > ... > > > > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 > > > > > > I thought it would be the safest approach. I've made some effort to keep > > > the two compatible, but sooner or later will get some bug report related > > > to their differences. Debian's the usual place for that sort of thing. > > > > fwiw, the reference files in test/*yacc show that backtracking doesn't > > simply _add_ definitions: > > > > 155 files changed, 53852 insertions(+), 1785 deletions(-) > > > > (presumably reviewing those deletions would tell me whether two binaries > > are still needed). > > > > -- > > Thomas E. Dickey > > https://invisible-island.net > > ftp://ftp.invisible-island.net > > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
Hello Thomas, What is the difference between Yacc and Lex GNU tools. And Byacc or Bison?! Berkeley still a source of truthful tools and clean mainstream. Do it keep byacc and blex. Kind regards, On Sun, 16 Jan 2022 at 14:09 Thomas Dickey wrote: > On Sun, Jan 16, 2022 at 07:58:07AM -0500, Thomas Dickey wrote: > > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > ... > > > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 > > > > I thought it would be the safest approach. I've made some effort to keep > > the two compatible, but sooner or later will get some bug report related > > to their differences. Debian's the usual place for that sort of thing. > > fwiw, the reference files in test/*yacc show that backtracking doesn't > simply _add_ definitions: > > 155 files changed, 53852 insertions(+), 1785 deletions(-) > > (presumably reviewing those deletions would tell me whether two binaries > are still needed). > > -- > Thomas E. Dickey > https://invisible-island.net > ftp://ftp.invisible-island.net >
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On Sun, Jan 16, 2022 at 07:58:07AM -0500, Thomas Dickey wrote: > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: ... > > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 > > I thought it would be the safest approach. I've made some effort to keep > the two compatible, but sooner or later will get some bug report related > to their differences. Debian's the usual place for that sort of thing. fwiw, the reference files in test/*yacc show that backtracking doesn't simply _add_ definitions: 155 files changed, 53852 insertions(+), 1785 deletions(-) (presumably reviewing those deletions would tell me whether two binaries are still needed). -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > On 2022-01-15 Thomas Dickey wrote: > [...] > > I am looking for a sponsor for my package "byacc": > > > * Package name: byacc > >Version : 1:2.0.20220114-1 > >Upstream Author : (Thomas E. Dickey) > > * URL : https://invisible-island.net/byacc/ > > * License : GPL-3, public-domain, other-BSD > > * Vcs : https://salsa.debian.org/debian/byacc > >Section : devel > > > It builds those binary packages: > > > byacc - public domain Berkeley LALR Yacc parser generator > > byacc2 - public domain Berkeley LALR Yacc parser generator, with > > back-tracking > [...] > > Hello Thomas, > > I would like to question the introduction of another binary package: > * "byacc2" seems to be a (newly introduced) Debiansm. Googling for > "byacc2" only finds links related to this RFS. Ultimately that's because Debian's the only place where the older "btyacc" is packaged. > * The packages are tiny (about 100k) and have no conflicting files. > /usr/bin/byacc2 and /usr/bin/byacc could be shipped in on binary > package. yes, I could do that. I don't believe that would interfere with using the alternatives mechanism for selecting "yacc". I made them separate because I thought that would be the expected way. > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 I thought it would be the safest approach. I've made some effort to keep the two compatible, but sooner or later will get some bug report related to their differences. Debian's the usual place for that sort of thing. > incompatible with /usr/bin/byacc2? A quick glance at the yacc.1 seems > to suggests that /usr/bin/byacc2 is a backward compatible extension of > /usr/bin/byacc the only difference being that it additionally supports > | -B create a backtracking parser ...with these caveats: a) because of the backtracking support, the skeletons differ. b) backtracking can be slow However, Mageia and OpenSUSE provide packages for byacc with backtracking enabled. (I should make a list of the other packages, but the rpm's are easy to check at the moment). -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On 2022-01-15 Thomas Dickey wrote: [...] > I am looking for a sponsor for my package "byacc": > * Package name: byacc >Version : 1:2.0.20220114-1 >Upstream Author : (Thomas E. Dickey) > * URL : https://invisible-island.net/byacc/ > * License : GPL-3, public-domain, other-BSD > * Vcs : https://salsa.debian.org/debian/byacc >Section : devel > It builds those binary packages: > byacc - public domain Berkeley LALR Yacc parser generator > byacc2 - public domain Berkeley LALR Yacc parser generator, with > back-tracking [...] Hello Thomas, I would like to question the introduction of another binary package: * "byacc2" seems to be a (newly introduced) Debiansm. Googling for "byacc2" only finds links related to this RFS. * The packages are tiny (about 100k) and have no conflicting files. /usr/bin/byacc2 and /usr/bin/byacc could be shipped in on binary package. * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 incompatible with /usr/bin/byacc2? A quick glance at the yacc.1 seems to suggests that /usr/bin/byacc2 is a backward compatible extension of /usr/bin/byacc the only difference being that it additionally supports | -B create a backtracking parser cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "byacc": * Package name: byacc Version : 1:2.0.20220114-1 Upstream Author : (Thomas E. Dickey) * URL : https://invisible-island.net/byacc/ * License : GPL-3, public-domain, other-BSD * Vcs : https://salsa.debian.org/debian/byacc Section : devel It builds those binary packages: byacc - public domain Berkeley LALR Yacc parser generator byacc2 - public domain Berkeley LALR Yacc parser generator, with back-tracking To access further information about this package, please visit the following URL: https://mentors.debian.net/package/byacc/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/byacc/byacc_2.0.20220114-1.dsc Changes since the last upload: byacc (1:2.0.20220114-1) unstable; urgency=medium . * work around git-buildpackage's absence of configurability regarding uscan. * fix lintian issues reported in update. Regards, -- Thomas Dickey -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
