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

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

From:
Paul LeoNerd Evans
Date:
February 2, 2012 08:28
Subject:
Re: [perl #108470] Term::ReadLine should use AE instead of Tkforevent looping
Message ID:
20120202162814.GR8369@cel.leo
If you are not interested in the wider politics, you can stop reading
here.

On Thu, Feb 02, 2012 at 02:21:22AM +0100, Marc Lehmann wrote:
> - IO::Async can use e.g. AnyEvent::Loop to be compatible, which _has_
>   the required functionality.

As said in my other mail, no. It doesn't. But I have suggested what
would be required to support it, so hopefully we can resolve this there.

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

You did not warn me "long before".

The timeline is as follows:

  02 Aug 2011: IO-Async-Loop-AnyEvent 0.01 appears on CPAN. Already it
    applied the above-mentioned API abuse of AnyEvent, as I could find no
    other way to implement it. As this was API abuse, I documented this
    to the users of my module so they would be aware of it.
  
    Included in its bugs section is (verbatim):

    * watch_idle and unwatch_idle are unimplemented, as a satisfactory
      implementation does not seem easy to come by. AnyEvent doesn't
      portably guarantee a later-like event.

    * The implementation of the loop_once method requires the use of an
      undocumented method AnyEvent->one_event. This happens to work at
      the time of writing, but as it is undocumented it may be subject
      to change.

  12 Aug 2011: I mailed you to enquire some details on how we can
    prevent an infinite loop between IO::Async::Loop::AnyEvent and
    AnyEvent::Impl::IOAsync.

    You replied the same day, basically explaining that you felt it a
    hopeless cause to attempt to support such. I won't quote your reply
    without your permission, but the basic outline was to basically say
    "no, stop doing that", rather than offer any suggestion on how it
    should be solved.

    At this point I decided I wouldn't reply, as you were quite firm in
    your beliefs here. I felt that any further argument would only further
    entrench you to hold that position, and would be ultimately
    counterproductive.

  04 Oct 2011: AnyEvent 6.1 is released on CPAN. Part of its changes
    adds the 'die' line conditional on the presence of
    IO::Async::Loop::AnyEvent; the line of source code at the centre of
    this discussion.

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

You did not.

The first time you were aware of it was my mail dated 12th August, a
mere 10 days after it had ever appeared on CPAN, and your first
immediate reply was to tell me to stop and that you would actively look
for ways to prevent me continuing along that path. Thereafter, and
without further notification to me, you released a version of AnyEvent
that kills the entire process merely if that module is even present in
%INC.

I asked your opinion on how to fix a problem. You had a choice there;
you could have worked with me to find a solution, you could have ignored
my email, you could have said "no, that's silly please go away". Any of
these would have been acceptable solutions.

Instead, you _actively_ went out of your way to break cross
compatibility between these two modules. That is quite a step beyond. As
Matt Trout points out, it's one thing to scream loudly and tell someone
they've pointed a gun at their own feet, it is quite another entirely to
pull the trigger for them themself.

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

As you did to Rocco, I claim "citation needed".

Specifcally, I would like to know where it was you tried to explain to
me how to fix this module, other than by saying "don't do it". I believe
my "later" functionallity (see other mail) is sufficient to stop this
API abuse. Please either implement it, or explain why it is insufficient
and how else you propose to solve it.

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

That's OK. I am the author, and I will claim that responsibility. As I
believe I did do in the BUGS section; a section of whose current
implementation I will again quote:

 * The implementation of the loop_once method requires the use of an
   undocumented AnyEvent method (one_event before version 6, _poll
   thereafter). This happens to work at the time of writing, but as it
   is undocumented it may be subject to change.

   The loop_forever method does not rely on this undocumented method, so
   should be safe from upstream changes. Furthremore, if AnyEvent rather
   than IO::Async remains ultimately in control of the runtime, by
   waiting on condvars, this should not be problematic.

Is there anything about this description you find inaccurate? Or do you
agree with this statement of affairs?

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

Once again - neither myself, nor Matt, nor anybody else has ever asked
that you do support it. All we require is that you do not actively go out
of your way to kill it. A 'die' statement at require time conditional
merely on an %INC hash key, feels to me at least, to be doing just that.

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

Other than

  https://metacpan.org/source/MLEHMANN/AnyEvent-6.13/lib/AnyEvent.pm#L1396

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/



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