holger krekel That may be a good idea. I am currently hunting down a deeply nested Exception problem and knowing which frames get created executing which code helps in understanding what's going on. Without lots of print-statements this would be very difficult (not that it really gets easy :-). are you tracking these frames from within the appspace or object space ? it would probably be helpful to have a tool like ping's cgitb (which he/I ) hacked into a text-mode version, and to have it for both object and appspace, no? __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Hello Hunter, On Thu, Jul 10, 2003 at 05:32:05AM -0700, Hunter Peress wrote:
There are several problems with the current way exceptions are printed. For example the tracebacks are incredibly long. This is due to the fact that a number of nested interpreter-level calls are needed for each application-level call. Internally, the OperationError can record which lines in the traceback correspond to which application-level call; the problem is mainly how to display it reasonably. Another problem is that application-level frames and multimethod calls are extremely confusing in the traceback -- you can't even know which multimethod was called, because they all involve the same code in multimethod.py. I would suggest we add debugging commands in the code of pypy; something that would allow us to build a custom traceback, and also possibly record the call tree. I'm thinking about explicit "pypy.debug.enter/leave" calls around multimethod calls and calls to application-level functions. Customizing pdb also looks like a good idea. Uncaught exceptions should automatically throw us into our debugger. A bientot, Armin.
Hello Armin, [Armin Rigo Sat, Jul 12, 2003 at 02:08:56PM -0700]
... not your fault, but Mr. Hunter Press cited me without proper indication ...
It really depends on what you want to debug, e.g. opcodes, interpeter-level or object-space level stuff or interactions between all of this etc.
I think that having easy-to-use "aspect-oriented" traces would be nice. Actually i'd like to say: def __init__(self): t = functrace('frame construction') t.dump('self.co_*') # or so def eval_code(self): t = functrace('frame') and this means that 1) functrace gets the name of the function by relying on 'self' beeing in the parent's frame locals (you may explicitely specify that of course) 2) the given strings are the "aspects" which you can use to parametrize what is beeing displayed 3) we rely on DECREF(t) when the scope is left (you don't want to do a try-finally block all the time, do you?). or alternatively call "t.close()" explicitely such a mechanism - reyling somewhat on introspection - would allow for a pretty flexible tracing parametrization depending on what you want to debug.
Customizing pdb also looks like a good idea. Uncaught exceptions should automatically throw us into our debugger.
Didn't Michael already do something like that? cheers, holger
holger krekel <hpk@trillke.net> writes:
Can't you use Python's setprofile/settrace stuff for this? Would make PyPy even slower, of course :-)
Yeah, should be possible.
Eh, I started. There's not much useful there, yet. Cheers, mwh -- I've even been known to get Marmite *near* my mouth -- but never actually in it yet. Vegamite is right out. UnicodeError: ASCII unpalatable error: vegamite found, ham expected -- Tim Peters, comp.lang.python
Hello Hunter, On Thu, Jul 10, 2003 at 05:32:05AM -0700, Hunter Peress wrote:
There are several problems with the current way exceptions are printed. For example the tracebacks are incredibly long. This is due to the fact that a number of nested interpreter-level calls are needed for each application-level call. Internally, the OperationError can record which lines in the traceback correspond to which application-level call; the problem is mainly how to display it reasonably. Another problem is that application-level frames and multimethod calls are extremely confusing in the traceback -- you can't even know which multimethod was called, because they all involve the same code in multimethod.py. I would suggest we add debugging commands in the code of pypy; something that would allow us to build a custom traceback, and also possibly record the call tree. I'm thinking about explicit "pypy.debug.enter/leave" calls around multimethod calls and calls to application-level functions. Customizing pdb also looks like a good idea. Uncaught exceptions should automatically throw us into our debugger. A bientot, Armin.
Hello Armin, [Armin Rigo Sat, Jul 12, 2003 at 02:08:56PM -0700]
... not your fault, but Mr. Hunter Press cited me without proper indication ...
It really depends on what you want to debug, e.g. opcodes, interpeter-level or object-space level stuff or interactions between all of this etc.
I think that having easy-to-use "aspect-oriented" traces would be nice. Actually i'd like to say: def __init__(self): t = functrace('frame construction') t.dump('self.co_*') # or so def eval_code(self): t = functrace('frame') and this means that 1) functrace gets the name of the function by relying on 'self' beeing in the parent's frame locals (you may explicitely specify that of course) 2) the given strings are the "aspects" which you can use to parametrize what is beeing displayed 3) we rely on DECREF(t) when the scope is left (you don't want to do a try-finally block all the time, do you?). or alternatively call "t.close()" explicitely such a mechanism - reyling somewhat on introspection - would allow for a pretty flexible tracing parametrization depending on what you want to debug.
Customizing pdb also looks like a good idea. Uncaught exceptions should automatically throw us into our debugger.
Didn't Michael already do something like that? cheers, holger
holger krekel <hpk@trillke.net> writes:
Can't you use Python's setprofile/settrace stuff for this? Would make PyPy even slower, of course :-)
Yeah, should be possible.
Eh, I started. There's not much useful there, yet. Cheers, mwh -- I've even been known to get Marmite *near* my mouth -- but never actually in it yet. Vegamite is right out. UnicodeError: ASCII unpalatable error: vegamite found, ham expected -- Tim Peters, comp.lang.python
participants (4)
-
Armin Rigo -
holger krekel -
Hunter Peress -
Michael Hudson