On 01/10/2010 15:00, exar...@twistedmatrix.com wrote:
>> I hope this helps, do let me know if I should add it to an issue
>> somewhere...
>
> Can you at least provide a traffic capture recording an instance of this
> happening?
I'm afraid not, I didn't have the forsight to do this at the time, and
On 01:30 pm, ch...@simplistix.co.uk wrote:
>Hi Glyph,
>
>On 30/09/2010 19:52, Glyph Lefkowitz wrote:
>>>File "Twisted-8.2.0-py2.5-linux-x86_64.egg/twisted/internet/base.py",
>>>line 757, in runUntilCurrent
>>>call.func(*call.args, **call.kw)
>>>File "test_looping.py", line 24, in __call__
>>>del se
Hi Glyph,
On 30/09/2010 19:52, Glyph Lefkowitz wrote:
>> File "Twisted-8.2.0-py2.5-linux-x86_64.egg/twisted/internet/base.py",
>> line 757, in runUntilCurrent
>> call.func(*call.args, **call.kw)
>> File "test_looping.py", line 24, in __call__
>> del self.connector
>> exceptions.AttributeError: Bre
Chris,
My original reply jumped into the middle of the thread and I didn't completely
understand what you were asking. Let's get back to your original message:
On Sep 28, 2010, at 9:48 AM, Chris Withers wrote:
> The loop() function is supposed to be a "catch all and report" error handler.
> H
On 30/09/2010 15:33, exar...@twistedmatrix.com wrote:
>> 2010-09-30 15:07:03,161 ERROR : log (22194|7f41910b26e0):
>> Unhandled Error
>> Traceback (most recent call last):
>>File "test_looping.py", line 47, in
>> reactor.run()
>>File "/twisted/internet/base.py", line 1166, in
On 02:13 pm, ch...@simplistix.co.uk wrote:
>On 30/09/2010 14:39, Jonathan Lange wrote:
>>On Thu, Sep 30, 2010 at 2:36 PM, Chris Withers
>>wrote:
>>...
>>>
>>>Is there any way I can get both errbacks *and* exceptions handled
>>>nicely in
>>>my `loop` call?
>>
>>You know about defer.maybeDeferred,
On 30/09/10 15:13, Chris Withers wrote:
> On 30/09/2010 14:39, Jonathan Lange wrote:
>> On Thu, Sep 30, 2010 at 2:36 PM, Chris Withers
>> wrote:
>> ...
>>>
>>> Is there any way I can get both errbacks *and* exceptions handled nicely in
>>> my `loop` call?
>>
>> You know about defer.maybeDeferred
On 30/09/2010 14:39, Jonathan Lange wrote:
> On Thu, Sep 30, 2010 at 2:36 PM, Chris Withers wrote:
> ...
>>
>> Is there any way I can get both errbacks *and* exceptions handled nicely in
>> my `loop` call?
>
> You know about defer.maybeDeferred, right?
Yep, the problem is with `loop` implemented
On 30/09/2010 14:46, Phil Mayers wrote:
> On 30/09/10 14:36, Chris Withers wrote:
>>
>> Indeed, but, as I keep saying, I need to build a scheduler that's
>> resilient to errors in the tasks its running ;-)
>
> Sure.
>
>>
Most prominent is reactor.callLater.
>>
>> ...which I'm not actually us
On 30/09/10 14:36, Chris Withers wrote:
>
> Indeed, but, as I keep saying, I need to build a scheduler that's
> resilient to errors in the tasks its running ;-)
Sure.
>
>>> Most prominent is reactor.callLater.
>
> ...which I'm not actually using, it was just a small-as-possible way I
> could simu
On Thu, Sep 30, 2010 at 2:36 PM, Chris Withers wrote:
...
>
> Is there any way I can get both errbacks *and* exceptions handled nicely in
> my `loop` call?
You know about defer.maybeDeferred, right?
jml
___
Twisted-Python mailing list
Twisted-Python@t
On 30/09/2010 14:03, Phil Mayers wrote:
On 30/09/10 13:44, Phil Mayers wrote:
This is because (as you've discovered) there are circumstances when a
function is called in Twisted where the exception can't propagate "up"
to the caller, because the caller is no longer higher in the call stack.
I
On 30/09/10 13:44, Phil Mayers wrote:
> This is because (as you've discovered) there are circumstances when a
> function is called in Twisted where the exception can't propagate "up"
> to the caller, because the caller is no longer higher in the call stack.
> Most prominent is reactor.callLater.
On 30/09/10 11:48, Chris Withers wrote:
> On 30/09/2010 04:45, exar...@twistedmatrix.com wrote:
>> On 12:52 am, ch...@simplistix.co.uk wrote:
>>>
>>> Because I haven't found any permutation that doesn't result in the
>>> LoopingCall's calls to `loop` from stopping after the exception.
>>>
>>> I wou
On 30/09/2010 04:45, exar...@twistedmatrix.com wrote:
> On 12:52 am, ch...@simplistix.co.uk wrote:
>>
>> Because I haven't found any permutation that doesn't result in the
>> LoopingCall's calls to `loop` from stopping after the exception.
>>
>> I would be more than ecstatic to be proved wrong ;-)
On 12:52 am, ch...@simplistix.co.uk wrote:
>
>Because I haven't found any permutation that doesn't result in the
>LoopingCall's calls to `loop` from stopping after the exception.
>
>I would be more than ecstatic to be proved wrong ;-)
You keep saying the LoopingCall stops. It does not stop. It i
On 30/09/2010 00:31, Glyph Lefkowitz wrote:
>
> There are so many ways.
Yes, that's what I thought, which is why I was confused to keep on
getting "fix the code" responses when I'd already pointed out it wasn't
my code to fix, and I'd like to build a solution that caters even for
this eventuall
On Sep 29, 2010, at 6:56 PM, Chris Withers wrote:
> On 29/09/2010 22:06, exar...@twistedmatrix.com wrote:
>>> That's one side of things, sure, but how can I write a scheduler which
>>> handles the current situation?
>>
>> Beats me.
>
> So, if some buggy code that should be doing a deferred call
On 29/09/2010 22:06, exar...@twistedmatrix.com wrote:
>> That's one side of things, sure, but how can I write a scheduler which
>> handles the current situation?
>
> Beats me.
So, if some buggy code that should be doing a deferred callback/errback
instead raises an exception, you're basically scr
On 08:27 pm, ch...@simplistix.co.uk wrote:
>On 29/09/2010 18:31, exar...@twistedmatrix.com wrote:
>>Then you're talking about an API in Twisted which returns a Deferred
>>that sometimes doesn't errback when the implementation encounters an
>>error.
>>
>>Also, `failIfNotConnected` should never raise
On 29/09/2010 18:31, exar...@twistedmatrix.com wrote:
> Then you're talking about an API in Twisted which returns a Deferred
> that sometimes doesn't errback when the implementation encounters an
> error.
>
> Also, `failIfNotConnected` should never raise an exception.
>
> These sound like bugs.
>
>
On 05:16 pm, ch...@simplistix.co.uk wrote:
>On 29/09/2010 17:16, Phil Mayers wrote:
>>No.
>>
>>The problem is that your example is malformed.
>
>Well, it's not, it's the reality of the situation and one I'd like to
>protect against; "the scheduler must not die" is the rule I need to
>make
>work...
On 29/09/2010 17:16, Phil Mayers wrote:
> No.
>
> The problem is that your example is malformed.
Well, it's not, it's the reality of the situation and one I'd like to
protect against; "the scheduler must not die" is the rule I need to make
work...
> You do this:
>
>1. Create a deferred on t
On 29/09/10 16:56, Chris Withers wrote:
> On 28/09/2010 15:21, exar...@twistedmatrix.com wrote:
>>> But, more crucially, the looping call then appears to stop.
>>
>> The function you're looping over returns a Deferred that never fires.
>> The LoopingCall isn't stopped, it's waiting for the Deferred
On 28/09/2010 15:21, exar...@twistedmatrix.com wrote:
>> But, more crucially, the looping call then appears to stop.
>
> The function you're looping over returns a Deferred that never fires.
> The LoopingCall isn't stopped, it's waiting for the Deferred.
So, inlineCallbacks/generator things will o
On 01:48 pm, ch...@simplistix.co.uk wrote:
>Hi All,
>
>The attached .py file demonstrates a problem I'm having with a little
>scheduler I need to maintain.
>
>The loop() function is supposed to be a "catch all and report" error
>handler. However, when the async code initiated by doStuff throws th
Hi All,
The attached .py file demonstrates a problem I'm having with a little
scheduler I need to maintain.
The loop() function is supposed to be a "catch all and report" error
handler. However, when the async code initiated by doStuff throws the
AttributeError, what actually gets logged is:
27 matches
Mail list logo
