Future of AnyEvent?

[Marc Lehmann]

On Wed, Jun 21, 2017 at 11:14:17PM -0600, Art Sackett <asackett at gmx.com> wrote:
> I skip a few days. Has there been, or is there any hope of, progress in
> keeping AnyEvent from being driven to extinction by p5p?

I think they are driving perl5 and CPAN to extinction, judging by the dozens
of modules that either don't compile anymore, don't run, crash or silently
corrupt data for every new perl release.

And no, I personally don't think there will ever be hope of progress until
the new perl6 people who took over p5p get kicked out and replaced by people
who care.

Since I professionally depend on perl, and p5p tries their utmost to break
existing software where they can, my personal strategy is to completely give
up on any new perl releases - I don't have the time to work around every new
API breakage every year, especially when it takes weeks or months of
debugging to find out what they broke again.

> 	https://rt.perl.org/Public/Bug/Display.html?id=119433#txn-1292226
> 
> ... summarizes the issue nicely, I think, even if the issue then at hand

No, that's just an example of a typical idiotic p5p FUD answer. Since then,
not only the "undocumented" AvARRAY has changed behaviour, av_fetch has
changed behaviour as well, as documented here:

   http://blog.schmorp.de/2016-12-29-griefing-the-perl-api.html

I am not sure how you can say it is resolved when now even modules crash
that did use the official API, and there isn't a documented/official
way to access array members anymore (the module in question now has to
hardcode undocumented internals). The API in question is completely broken
now.

It's also disingenuous of yves to claim that "most" of p5p developers do
not gratuitously break backwards compatiblity - I am one of them, or at
least, was, and most older ones are inactive or have been driven out (for
example, Tom Christiansen, the documentation guru, gave up long before
me), so "most" don't matter.

It's enough if a few people gratuitously break the API, again and again.

Note also that Yves is part of that problem - when pressured by both
me and Reini Urban (the cygwin perl maintainer) on the issue of his
security-through-obscurity patches that don't actually fix the underlying
security problem but slow down every perl program and broke hundreds of
modules on CPAN, he just claimed "it's secret, if you think it's insecure
then prove it by cracking it" - typical snake oil from somebody who has no
clue of cryptography.

And the end result is that both Reini Urban and me have been blocked on
perl5porters, and Reini Urban has got his blog killed on blog.perl.org
as well for talking clearly - american political correctness at work, no
dissent allowed. (Reini Urban took action much earlier than me and locked
perl on cygwin at version 5.14.2, the last version that kind of worked,
which I think is his way of doing "stableperl").

It's enlightening to read perlpolicy, especially "BACKWARD COMPATIBILITY
AND DEPRECATION", and then compare this with reality - this section has
been ignored for a decade now, and the perl pumpkin readily acknowledges
that the documented perlpolicy is and will be ignored, and asked for a
patch to change the wording to reflect the new reality, which I delivered.

My patch to fix perlpolicy was of course never applied (and nobody else
had the time to fix the perlpolicy), but what p5pers had time for was to
change their blocking policy to block anybody on a whim, witness:

       It is not enough to be factual. [...]
       
       Responding in kind to incivility is not acceptable.

What that boils down to is that they can block you for any reason (they
just have to call it a veiled insult, or incivil, or inacceptable) -
stating facts can be incivil according to them, and of course *they* can
insult *you* or spread FUD all day long, but if you complain about that,
you get blocked.

Note especially these words in perlpolicy:

       We would all love to unmake some mistakes we've made over the past
       decades. [...] Doing so without actively harming our users is
       nearly impossible.

       [...]

       Lately, ignoring or actively opposing compatibility with earlier
       versions of Perl has come into vogue. [...]

       Down this road lies madness.

And that is the path p5p is locked on for years now.

> has been resolved. What got me thinking about it again is that I just
> upgraded Debian to v9.0, which brought me perl 5.24.1, and AnyEvent
> install via CPAN gives me a failure of t/12_io_ioaio.t "not loadable".

I've not heard about that (and it works fine for me, being on stretch as
well), even with debians 5.24.1 perl (which I don't support).

There is an issue with TLS support that trips over a bug in Net::SSLeay and
has a workaround in CVS to be released soon, but that won't affect
t/12_io_ioaio.t.

So I guess the problem is elsewhere, and probably worht debugging a bit to
find out what's going on.

> Not that it matters, but having just been forced to address this problem
> in my own world has got me thinking that perl has managed to reduce
> itself to a toy language. As just one easy example:
> 
> 	$ perl -e 'say("hello")'
> 	Undefined subroutine &main::say called at -e line 1.
> 
> 	$ perl -e 'use 5.10.0; say("hello")'
> 	hello
> 
> We got a new pragma to turn on the new features. BUT when they yanked
> '.' from @INC it was without that consideration; we don't get 'use
> voodoo::security'.

Oh yes, removal of "." from @INC is a great example. When the CERT reporter
mailed me to "fix" my module, I honestly told him that I don't think this is
a security bug, and how is this security bug supposed to work, and was told
"I can't tell you, but when I showed it to p5pers, they were scared".

At that point, removal from "." was supposed to be optional, but obviously,
this has changed in the meantime, and of course causes enourmous breakage for
every program that uses "do EXPR" without ANY documented security issue, only
FUD.

I planned to blog on this, but found out that ignoring such issues
considerably imrpoves my life.

It's not uncommon to have idiot/fake CVE notices, for example,
rxvt-unicode once got CVE-2008-1142 because, hold your seat - if you open
a terminal window on the wrong DISPLAY (e.g. when logged in via ssh, and
rxvt/urxvt both default to :0), then the user owning that X session could
type in commands as you...

No kidding.

> Instead we're told by some in the community (whose opinions have
> prevailed) to blame ourselves if we get upbreakage, and by others in the
> broader community to blame ourselves if failure to update allows our
> systems to be cracked. If both of these assertions of who's to blame
> are true, then one who wishes to avoid that blame has but one rational
> choice: *stop using perl*.

That is more or less exactly my line of reasoning, with the added corollary
that I have an enourmous investment into perl, so I can't stop using it. And
of course I don't want to.

Thus stableperl, which is both a way of continuing to use it (it's my perl),
and stopping to use perl (upstream).

Believe me when I say that this situation was not created on a whim,
it took me many years to come to this decision, mostly because of the
hardships this created for users of my modules, which I do care about a
lot, otherwise I wouldn't stand the abuse and FUD from people who think
they are entitled for me to work for free on their probems (you know,
those people who think you have to apply their patches that break things
for everybody else because they insist on their broken system config and
so on).

But I simply cannot go on like this - I need a perl implementation I can rely
on, and stableperl has already turned out to be based on a bad perl release
(5.22), which still causes grief to me.

Now, this all sounds very frustrated and grumpy, because I am very
frustrated and grumpy, and by now rather extremely biased, of course,a nd
I am probably preaching to the choir here, at least partially, so don't be
offended by my direct words.

However, when I write "I cannot go on like this", I really meant it - since I
made stableperl (and gave up on newer perl releases) my *life* has improved
considerably - for the first time in years I can concentrate on getting
things done, and implementing and improving products, and not having to worry
and be stressed by constant bugs introduced by needless API changes.

If I had high blood pressure, so to say, then it's back to normal now.

> Which is why I'm asking about AnyEvent's chances of avoiding extinction.

I'm not seeing it go extinct, there is nothing in it that is known to
break with perl 5.24, I have no clue about 5.26, but would assume it works
on 5.26 as well, and the only known problem is libssl, which is unrelated
to the perl version and your problem (I tried the CVS version on stretch,
but I doubt there have been relevant changes).

But maybe it is going extinct for FUD reasons - many popular perl modules
aren't supported at all on any platform anymore, because they have fallen
into disrepair, and perl itself is kind of no longer suppoprting (older) perl
scripts, but for some reason, AnyEvent, which has a documented support policy
now, gets more flak for it.

So, you tell me, I would be interested in why you think AnyEvent is going
extinct - I massume it's only because of that test failure? Most of the CPAN
modules I install have test failures and always had them, to the point where
I mostly install with "notest", so I think a single failure is not going to
be a problem.

Coro is much more likely to go extinct, because frankly, I can no longer
care. I would like to, but every single time I do I get frustrated, and
after all, I am powerless.

> I can live without perl a lot easier than I can live without libev and
> libeio.

Lucky you then, both for not need perl as much as I do, and for libev and
libeio still being maintained and fairly stable, no? :)

In any case, I readily admit having lost, and perl5porters have won. I
think that p5pers are killing off perl5, and all left for me to do is save
whatever I can save, and that means me personally, and a version of perl
that I will maintain for as long as needed.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\