Hilarious dream-logic (was Re: [Twisted-Python] [patch] (etc)

[glyph at divmod.com]

On Thu, 18 May 2006 21:25:07 +0200, Andrea Arcangeli <andrea at cpushare.com> wrote:
>> Andrea don't understand the purpose of that code (he's effectively reading
>> it backwards) and disabling it will make the situation with processes and
>> threads worse, not better.  Please don't apply this patch (or any of his
>> patches) to your own copies of Twisted.
>
>I didn't want to answer but I think I should to confirm that for this
>single patch (2/4 posted to python-twisted) they're right: I misread the
>code because defertothread(callback) means defer the callback to the
>thread, but callfromthred _doesn't_ mean to call the callback from the
>thread. callfromthread means to call the callback from the main event
>loop instead, great API naming I would say.

I understand that English isn't your first language, and I don't blame you for that, but you can find the documentation for these APIs here:

http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.IReactorThreads.html

and I think the descriptions are easy enough to understand.

The API logic is this: If you have a function and you are running in the reactor, but you want to CALL that function IN a THREAD, you use callInThread.

If you are running in a thread already, and you want to CALL a function that uses Twisted APIs (such as the reactor) FROM that THREAD, you use callFromThread.

Perhaps "invokeArgumentInThreadpool" or "dispatchCallableToReactorForThreadSafety" would have been better names, but I already wear out my keyboards fast enough.

>But for all other patches I posted, they should be applied to
>everybody's own twisted copy. Including the "no it isn't", since the bug
>exists and needs fixing or I get exceptions.

Since you've already demonstrated that you don't bother to read the documentation, write tests, or even understand the difficulties that may or may not exist before you submit a patch and apply it to your branch, I don't doubt that tracebacks happen, but I doubt that they're the problem you have identified.

The reason we require unit tests is the same reason scientists require *reproducible* experiments.  If you don't submit a test that can easily produce the traceback you saw, how else would we know that some local misconfiguration on your system wasn't causing it.

>If trac would have posted me updates via email ...

o/` If I only had a brain o/` da dee da dee da da dum o/`

Trac isn't perfect, but despite some minor complaints everyone else is managing to use it.  Like Twisted, Trac is written in Python, and if you want it to send you email, you can submit plugins and suggest that we use them.  Also, you can learn how to click on a bookmark, or even update an RSS feed.  Here's a single convenient page you can poll for all your tickets - including those that have been closed - and it does have an "RSS" button at the bottom so you can monitor changes:

    http://twistedmatrix.com/trac/query?reporter=andrea

>Overall using twisted for my project was a mistake.

And yet, and yet, and yet...

>One major core
>design problem it has is that it can't pass POLLERR|POLLHUP|POLLNVAL to
>the poll syscall unless POLLIN/POLLOUT are set too.

This is definitely a bug.  I wouldn't term it a "major core design problem", since I think it can be affected even without changing any external APIs.  Oddly enough, you submitted a bug in the tracker about it, which could have been found either with trac's search field or the above query.  In fact it's also the first hit for "POLLHUP POLLNVAL twisted" on google.  However, since both Trac and Google are far too much work for busy, important men like yourself, I've included a link here:

    http://twistedmatrix.com/trac/ticket/1662

A response has been posted within the last month, with a comment indicating that it will be fixed.

>This means that if I throttle the I/O I can't notice anymore when a disconnect happens.

The last paragraph of the ticket's description begins:

"Currently I don't strictly need this"

I doubt that we'd necessarily do anything that was important to you in particular, but *even you* have said that this isn't really that important.  It is hypocrisy of the worst order to bring it up in this discussion as a critical, severe problem that indicates the failure of the whole community.

>But the severe core design issues it has would be fixable and they are a
>minor problem compared to the behaviour of some elements of the
>community that exists around it. I don't need to enter the details
>myself, if doc/fun/Twisted.Quotes isn't enough, quoting emails like
>these is more than enough:

"I know you are but what am I!?!?"

You're the one who won't follow simple rules of politeness like "use the tracker" or "write unit tests if you require your patches be applied".

You're the one who throws around baseless insults and lies about other peoples' code.  Your factual errors about Nevow during the period when you were abandoning it were too numerous to even taxonomize -- when have I ever said anything nasty about CPUShare?

Even considering these abuses, we still haven't rejected your access to our resources, including our mailing list and our bugtracker.  In fact, as evidenced above, effort and thought is going into fixing issues that you've reported!

And yet, because somebody once told a fart joke on an IRC channel, you *still* have the gall to say that our "behavior", as a whole community, is too difficult for anyone to deal with.  Since explicit is better than implicit, why don't I just say this right out: you are a humorless, self-important, obnoxious jerk.  You need to seriously consider your own behavior before you start insulting others.

>Specifically I never said unittest are a waste of time

Ahem.  From http://twistedmatrix.com/pipermail/twisted-web/2006-January/002389.html

"""
>So I'm going to fork twisted into a private twisted-CPUShare branch for
>my own server use where I won't have to waste time to fix bugs
"""

At least as I understood it, "waste time" == "write unittests" in that context, since the whole point of this fork is that you didn't want to write tests to get bug-fixes applied.  You are correct that you didn't ever write, word for word, "unit tests are a waste of time" but numerous other things you said implied it.