On 21 February 2011 22:45, Jason Rennie wrote:
> Sounds like you just need a queue of pending commands and a state object for
> the currently executing command.
Just for the sake of completeness, this is what I've ended up with. No
explicit queues, and the state is kept with a lock:
cla
On 06:16 pm, michae...@gmail.com wrote:
On 21 February 2011 14:06, Jason Heeris wrote:
On 21 February 2011 21:30, � wrote:
Not intentionally:
�http://twistedmatrix.com/trac/ticket/3690
Interesting...
As an aside, the problem of serial port availability for unit tests is
something I've enco
On 21 February 2011 14:06, Jason Heeris wrote:
> On 21 February 2011 21:30, wrote:
>> Not intentionally:
>>
>> http://twistedmatrix.com/trac/ticket/3690
>
> Interesting...
>
> As an aside, the problem of serial port availability for unit tests is
> something I've encountered before too. I solve
(...catching up on this thread...)
On Mon, Feb 21, 2011 at 6:21 AM, Jason Heeris wrote:
> There's a connectionMade event when you do SerialPort(protocol, ...).
> There's no connectionLost event, even if you do that over and over
> again.
>
As Jean-Paul noted, that's a genuine bug with Twisted.
On 21 February 2011 21:30, wrote:
> Not intentionally:
>
> http://twistedmatrix.com/trac/ticket/3690
Interesting...
As an aside, the problem of serial port availability for unit tests is
something I've encountered before too. I solved it by using "socat" to
create virtual serial ports with kno
On 11:21 am, jason.hee...@gmail.com wrote:
>On 21 February 2011 16:59, Phil Mayers wrote:
>>I'm a little confused as to why this is a connectionless protocol, if
>>it's talking on a serial port? Surely it's a singleton connection,
>>with
>>no connect/disconnect events?
>
>There's a connectionMade
On 21 February 2011 19:18, Phil Mayers wrote:
> For example, if you have a line-based proto it might look like this:
Aha, I think you might just have answered my question before I asked
it. Which seems appropriate somehow.
I think the DeferredQueue does some of this for me, so I'll look into it.
On 21 February 2011 16:59, Phil Mayers wrote:
> I'm a little confused as to why this is a connectionless protocol, if
> it's talking on a serial port? Surely it's a singleton connection, with
> no connect/disconnect events?
There's a connectionMade event when you do SerialPort(protocol, ...).
The
On 21/02/11 10:39, Jason Heeris wrote:
> On 21 February 2011 15:58, Michael Thompson wrote:
>> The app should be waiting on the result of a deferred (which it
>> expects to fire with the result of the serial comms) so you can simply
>> errback that deferred.
>
> I get that bit, but my question is
On 21 February 2011 18:39, Jason Heeris wrote:
> (I would ask: do I even need a factory? But the fact is that I do,
> since all of the useful mixins and base classes rely on one being
> present.)
Just realised that actually, I'm using the TimeoutMixin, not the
TimeoutProtocol — no factory is tech
On 21 February 2011 15:58, Michael Thompson wrote:
> The app should be waiting on the result of a deferred (which it
> expects to fire with the result of the serial comms) so you can simply
> errback that deferred.
I get that bit, but my question is essentially: what triggers the
errback? If the
On 02/21/2011 06:26 AM, Jason Heeris wrote:
>
> So how I do I deal with protocol errors in a connectionless protocol?
I'm a little confused as to why this is a connectionless protocol, if
it's talking on a serial port? Surely it's a singleton connection, with
no connect/disconnect events?
I kno
On 21 February 2011 07:00, Jason Heeris wrote:
> On 21 February 2011 14:50, Michael Thompson wrote:
>> This might be better expressed as how do you write a protocol to
>> handle errors when using an unreliable transport. It down to your
>> protocol as to how you need to handle errors by for insta
On 21 February 2011 14:50, Michael Thompson wrote:
> This might be better expressed as how do you write a protocol to
> handle errors when using an unreliable transport. It down to your
> protocol as to how you need to handle errors by for instance sending a
> NACK or re-transmitting a request.
On 21 February 2011 06:26, Jason Heeris wrote:
> So how I do I deal with protocol errors in a connectionless protocol?
This might be better expressed as how do you write a protocol to
handle errors when using an unreliable transport. It down to your
protocol as to how you need to handle errors by
I'm still a little confused about exactly how to deal with errors and
responses using protocols and factories. I think a lot of my
misunderstanding stems from the fact that I'm using serial (and
inter-process) communications, both of which Twisted treats rather
differently from TCP based connection
16 matches
Mail list logo
