Skip Menu |
Report information
Id: 131919
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: alex.jakimenko [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [RFC] Returning Failure from failed P6-level .parse
Download (untitled) / with headers
text/plain 1.1k
See this commit: https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329 These roast commits: * https://github.com/perl6/roast/commit/1fb68c4b7a7c975f26fc81ad79f000958d1b4afd * https://github.com/perl6/roast/commit/b53616f8e67f9b19366008b3abf55400a3d6cd2b And this justification: * https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994 This blog post noticing the breakage due to the change: * https://gfldex.wordpress.com/2017/08/17/parsing-nothing/ And these thoughts about postponing it to v6.d: * https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160 I am confident that we will not be able to process this change and all potential breakage associated with it in ≈3 days before the release, so the revert is coming. Personally, I don't mind rereverting it afterwards for inclusion in 2017.09, assuming we make sure to fix all modules that were relying on Nils being returned. However, I do see the point for postponing it till v6.d. So should we feel adventurous and push this change as early as we can (in 2017.09, aftear at least one month)? Or is it better to be safe and wait for v6.d? Please discuss.
Download (untitled) / with headers
text/plain 652b
On Thu, 17 Aug 2017 08:50:48 -0700, alex.jakimenko@gmail.com wrote: Show quoted text
> See this...
See also timotimo++'s comment that TimToady cleared a revert if there were fallout: <timotimo> raschipi, gfldex, timtoady already said he'd retract the commit if there's ecosystem fallout, which you just demonstrated https://irclog.perlgeek.de/perl6/2017-08-17#i_15031866 Show quoted text
> Personally, I don't mind rereverting it afterwards for inclusion in > 2017.09
To me, it looks like a clear case for 6.d material. We made a promise to users that we won't make changes that break 6.c-errata changes and IMO the 6.c-errata roast changes due to this feature break that promise.
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 402b
On Thu, 17 Aug 2017 09:11:21 -0700, cpan@zoffix.com wrote: Show quoted text
> To me, it looks like a clear case for 6.d material. We made a promise > to users that we won't make changes that break 6.c-errata changes and > IMO the 6.c-errata roast changes due to this feature break that > promise.
Though, since it's a method, we get the whole "can't easily change behaviour of a method between languages" problem...
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Subject: Re: [perl #131919] [RFC] Returning Failure from failed P6-level .parse
Date: Thu, 17 Aug 2017 21:23:50 +0200
To: "Aleks-Daniel Jakimenko-Aleksejev (via RT)" <perl6-bugs-followup [...] perl.org>
Download (untitled) / with headers
text/plain 2.1k
Show quoted text
> On 17 Aug 2017, at 17:50, Aleks-Daniel Jakimenko-Aleksejev (via RT) <perl6-bugs-followup@perl.org> wrote: > > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev > # Please include the string: [perl #131919] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=131919 > > > > See this commit: https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329 > > These roast commits: > * https://github.com/perl6/roast/commit/1fb68c4b7a7c975f26fc81ad79f000958d1b4afd > * https://github.com/perl6/roast/commit/b53616f8e67f9b19366008b3abf55400a3d6cd2b > > And this justification: > * https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994 > > This blog post noticing the breakage due to the change: > * https://gfldex.wordpress.com/2017/08/17/parsing-nothing/ > > And these thoughts about postponing it to v6.d: > * https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160 > > > I am confident that we will not be able to process this change and all potential breakage associated with it in ≈3 days before the release, so the revert is coming. > > Personally, I don't mind rereverting it afterwards for inclusion in 2017.09, assuming we make sure to fix all modules that were relying on Nils being returned. However, I do see the point for postponing it till v6.d. > > > So should we feel adventurous and push this change as early as we can (in 2017.09, aftear at least one month)? Or is it better to be safe and wait for v6.d? Please discuss.
My feeling is to put this towards 6.d. And possibly have that coincide with 2017.09. The reason? This feature, like other features such as “is default” working on attributes, can *still* not be used on any module in the ecosystem, because one cannot be sure it won’t get run by a version of 6.c that does not have that feature already: case in point, not gaining about 5% in performance in Text::CSV because we cannot use “has $!foo is default()”. I think we’ve collected so many incompatible features by now that we need a 6.d earlier rather than later. At least from the API point of view. AKA, make things work for 6.d, then start optimizing again :-)
Subject: Re: [perl #131919] [RFC] Returning Failure from failed P6-level .parse
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Date: Thu, 17 Aug 2017 21:24:39 +0200
To: perl6-bugs-followup [...] perl.org
Download (untitled) / with headers
text/plain 775b
Show quoted text
> On 17 Aug 2017, at 18:11, Zoffix Znet via RT <perl6-bugs-followup@perl.org> wrote: > > On Thu, 17 Aug 2017 08:50:48 -0700, alex.jakimenko@gmail.com wrote:
>> See this...
> > See also timotimo++'s comment that TimToady cleared a revert if there were fallout: > <timotimo> raschipi, gfldex, timtoady already said he'd retract the commit if there's ecosystem fallout, which you just demonstrated > > https://irclog.perlgeek.de/perl6/2017-08-17#i_15031866 > >
>> Personally, I don't mind rereverting it afterwards for inclusion in >> 2017.09
> > To me, it looks like a clear case for 6.d material. We made a promise to users that we won't make changes that break 6.c-errata changes and IMO the 6.c-errata roast changes due to this feature break that promise.
Hear hear!
The change was moved to v6.d in this commit: https://github.com/rakudo/rakudo/commit/d2278b471cb0bd691dc7a1235fbcb9318ff5d61f

On 2017-08-17 08:50:48, alex.jakimenko@gmail.com wrote:
Show quoted text
> See this commit:
> https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329
>
> These roast commits:
> *
> https://github.com/perl6/roast/commit/1fb68c4b7a7c975f26fc81ad79f000958d1b4afd
> *
> https://github.com/perl6/roast/commit/b53616f8e67f9b19366008b3abf55400a3d6cd2b
>
> And this justification:
> * https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994
>
> This blog post noticing the breakage due to the change:
> * https://gfldex.wordpress.com/2017/08/17/parsing-nothing/
>
> And these thoughts about postponing it to v6.d:
> * https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160
>
>
> I am confident that we will not be able to process this change and all
> potential breakage associated with it in ≈3 days before the release,
> so the revert is coming.
>
> Personally, I don't mind rereverting it afterwards for inclusion in
> 2017.09, assuming we make sure to fix all modules that were relying on
> Nils being returned. However, I do see the point for postponing it
> till v6.d.
>
>
> So should we feel adventurous and push this change as early as we can
> (in 2017.09, aftear at least one month)? Or is it better to be safe
> and wait for v6.d? Please discuss.


I had to revert one of the nqp commits related to .parse: https://github.com/perl6/nqp/commit/d4d77b66c46c57de800b147df61fe486b4486acd

Here's a ticket for the module that was affected by the change: https://github.com/p6-css/CSS-Module-p6/issues/10

Most certainly we want this change back ASAP, but it had to be reverted for the release.



On 2017-08-19 05:36:36, alex.jakimenko@gmail.com wrote:
Show quoted text
> The change was moved to v6.d in this commit:
> https://github.com/rakudo/rakudo/commit/d2278b471cb0bd691dc7a1235fbcb9318ff5d61f
>
> On 2017-08-17 08:50:48, alex.jakimenko@gmail.com wrote:
> > See this commit:
> >
> https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329
> >
> > These roast commits:
> > *
> >
> https://github.com/perl6/roast/commit/1fb68c4b7a7c975f26fc81ad79f000958d1b4afd
> > *
> >
> https://github.com/perl6/roast/commit/b53616f8e67f9b19366008b3abf55400a3d6cd2b
> >
> > And this justification:
> > * https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994
> >
> > This blog post noticing the breakage due to the change:
> > * https://gfldex.wordpress.com/2017/08/17/parsing-nothing/
> >
> > And these thoughts about postponing it to v6.d:
> > * https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160
> >
> >
> > I am confident that we will not be able to process this change and
> > all
> > potential breakage associated with it in ≈3 days before the release,
> > so the revert is coming.
> >
> > Personally, I don't mind rereverting it afterwards for inclusion in
> > 2017.09, assuming we make sure to fix all modules that were relying
> > on
> > Nils being returned. However, I do see the point for postponing it
> > till v6.d.
> >
> >
> > So should we feel adventurous and push this change as early as we can
> > (in 2017.09, aftear at least one month)? Or is it better to be safe
> > and wait for v6.d? Please discuss.


It was removed completely for 2017.08 release.

Rakudo commit: https://github.com/rakudo/rakudo/commit/465d91abdfda038cb7feda35f7966be4ec39acf3
Discussion:  https://irclog.perlgeek.de/perl6-dev/2017-08-21#i_15048995
On 2017-08-19 15:31:01, alex.jakimenko@gmail.com wrote:
Show quoted text
> I had to revert one of the nqp commits related to .parse:
> https://github.com/perl6/nqp/commit/d4d77b66c46c57de800b147df61fe486b4486acd
>
> Here's a ticket for the module that was affected by the change:
> https://github.com/p6-css/CSS-Module-p6/issues/10
>
> Most certainly we want this change back ASAP, but it had to be
> reverted for the
> release.
>
> ♥
>
> On 2017-08-19 05:36:36, alex.jakimenko@gmail.com wrote:
> > The change was moved to v6.d in this commit:
> >
> https://github.com/rakudo/rakudo/commit/d2278b471cb0bd691dc7a1235fbcb9318ff5d61f
> >
> > On 2017-08-17 08:50:48, alex.jakimenko@gmail.com wrote:
> > > See this commit:
> > >
> >
> https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329
> > >
> > > These roast commits:
> > > *
> > >
> >
> https://github.com/perl6/roast/commit/1fb68c4b7a7c975f26fc81ad79f000958d1b4afd
> > > *
> > >
> >
> https://github.com/perl6/roast/commit/b53616f8e67f9b19366008b3abf55400a3d6cd2b
> > >
> > > And this justification:
> > > * https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994
> > >
> > > This blog post noticing the breakage due to the change:
> > > * https://gfldex.wordpress.com/2017/08/17/parsing-nothing/
> > >
> > > And these thoughts about postponing it to v6.d:
> > > * https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160
> > >
> > >
> > > I am confident that we will not be able to process this change and
> > > all
> > > potential breakage associated with it in ≈3 days before the
> > > release,
> > > so the revert is coming.
> > >
> > > Personally, I don't mind rereverting it afterwards for inclusion in
> > > 2017.09, assuming we make sure to fix all modules that were relying
> > > on
> > > Nils being returned. However, I do see the point for postponing it
> > > till v6.d.
> > >
> > >
> > > So should we feel adventurous and push this change as early as we
> > > can
> > > (in 2017.09, aftear at least one month)? Or is it better to be safe
> > > and wait for v6.d? Please discuss.




This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org