Front page | perl.perl5.porters |
Postings from February 2012
Re: [perl #108470] Term::ReadLine should use AE instead of Tkforevent looping
From: Marc Lehmann
February 2, 2012 11:53
Re: [perl #108470] Term::ReadLine should use AE instead of Tkforevent looping
Message ID: 20120202195326.GC6672@schmorp.de
On Thu, Feb 02, 2012 at 04:28:16PM +0000, Paul LeoNerd Evans <email@example.com> wrote:
> 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 have explained to you that it can't be done, becaue AnyEvent can only offer
what is implementable with event loops, and I have also explained that it's
not even fixing any real problem.
> > - 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".
Well, did not "warn" you at all - I pointed out that your module creates
problems, multiple times, and explained to you _why_ it does so and what
needs to be changed.
You ignored that, so I added a diagnostic to warn users that they should
not use your module because it doesn't work.
> 12 Aug 2011:
> At this point I decided I wouldn't reply, as you were quite firm in
> 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.
So you disagree that three weeks is not "long before", ok, granted, I
feel different. However, since you freely admit that you didn'T bother
reeplying and resolving the problem, no amount of time would have made any
difference, so the point is moot, right?
> > 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.
Of course I did, until people started to suffer, and I got the burden of
> 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
Bullshit, this is what I wrote:
It's morally wrong, and I will certainly not help you making the
world worse for perl coders :) In fact, since I think it's so evil, I will
actively fight it :)
That doesn't mean I was looking for ways to prevent you continuing along
that path, and in fact, it's also not what I did then.
Now, that mail was 3kb in size, in which I explained why your approach is
wrong, and whats needed to fix it. Claiming I didn't explain it to you is
simply wrong (the e-mail is available on request, if you agree).
However, since the very approach is wrong, it can't be fixed by any simple
means, so much is true.
> without further notification to me, you released a version of AnyEvent
Well, you admitted you ignored me, so what's your point?
> 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
I did. You didnt like the solution and the explanation, so it is your
problem until people come to me and complain, then it is my problem, and
then I will act.
Sorry, but saying you didn't bother with a reply is not my idea of trying
to resolve a problem.
> my email, you could have said "no, that's silly please go away". Any of
> these would have been acceptable solutions.
I explained in many ways why the approach is wrong.
> Instead, you _actively_ went out of your way to break cross
> compatibility between these two modules.
Bullshit, the module was broken from the very beginning, and causing
> 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.
Not everything that limps along is an analogy.
What I did was simply add a diagnostic because your module breaks othe
rmodules using AnyEvent (or other event loops).
> > 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".
Condvars stop working, as well as programs using other event loops than
> 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".
Well, your module *is not fixable*, it's broken by design.
I have explained to you what needs to be done to actually make IO::Async use
AnyEvent, but you didn't like that solution.
That's not my problem, sorry.
> 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.
See my other mail, it can't be solved by the design you choose, and the
later function cannot be implemented.
> That's OK. I am the author, and I will claim that responsibility
Good, then how about doing so?
> * 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.
It does not work "at the time of the writing" vecause one_event wasn't
even implemented by all backends.
> Is there anything about this description you find inaccurate? Or do you
> agree with this statement of affairs?
I think you fundamentally misunderstand AnyEvent - you think AnyEvent is just
another event module, it is not. The closest thing AnyEvent has that is that
AnyEvent is just an adaptor to existing event loops. It does not block, like
> Once again - neither myself, nor Matt, nor anybody else has ever asked
> that you do support it.
When people run into problems and I have to waste my time debugging your code
then it's already too late. Not supporting it will not help.
And if you don't want me to support it, what exatcly is your problem? I do
not support it, I do not condone it, and it doesn't work (and di not work,
ever) - I am entirely fine with that state of affirs, although I would
have hoped you'd be interested in a real solution. You are not.
> 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.
I can change it into a warning if that makes you happy, but that will not fix
your module in any way.
In any case, if that is all you wanted, you could have mentioned that - I
was alway wwilling to tlak about things, keep in mind that you are the one
who refused to communicate.
> > It does not and has not implemented any prejuduice against any other event
> > loops - it simply embraces them, if possible.
> Other than
At least in firefox that just gives me the AnyEvent manpage - presumably
there is a supposed anchor L1396, but firefox doesn't find it.
You probably need to be more specific - if you refer to:
# IO::Async::Loop::AnyEvent is extremely evil, refuse to work with it
then please read what I wrote: "It does not and has not implemented any
prejuduice against any other event loops" - your module is not an event loop
in any sense of the word.
Your event loop is called IO::Async (actually an event framework), and it
does come with a numbe rof event loops.
AnyEvent is supposed to work just fine with IO::Async as event loop -
anything else is a bug. Please don't imply anything to the contrary.
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / firstname.lastname@example.org