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
From:
Dave Mitchell
Date:
April 20, 2018 07:29
Subject:
Re: [perl #132142] Bleadperl v5.27.3-34-gf6107ca24b breaksMLEHMANN/AnyEvent-HTTP-2.23.tar.gz
Message ID:
20180420072908.GV25122@iabyn.com
On Fri, Apr 20, 2018 at 06:50:54AM +0200, Andreas Koenig wrote:
> 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.

Again, as the author of that optimisation,
1) it was my intention that it should make no user-visible difference
   apart from speed;
2) if I had been aware of the weakrefs behaviour at the time, I would
   have implemented the optimisation in a way that strengthened weak refs;
3) there is no documentation for the sort function which describes this
behaviour. The 5.10.1 perldelta mentions in-place sorting in the
'Performance Enhancements' section, and makes no particular claim about
whether weak refs are strengthened, or any implication that a change in
behaviour is intended.

> It was
> established behaviour for a long time.

Any bug fix must by definition change established behaviour.

> Given that it was both proudly
> announced and well established,

We'll have to disagree about the "announced" bit.

> 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.

My personal feeling is that avoiding unexpected differences in behaviour
between '@a = sort @a' and '@b = sort @a' outweighs the cost of the change
in behaviour. Other people may feel differently.

>   > 3) A patch has been privately submitted to Marc;
> 
> But the patch has issues. Discussion about it has been avoided and
> prevented.

Unusually for CPAN authors, Marc doesn't use any publicly-facing bug
tracking system for his modules, so it is hard to have a discussions about
such issues. Even when Marc isn't banned from this list, it is extremely
difficult to have any sort of technical discussion with him, since he
often resorts to personal attacks. I have, on this list, been repeatedly
called a liar by him. When I submitted a patch to him for one of his
modules, his initial reply was to tell me that my attitude was atrocious.
This sort of behaviour is a strong disincentive for anyone to engage with
him.

>   > 4) There has not been a new release of AnyEvent yet;
> 
> What could that probably mean?

Again, due to the lack of a public bug tracker, that's hard to guess.
Perhaps it's a poor patch; perhaps it a good patch which Marc hasn't had
time to apply yet?

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

Presumably because no-one could come up with any good suggestions.

> Originally the in-place sort was deemed as a
> feature.

Again, I disagree.

> 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.

Many things are possible. In practice, perl gets 1000 new RT tickets per
year, plus a further 150 security tickets; there are many things which
occupy our time and energy.

> 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. 

Does anyone else here any feelings either way?

-- 
"I do not resent criticism, even when, for the sake of emphasis,
it parts for the time with reality".
    -- Winston Churchill, House of Commons, 22nd Jan 1941.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About