develooper Front page | perl.perl5.porters | Postings from February 2012

Re: [perl #108470] Term::ReadLine should use AE instead of Tkforevent looping

Thread Previous | Thread Next
Marc Lehmann
February 1, 2012 17:21
Re: [perl #108470] Term::ReadLine should use AE instead of Tkforevent looping
Message ID:
It's quite funny how authors of competing event-relatd libraries are
spreading major FUD about anyevent here, and some people go even so far as
wanting to remove AnyEvent from cpan, while tolerating non-free software
on cpan without any problem :)

It's less funny when so many people "know" my motivation without ever so
much as asking me, or actually looking at the code!

So here are the facts:

- AnyEvent supports IO::Async as backend for quite a while now, and still does so,
  nothing has changed, no event library is being singled out in any way.
- The required backend mechanics ("internals") for IO::Async::Loop::AnyEvent or
  what it's called have been REMOVED around the same time as the error has
  been added.
- IO::Async can use e.g. AnyEvent::Loop to be compatible, which _has_
  the required functionality.
- I warned IO::Async's author long before on why his module will break
  and why it is inevitable, and especially why it is a disservice to his
  users, and how to fix it. I didn't receive a reaction.
- POE contains similar code, and nobody complained for years.

So the error is actually just that: an error indicating that the module
will not work, because AnyEvent is NOT an event library and lacks the
functionality (which was present in earlier versions).

If there are newer versions of IO::Async::Loop::AnyEvent that happen to
work (which would require some changes to IO::Async, which is an event
library, so can't sit on top of anyevent and work at the same time), then
it's easy to remove this check, or indeed override the check itself, after
all, IO::Async::Loop::AnyEvent didn't shy back from hacking internals
before, so nothing really changed.

Now, all this shitting on my head when I actually _did_ secretly
support IO::Async::Loop::AnyEvent for as long as I could is... rather
dishonest: Suddenly, module authors have to support every third-party
module that abuses its internals? Seriously?

> In fact, IO::Async::Loop::AnyEvent was written to -avoid- problems.

Ah, but it's buggy and causes mysterious failures that are hard to
diagnose for users after the required functionality had been removed. This
has been reported, and the author of IO::Async::Loop::AnyEvent has had
ample time to fix it.

> I had a significant sized AnyEvent application. Since it was already running
> reliably on its existing Impl, I did not want to have to switch it to
> using AnyEvent::Impl::IOAsync (which still works imperfectly, but I don't
> have good repro cases for the problems I encountered and now never will,
> for reasons to be explained).

I am not the author of IO::Async::Loop::AnyEvent, and am not responsible
for it when it breaks. Making me responsible is highly disingenious.

> Then an AnyEvent upgrade killed it.

Yes of course - I do not support hacking around in internals, and I made
this very clear. When I do innovation then I will support exactly what
I said I will support. Making me responsbile for supporting third-party
modules that are known to abuse internals is disingenious.

> My client's answer to this was to ban all future use of AnyEvent within
> their codebase and to authorise a rewrite of the relevant daemon to a pure
> IO::Async

Such a pity for him, and you - I know it's a loss for both of you, but
frankly, you have to live with that.

> As such, I'm unlikely to ever find out why Impl::IOAsync doesn't work for
> that code and I am, on the whole, comfortable with this fact.

But it doesn't keep you from spreading fud publicly, eh?

In any case, the people who call for removal of AnyEvent are just
demonstrating their inability to think. Or maybe their ability to push
their own secret agenda - I would prefer if you would honestly say what
you want instead of resorting to fud tactics.

In addition, AnyEvent is free software and allows anybody to hack its
internals. It doesn't forbid anybody to use it in any way as long as the
license(s) are followed. Please don't forget basic facts like these.

And furthermore, yes, AnyEvent is a good candidate for inclusion in the
perl core for replacing ReadLine loop stuff. I don't think it should go
into the core because it is probably better maintained separately, but I
think it would not be hard to support AnyEvent optionally in those core
modules that could use event integration (the AnyEvent API has been stable
for many years now, and has a demonstrated committment to stay stable).

AnyEvent certainly is the way to go - it has been designed from the ground
up to support using it from modules, as opposed to all other existing
solutions, which are made for programs (the main program needs to be aware
of them). It really is singular in this respect.

It does not and has not implemented any prejuduice against any other event
loops - it simply embraces them, if possible.

So please get your facts straight, or else deal with the results.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /
      -=====/_/_//_/\_,_/ /_/\_\

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