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:
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 :-).
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]
Hello Hunter,
On Thu, Jul 10, 2003 at 05:32:05AM -0700, Hunter Peress wrote:
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 :-).
... not your fault, but Mr. Hunter Press cited me without proper indication ...
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.
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 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.
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:
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
Can't you use Python's setprofile/settrace stuff for this? Would make PyPy even slower, of course :-)
such a mechanism - reyling somewhat on introspection - would allow for a pretty flexible tracing parametrization depending on what you want to debug.
Yeah, should be possible.
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?
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