[Bashdb-pydb] pydb-1.21 buglets

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

Thanks for the patches but I'm having trouble using some of them. 

DaveS writes:
 > 
 > Some tweaks to pydb.el for better windows support (c: and spaces in
 > filenames).  BTW is pydb-pydbtrack-stack-entry-regexp currently used for
 > anything?

Perhaps not. I've removed for now. We'll see what breaks if anything.

 > 
 > --8<---------------cut here---------------start------------->8---
 > (setq gud-pydb-marker-regexp
 >       "^(\\(\\(?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/.\\\\ ]+\\):\\([0-9]+\\))")
 > (setq pydb-position-re
 >       "\\(^\\|\n\\)(\\(\\(?:[A-Za-z]:\\)?[^:]+\\):\\([0-9]*\\)).*\n")
 > (setq pydb-pydbtrack-stack-entry-regexp  
 >       "^(\\((?:[a-zA-Z]:\\)?[-a-zA-Z0-9_/.\\\\ ]*\\):\\([0-9]+\\)):[ \t]?\\(.*\n\\)")))
 > --8<---------------cut here---------------end--------------->8---

Please give a diff against the current emacs/pydb.el for this. And
also please add a test in emacs/pydb-test.el.in for the a sample
string this now matches. I'm not sure I could reliably make a change
from what you have above.

 > 
 > A couple of small python changes:
 > 
 > * raw_input() needs a strip() because when running pydb with ipython and
 > emacs, I keep getting a trailing CR, which breaks things.

This change has been applied in CVS.

 > * pydbcmd.py: 419
 > looks like an indentation error. The line trace was *always* being printed.


No, this is intentional. Look at gdb output and you'll see a similar
output format.

 > 
 > Index: C:/Python25/Lib/site-packages/pydb/gdb.py
 > ===================================================================
 > --- C:/Python25/Lib/site-packages/pydb/gdb.py	(revision 1)
 > +++ C:/Python25/Lib/site-packages/pydb/gdb.py	(revision 5)

As mentioned above, I've applied this change.  It doesn't break the
regression tests. Presumably if it breaks things for someone else
we'll find out down the line.

But in the future place patch against the source (which in this case
the basename of the file is gdb.py.in)


 > One last change I didn't include in the patch (because it's so ugly).
 > traceback.print_exc() prints to stderr by default, but when I'm running in
 > emacs that seems to get buffered so I don't see the traceback until I exit
 > pydb.  For now I'm just calling as traceback.print_exc(file=p.stdout) to
 > make it work.  Still looking for a better alternative.

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.

 > 
 > Somethings changed with the tracebacks.  When execution stops because of an
 > exception, I'm getting dropped deep into pydb code rather then at the point
 > of failure.  Example:

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".

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.