develooper Front page | perl.perl5.porters | Postings from April 2018

Re: [perl #132142] Bleadperl v5.27.3-34-gf6107ca24b breaksMLEHMANN/AnyEvent-HTTP-2.23.tar.gz

Thread Previous | Thread Next
Andreas Koenig
April 20, 2018 04:51
Re: [perl #132142] Bleadperl v5.27.3-34-gf6107ca24b breaksMLEHMANN/AnyEvent-HTTP-2.23.tar.gz
Message ID:
>>>>> On Thu, 19 Apr 2018 14:48:47 -0700, "Dave Mitchell via RT" <> said:

  > On Sun, Nov 19, 2017 at 06:10:28AM -0800, Sawyer X via RT wrote:
 >> On Fri, 17 Nov 2017 16:09:12 -0800, ilmari wrote:
 >> > Andreas Koenig <> writes:
 >> > 
 >> > > What is the state of this ticket? From looking at it it looks stalled.
 >> > > Was there any additional activity?
 >> > >
 >> > > Has anybody summarised? Reported to Marc? Provided a patch? Considered
 >> > > improving? Considered reverting?
 >> > 
 >> > I provided a patch in
 >> >, but
 >> > just realised there's a simpler way to do it, which I've attached.
 >> > 
 >> > As mentioned in that previous message, I'm not in the mood to confront
 >> > Marc over this, but Sawyer graciously offered to do that for me.
 >> > 
 >> > Sawyer, do you feel like sending these two patches to Marc and suggest
 >> > he applies one of them to keep AnyEvent working on blead?  Note that
 >> > AnyEvent's own test suite doesn't trigger the bug, but AnyEvent::HTTP
 >> > does.
 >> I didn't receive an email for this correspondence so I only saw the
 >> ping from Andreas. I have just sent an email to Marc with the latest
 >> patch, asking to apply the patch and release a new version. P5P was
 >> CC'ed on the email as well.

  > My understanding of the current state of this 5.28 blocker ticket is:

  > 1) A bug fix to blead removed an inadvertent user-visible difference
  > between '@b = sort @a' and '@a sort @a'; the latter is internally optimised,
  > but such optimisations shouldn't make visible changes to sort
  > behaviour.

It has been pointed out that the "internally optimized behaviour" of '@a
= sort @a' was documented as a way to get an in-place sort. It was
established behaviour for a long time. Given that it was both proudly
announced and well established, I find the term "bug fix" for its
removal problematic. This is a change in bahaviour. As such it may be a
bug fix for one party and a breakage for the other. Fair discussion
should try to balance the thinking and take this into account.

  > 2) AnyEvent relied on this now-fixed buggy behaviour;

The problematic terms continue.

  > 3) A patch has been privately submitted to Marc;

But the patch has issues. Discussion about it has been avoided and

  > 4) There has not been a new release of AnyEvent yet;

What could that probably mean?

  > 5) There was a brief discussion about the desirability of an explicit
  > in-place sort feature.

Why was it so brief? Originally the in-place sort was deemed as a
feature. To remove it, is now called a bug fix. I would say seeking for
solutions with the decisive extra bit of effort should be possible.

  > I propose

  > a) this ticket is removed from 5.28 blockers.
  > b) is kept open in case anyone wants to propose an in-place sort syntax or
  > mechanism.

I would suggest a revert with a chance to retry for 5.30, but with the
mandate to try to find a way to retain in-place sort. 

  > Hofstadter's Law: It always takes longer than you expect, even when you
  > take into account Hofstadter's Law.

Long live Hofstadter,

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About