Re: [Bashdb-pydb] pydb-1.21 buglets (not)

[R. B. <ro...@pa...>]

DaveS writes:
 > Ah, didn't realize that.  I guess the only issue with that is if pydb is not
 > running through gud (say in ipython) you get a double tracer - the first
 > (source:line) output that gdb would hide if it was running plus this second
 > tracer.  I'll get use to it.

Actually, it is *more* helpful when not run under Emacs and in ipython
in particular. Try running %pydb and stepping lines. It is helpful to
see the text of source shown.

Furthermore, in pydb's CVS I've broken out and the exposed the method
that prints that source line. This was done for ipython in particular,
but it could be helpful for other things of that ilk, e.g. remote
execution or Eclipse which may want results tagged in XML.

In ipython, I've patched Debugger.py to wrap a PyColorize call to that
source line. Recall that ipython creates a customized Pdb object
suited for its particular way of doing things. The patch hasn't been
submitted because there are already a number of patches in ipython
that I've sent in that haven't been applied -- and some of those need
to get in for this to work.

However it's also possible for ipython or some other such front-end to
customize an enclosing method, like "print_location". And there it
could choose not to show that line. (But again for ipython in
particular, I don't think it advisable when run outside of Emacs.)

 > > p.stdout seems better than stderr; we allow all debugger output to get
 > > redirected to wherever was specified. If it's not doing that it's a
 > > bug. I've just put this change also in CVS.
 > >
 > 
 > Does this mean that all output should make it's way to the debugger stdout
 > member?  If so I'll keep my eye open for any other cases.

Yes - thanks. For example in version 1.21 a change was made so that
disassembly output no longer goes to stdout unconditionally.

 > > Yes, this has changed. On an exception in Python 2.5 you are now at
 > > the point at which the exception was fielded rather than at the point
 > > it was raised. Previously there was no way to know, and personally I
 > > think this is a little more accurate. However in the future I may
 > > consider adding some option to allow the old behavior. For now if you
 > > always want to be at the the place the exception was raised issue
 > > "frame 0".
 > 
 > I guess this is more accurate, but if I'm working on a script I don't
 > normally need to see all the stack frames from the debugging framework.  I
 > like to think that my script is the only thing running.  I vote +1 for being
 > able to hide, or at least easily ignore, the pydb frames.

Yes, this has crossed my mind on a number of occasions. And in fact we
do some of this already on the most-recent side of the stack when you
use the "--threading" option. What you are suggesting is hiding frames
at the other end. (pdb has this problem too which is where we
inherited the bad behavior.)

I'll also note that the mechanism for doing this is a little
cumbersome and error prone. Either you look for certain source file
names like "bdb.py" (error prone), or you create a variable in the
call stack that you introspect on and identify like "breadcrumb" which
has a value of the method it is in that you can compare against
(cumbersome). And this latter alternative isn't available if the code
comes from outside of pydb as bdb.py does.

 > > Lastly, expect alas more breakage with pydb, ipython, emacs. Recently I've
 > >been changing the first two so that colorized output appears. (See the
 > >ipython forum on that. There are some patches I haven't sent in yet
 > >though.) However the recent changes seems to have cause the line-tracking
 > >regexp to now fail.
 > 
 > I've previously seen some issues related to coloured text.  If the
 > ansi-codes aren't processed before the tracking filters scan the text the
 > regexps can fail - and some filters work with the passed text while others
 > directly scan the buffer contents, so it's a bit of a hair puller at times.

Yes, so help here would be appreciated. Although my preferred
interaction of pydb is via Emacs, I don't really use ipython inside
emacs. I'll often just use a the Emacs pydb debugger, or a regular
shell with pydb line tracking, or a python shell.

But tolerance for other modes is good. I've noticed that many of the
fixes needed for such things are generally useful to make pydb better
or more general.

There is another gdb-like debugger for Ruby (called ruby-debug). It's
overall design is a bit cleaner. In particular, the entire "printing"
mechanism is its own class. Such a structure like this might be of
help here.

 > Looking forward to more goodness.  

I can only go so far and have limited time I can spend on this. So
really a lot depends on everyone or others.