On 17 Jan, 05:20 pm, te...@jon.es wrote:
"glyph" == glyph writes:
glyph> So, we still have some diagnosis to do on why you don't seem to
be
glyph> getting useful tracebacks from inlineCallbacks :). Now, not
only
glyph> can I not reproduce the bug, your reasoning doesn't make sense
any
gl
Hi all.
> "glyph" == glyph writes:
glyph> 1. More of this discussion should be on a ticket.
See http://twistedmatrix.com/trac/ticket/3622
Terry
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mai
> "glyph" == glyph writes:
glyph> Just to drive that point home, Terry, I found an interesting error
glyph> in your initial example. Your example does this:
glyph> info = sys.exc_info()
glyph> f = failure.Failure(*info)
glyph> but sys.exc_info() is a tuple of (type, value, traceback), whe
Hi Glyph
> "glyph" == glyph writes:
glyph> It sounds like the real issue here is that we don't have a channel
glyph> to communicate a "cleaned traceback" (i.e., failure with stringified
glyph> frames, but no traceback) from one bit of code to another?
Yes, now that I better understand what'
On 07:54 am, gl...@divmod.com wrote:
2. When filing that ticket, I'd really like a full working example of
inlineCallbacks not showing a traceback to play with
Just to drive that point home, Terry, I found an interesting error in
your initial example. Your example does this:
info = s
On 02:31 am, ra...@twistedmatrix.com wrote:
On Fri, Jan 16, 2009 at 7:28 PM, Phil Christensen
wrote:
Keeping references to tracebacks still has many potential pitfalls.
It's a fundamental problem: tracebacks refer to all their frames,
which refer to all their locals; this makes it *really* e
On Fri, Jan 16, 2009 at 7:28 PM, Phil Christensen wrote:
> The comment was this:
>
># added 2003-06-23 by Chris Armstrong. Yes, I actually have a
># use case where I need this traceback object, and I've made
># sure that it'll be cleaned up.
>self.tb = tb
>
> presum
Hi Phil
> "Phil" == Phil Christensen writes:
Phil> On Jan 12, 2009, at 8:36 PM, Terry Jones wrote:
>> # added 2003-06-23. See comment above in __init__
>> c['tb'] = None
>>
>> But the comment in __init__ seems to have been deleted.
Phil> The comment was this:
Phil> # added 2003-06-23 by Ch
On Jan 12, 2009, at 8:36 PM, Terry Jones wrote:
I think I've finally gotten to the bottom of why exceptions
sometimes lose
their tracebacks when using inlineCallbacks.
[snip]
We make a failure object, it has a
traceback, but after passing it to the errback method on a deferred
the
tracebac
On 13 Jan, 02:58 am, p...@bubblehouse.org wrote:
On Jan 12, 2009, at 8:36 PM, Terry Jones wrote:
I think I've finally gotten to the bottom of why exceptions sometimes
lose
their tracebacks when using inlineCallbacks.
[snip snip]
I'll stop for now. I have some suggestions for fixes, but I'm
On Jan 12, 2009, at 8:36 PM, Terry Jones wrote:
I think I've finally gotten to the bottom of why exceptions
sometimes lose
their tracebacks when using inlineCallbacks.
[snip snip]
I'll stop for now. I have some suggestions for fixes, but I'm
already in
over my head.
BTW, I get the impressi
I think I've finally gotten to the bottom of why exceptions sometimes lose
their tracebacks when using inlineCallbacks.
I've spent many hours trying to track down problems that result from
this. I find the code handling failures, deferreds, and inlineCallbacks
non-trivial even in isolation, let al
12 matches
Mail list logo
