[pypy-dev] RE: type problems

[holger krekel]

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