RFC: freeze bison version with docker container

--000000000000e8c71405ab5552b4
Content-Type: text/plain; charset="UTF-8"

Hi Porters,

Motivation:
Bison itself evolves, deprecating features (eg %pure-parser) , changing
output format.
Distributions do as well, providing different bison versions.
These days we can provide unified tooling via containers.

Commit (POC):
https://github.com/happy-barney/perl5/commit/4c8c41bcf0

Brano

--000000000000e8c71405ab5552b4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Porters,</div><div><br></div><div>Motivation:</div=
><div>Bison itself evolves, deprecating features (eg %pure-parser) , changi=
ng output format.<br></div><div>Distributions do as well, providing differe=
nt bison versions.</div><div></div><div></div><div>These days we can provid=
e unified tooling via containers.</div><div><br></div><div><div>Commit (POC=
):</div><div><a href=3D"https://github.com/happy-barney/perl5/commit/4c8c41=
bcf0">https://github.com/happy-barney/perl5/commit/4c8c41bcf0</a></div></di=
v><div><br></div><div>Brano<br></div></div>

--000000000000e8c71405ab5552b4--
0
happy
7/26/2020 10:03:44 AM
perl.perl5.porters 48174 articles. 1 followers. Follow

8 Replies
24 Views

Similar Articles

[PageSpeed] 58

On Sun, Jul 26, 2020 at 12:03:44PM +0200, Branislav Zahradn´┐Żk wrote:
> Hi Porters,
> 
> Motivation:
> Bison itself evolves, deprecating features (eg %pure-parser) , changing
> output format.
> Distributions do as well, providing different bison versions.
> These days we can provide unified tooling via containers.
> 
> Commit (POC):
> https://github.com/happy-barney/perl5/commit/4c8c41bcf0


It's not clear to me what you are proposing to change in the perl core
build process to "freeze bison version", or indeed what "freeze bison
version" means in the context of the perl build process.



-- 
Never work with children, animals, or actors.
0
davem
7/27/2020 11:12:30 AM
Dave Mitchell wrote:
> On Sun, Jul 26, 2020 at 12:03:44PM +0200, Branislav Zahradník wrote:
>> Hi Porters,
>>
>> Motivation:
>> Bison itself evolves, deprecating features (eg %pure-parser) , changing
>> output format.
>> Distributions do as well, providing different bison versions.
>> These days we can provide unified tooling via containers.
>>
>> Commit (POC):
>> https://github.com/happy-barney/perl5/commit/4c8c41bcf0
>
>
> It's not clear to me what you are proposing to change in the perl core
> build process to "freeze bison version", or indeed what "freeze bison
> version" means in the context of the perl build process.

This is some poor attempt complaining about "build reproducability" and 
searching for a problem to justify a predetermined solution (wouldn't it 
be cool to have React/Nodejs/AWS/Angular inside Perl's toolchain to 
modernize Perl?).

What is think OP is arguing, Bison is a not ISO/ANSI/IETF/W3C/IEEE 
specification, so Bison's maintainers never promised identical output 
bytestreams for identical input streams. Bison is SORT OF part of Perl's 
toolchain. 
https://perl5.git.perl.org/perl5.git/blob/HEAD:/regen_perly.pl But SORT 
OF, since P5P ships the readable OUTPUT of BISON in the repo, as a 
static file, some would argue this is "source code", others would argue 
P5P is shipping closed source binaries in the files perly.tab, perly.c, 
and perly.act since P5P doesn't include the source code of the tool that 
made them. I think OP is arguing that BISON's source code must be 
shipped with Perl 5 repo and compiled during a standard Configure/make 
(oh lets add Docker/add 32 bit color depth alpha layeer fancy logos to 
perl's toolchain), otherwise Perl is proprietary software.
0
bulk88
7/27/2020 3:18:15 PM
On Mon, 27 Jul 2020 11:18:15 -0400
bulk88 <bulk88@hotmail.com> wrote:

> What is think OP is arguing, Bison is a not ISO/ANSI/IETF/W3C/IEEE 
> specification, so Bison's maintainers never promised identical output 
> bytestreams for identical input streams. Bison is SORT OF part of
> Perl's toolchain. 

OP is also pointing out that developing perl currently requires a
version of bison older than is in debian/testing. I cannot develop perl
on my own laptop right now without manually installing an old bison in
/usr/local, because the one shipped by debian is too new for regen_perly

This needs a solution somehow.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/27/2020 3:45:50 PM
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> writes:

> OP is also pointing out that developing perl currently requires a
> version of bison older than is in debian/testing. I cannot develop perl
> on my own laptop right now without manually installing an old bison in
> /usr/local, because the one shipped by debian is too new for regen_perly

Does this need more than just bumping the version check in
regen/regen_perly.pl?  I bumped the maximum from 3.0 to 3.4 in July last
year, which was current in Debian unstable at the time.  We could even
be optimistic and allow any 3.x version, under the presumption that any
incompatible change would be a new major version.

There is the slight annoyance that regenerating the grammar with varying
Bison versions cause noise changes in the generated files, but I don't
think anyone has complained about that.

- ilmari
-- 
"A disappointingly low fraction of the human race is,
 at any given time, on fire." - Stig Sandbeck Mathisen
0
ilmari
7/27/2020 4:02:31 PM
--00000000000015e8d505ab6ea1f1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 27 Jul 2020 at 17:18, bulk88 <bulk88@hotmail.com> wrote:

> Dave Mitchell wrote:
> > On Sun, Jul 26, 2020 at 12:03:44PM +0200, Branislav Zahradn=C3=ADk wrot=
e:
> >> Hi Porters,
> >>
> >> Motivation:
> >> Bison itself evolves, deprecating features (eg %pure-parser) , changin=
g
> >> output format.
> >> Distributions do as well, providing different bison versions.
> >> These days we can provide unified tooling via containers.
> >>
> >> Commit (POC):
> >> https://github.com/happy-barney/perl5/commit/4c8c41bcf0
> >
> >
> > It's not clear to me what you are proposing to change in the perl core
> > build process to "freeze bison version", or indeed what "freeze bison
> > version" means in the context of the perl build process.
>
> This is some poor attempt complaining about "build reproducability" and
> searching for a problem to justify a predetermined solution (wouldn't it
> be cool to have React/Nodejs/AWS/Angular inside Perl's toolchain to
> modernize Perl?).
>
> What is think OP is arguing,
>

Nope,nothing from removed content :-) just reproducibility. Maintainer vs
contributor.
First one understands a tool and maintains tooling to produce stable
generated output without warnings, second one contributes new rules.

--00000000000015e8d505ab6ea1f1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, 27 Jul 2020 at 17:18, bulk88 =
&lt;<a href=3D"mailto:bulk88@hotmail.com">bulk88@hotmail.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dave Mitchell w=
rote:<br>
&gt; On Sun, Jul 26, 2020 at 12:03:44PM +0200, Branislav Zahradn=C3=ADk wro=
te:<br>
&gt;&gt; Hi Porters,<br>
&gt;&gt;<br>
&gt;&gt; Motivation:<br>
&gt;&gt; Bison itself evolves, deprecating features (eg %pure-parser) , cha=
nging<br>
&gt;&gt; output format.<br>
&gt;&gt; Distributions do as well, providing different bison versions.<br>
&gt;&gt; These days we can provide unified tooling via containers.<br>
&gt;&gt;<br>
&gt;&gt; Commit (POC):<br>
&gt;&gt; <a href=3D"https://github.com/happy-barney/perl5/commit/4c8c41bcf0=
" rel=3D"noreferrer" target=3D"_blank">https://github.com/happy-barney/perl=
5/commit/4c8c41bcf0</a><br>
&gt;<br>
&gt;<br>
&gt; It&#39;s not clear to me what you are proposing to change in the perl =
core<br>
&gt; build process to &quot;freeze bison version&quot;, or indeed what &quo=
t;freeze bison<br>
&gt; version&quot; means in the context of the perl build process.<br>
<br>
This is some poor attempt complaining about &quot;build reproducability&quo=
t; and <br>
searching for a problem to justify a predetermined solution (wouldn&#39;t i=
t <br>
be cool to have React/Nodejs/AWS/Angular inside Perl&#39;s toolchain to <br=
>
modernize Perl?).<br>
<br>
What is think OP is arguing, <br></blockquote><div><br></div><div>Nope,noth=
ing from removed content :-) just reproducibility. Maintainer vs contributo=
r.</div><div>First one understands a tool and maintains tooling to produce =
stable generated output without warnings, second one contributes new rules.=
<br></div></div></div>

--00000000000015e8d505ab6ea1f1--
0
happy
7/27/2020 4:15:08 PM
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:

> "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> writes:
>
>> OP is also pointing out that developing perl currently requires a
>> version of bison older than is in debian/testing. I cannot develop perl
>> on my own laptop right now without manually installing an old bison in
>> /usr/local, because the one shipped by debian is too new for regen_perly
>
> Does this need more than just bumping the version check in
> regen/regen_perly.pl?  I bumped the maximum from 3.0 to 3.4 in July last
> year, which was current in Debian unstable at the time.  We could even
> be optimistic and allow any 3.x version, under the presumption that any
> incompatible change would be a new major version.

So, I did this on my Debian Sid VM (and added -Wno-deprecated to shut up
a warning), and ran `perl regen_perly.pl`, but the resulting code does
not build.  There are several missing definitions, including YY_CAST and
yysymbol_kind_t, and the defintionn of yy_type_tab in perly.tab is
_completely_ mangled.  I'll have a look at fixing that...

- ilmari
-- 
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
 the consequences of."                              -- Skud's Meta-Law
0
ilmari
7/27/2020 5:32:59 PM
--000000000000ed091405ab6fc19a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 27 Jul 2020 at 13:12, Dave Mitchell <davem@iabyn.com> wrote:

> On Sun, Jul 26, 2020 at 12:03:44PM +0200, Branislav Zahradn=C3=ADk wrote:
> > Hi Porters,
> >
> > Motivation:
> > Bison itself evolves, deprecating features (eg %pure-parser) , changing
> > output format.
> > Distributions do as well, providing different bison versions.
> > These days we can provide unified tooling via containers.
> >
> > Commit (POC):
> > https://github.com/happy-barney/perl5/commit/4c8c41bcf0
>
>
> It's not clear to me what you are proposing to change in the perl core
> build process to "freeze bison version", or indeed what "freeze bison
> version" means in the context of the perl build process.
>
>
First I have to admit that "freeze" is probably not an exact word I had to
use.

Idea is about having the same environment (same tooling) for every
contributor regardless
of distribution.

For example, I regularly use 3 distributions, each of them having different
bison version - 3.0, 3.4, and 3.6. Latest two rise warning about deprecated
directive - quite confusing.

Putting generators into container allows different evolution patterns for
developer's localhost and source code.

Regarding changes to perl's development process, I think that every code
generator should be put
into a container, but that's not on table yet / right now.



>
> --
> Never work with children, animals, or actors.
>

--000000000000ed091405ab6fc19a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, 27 Jul 2020 at 13:12, Dave Mi=
tchell &lt;<a href=3D"mailto:davem@iabyn.com">davem@iabyn.com</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Jul 26=
, 2020 at 12:03:44PM +0200, Branislav Zahradn=C3=ADk wrote:<br>
&gt; Hi Porters,<br>
&gt; <br>
&gt; Motivation:<br>
&gt; Bison itself evolves, deprecating features (eg %pure-parser) , changin=
g<br>
&gt; output format.<br>
&gt; Distributions do as well, providing different bison versions.<br>
&gt; These days we can provide unified tooling via containers.<br>
&gt; <br>
&gt; Commit (POC):<br>
&gt; <a href=3D"https://github.com/happy-barney/perl5/commit/4c8c41bcf0" re=
l=3D"noreferrer" target=3D"_blank">https://github.com/happy-barney/perl5/co=
mmit/4c8c41bcf0</a><br>
<br>
<br>
It&#39;s not clear to me what you are proposing to change in the perl core<=
br>
build process to &quot;freeze bison version&quot;, or indeed what &quot;fre=
eze bison<br>
version&quot; means in the context of the perl build process.<br>
<br></blockquote><div><br></div><div>First I have to admit that &quot;freez=
e&quot; is probably not an exact word I had to use.</div><div><br></div><di=
v>Idea is about having the same environment (same tooling) for every contri=
butor regardless</div><div>of distribution.<br></div><div><br></div><div>Fo=
r example, I regularly use 3 distributions, each of them having different b=
ison version - 3.0, 3.4, and 3.6. Latest two rise warning about deprecated =
directive - quite confusing.</div><div><br></div><div>Putting generators in=
to container allows different evolution patterns for developer&#39;s localh=
ost and source code.</div><div><br></div><div>Regarding changes to perl&#39=
;s development process, I think that every code generator should be put</di=
v><div>into a container, but that&#39;s not on table yet / right now.<br></=
div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
<br>
<br>
-- <br>
Never work with children, animals, or actors.<br>
</blockquote></div></div>

--000000000000ed091405ab6fc19a--
0
happy
7/27/2020 5:35:54 PM
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:

> ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>
>> "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> writes:
>>
>>> OP is also pointing out that developing perl currently requires a
>>> version of bison older than is in debian/testing. I cannot develop perl
>>> on my own laptop right now without manually installing an old bison in
>>> /usr/local, because the one shipped by debian is too new for regen_perly
>>
>> Does this need more than just bumping the version check in
>> regen/regen_perly.pl?  I bumped the maximum from 3.0 to 3.4 in July last
>> year, which was current in Debian unstable at the time.  We could even
>> be optimistic and allow any 3.x version, under the presumption that any
>> incompatible change would be a new major version.
>
> So, I did this on my Debian Sid VM (and added -Wno-deprecated to shut up
> a warning), and ran `perl regen_perly.pl`, but the resulting code does
> not build.  There are several missing definitions, including YY_CAST and
> yysymbol_kind_t, and the defintionn of yy_type_tab in perly.tab is
> _completely_ mangled.  I'll have a look at fixing that...

I've now pushed a fixes for both Bison 3.7 (Debian Sid) (also tested
with and 3.6 (Debian Testing)) to the `smoke-me/ilmari/bison-3.7` branch
and https://github.com/Perl/perl5/pull/18000.

- ilmari
-- 
- Twitter seems more influential [than blogs] in the 'gets reported in
  the mainstream press' sense at least.               - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
  to a mainstream media article.                      - Calle Dybedahl
0
ilmari
7/27/2020 9:47:09 PM
Reply: