As to where it happens, look at
twisted.conch.recvline.RecvLine.connectionMade() and
twisted.conch.insults.insults.TerminalProtocol.makeConnection()
You could step on the RecvLine. initializeScreen(), but I have no idea what
the side effects are. (And of course if you bypass all or part of it, eve
s not connected anymore. As part of grokking the guts of this thing I've
been using for a decade...I'm curious to know why.
On Tue, Apr 28, 2015 at 7:43 AM, Brian Costlow
wrote:
> On Mon, Apr 27, 2015 at 4:55 PM, Glyph Lefkowitz
> wrote:
>
>>
>> Nothing strikes m
On Mon, Apr 27, 2015 at 4:55 PM, Glyph Lefkowitz
wrote:
>
> Nothing strikes me as obviously wrong about this code (except the
> "deferToThread" which seems *slightly*
> suspicious, since nothing in the example appears to have anything to do
> with threads, and whenever you get threads involved th
On Mon, Apr 27, 2015 at 8:26 PM, Itamar Turner-Trauring wrote:
> self.in_send_message seems like a potential source of bugs (can't see it
> being set to False on all branches here) and is also likely unnecessary.
>
self.in_send_message is redundant with self.waiting_id, which was added
later, an
Summary: I am having an issue writing data from an object based on
twisted's LineReceiver. Calling self.transport.write from the protocol,
some data makes it through, some does not. Using tcpdump, I am not seeing
the missing data cross the network interface.
Ubuntu LTS 14.04
Python 2.7.6
Twisted 1
