using python debugger (pdb) inside emacs debugger mode ... 
Author Message
 using python debugger (pdb) inside emacs debugger mode ...

Does anyone have experience with using M-x pdb inside emacs? This part of
gud-mode should be able to grok the python de{*filter*}, but I can't get it to
work, and there is little documentation (gud-mode mentions gdb, sdb, dbx,
perldb, xdb, but not pdb).

M-x pdb gives:

  run pdb (like this): pdb

which doesn't work, as pdb is not defined. Running it like

  python /usr/local/lib/python1.5/pdb.py ~/python/test.py args

does not work either, since it chdir()'s to /usr/local/lib/python1.5/ and
also strangely doesn't expand the ~ to "/my/home/dir". If I hand-expand it,
it will only synchronize with the source if I give a few 's' commands, but
then it gets stuck when stepping into a module that it can't find because
os.getcwd() is wrong.

Aaarggh! what am I doing wrong? Any comments appreciated!

This is in emacs 20.3, but emacs 20.4 has the same gud.el

(BTW, I'm amazed that gud.el, which comprises 2500 lines of fairly
non-trivial stuff, does not include any version information, not as a
variable, nor as comment...)

                                                                      Philip
--
The cause of the millenium bug is Homo Sapiens having 10 fingers
-----------------------------------------------------------------------------

+44 (0)1223 49 4639                 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax)           | Cambridgeshire CB10 1SD,  GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC  50 3D 1F 64 40 75 FB 53



Sat, 02 Mar 2002 03:00:00 GMT  
 using python debugger (pdb) inside emacs debugger mode ...
Quote:
Philip Lijnzaad writes:

 > Does anyone have experience with using M-x pdb inside emacs?

A while ago I submitted patches to the XEmacs maintainers to make this
all work smoothly in XEmacs, which, as of XEmacs version 21, it does.
I have no idea about FSF Emacs, some additional work may be necessary.
If I get some time I'll put up an FSF Emacs installation and give it a
whirl, but don't hold your breath!

 > M-x pdb gives:
 >
 >   run pdb (like this): pdb
 >
 > which doesn't work, as pdb is not defined. Running it like
 >
 >   python /usr/local/lib/python1.5/pdb.py ~/python/test.py args
 >
 > does not work either, since it chdir()'s to /usr/local/lib/python1.5/ and
 > also strangely doesn't expand the ~ to "/my/home/dir". If I hand-expand it,
 > it will only synchronize with the source if I give a few 's' commands, but
 > then it gets stuck when stepping into a module that it can't find because
 > os.getcwd() is wrong.
 >
 > Aaarggh! what am I doing wrong? Any comments appreciated!

I'd suggest at the very least to make a symlink to
/usr/local/lib/python1.5/pdb.py called something like
/usr/local/bin/pdb, (somewhere along your $PATH), and make sure the
file is executable and has the right #!/ magic at the top.

That might just be enought to get you there.



Sat, 02 Mar 2002 03:00:00 GMT  
 using python debugger (pdb) inside emacs debugger mode ...

I had the same problem for a while.  I got a partial solution going, but
gave up when I decided that it was easier to just insert a
pdb.set_trace() in the region of code I was interested in.

Anyway, what I did was set

(setq gud-pdb-command-name "python ~/command-pdb.py ")

where command-pdb.py contained:

#!/usr/bin/python
import sys, pdb, re
home = '/home/alex/'
file = sys.argv[1]
file = re.sub ('^~', home, file)
sys.path = [re.match ('(.*)/[^/]*$', file).group (1)] + sys.path
pdb.run ('import ' + re.match ('.*/([^/]*)\.py$', file).group (1))

so when I ran pdb, in the command line would appear

Run pdb (like this): python command-pdb.py

and I would enter the path to the script I wanted to run, i.e. if it was
in ~/python/script.py, I would put that whole path in, regardless of
what the cwd was.

It was then easy to bind a function key to some emacs lisp that did all
this automatically for the buffer I was currently in.  Unfortunately, I
seem to have deleted that while noodling around with my .emacs file.
Probably just as well, because it was at least as bad as the code
above. :)

Alex.

--
If cars were like computers, they would go 300 m.p.h. and get a hundred
miles to the gallon and cost $50. Except that twice a month someone a
thousand miles away would be able to blow up the car, killing everyone
nearby.



Sat, 02 Mar 2002 03:00:00 GMT  
 using python debugger (pdb) inside emacs debugger mode ...
Philip Lijnzaad:
 |Does anyone have experience with using M-x pdb inside emacs? This part of
...
 |then it gets stuck when stepping into a module that it can't find because
 |os.getcwd() is wrong.
 |
 |Aaarggh! what am I doing wrong? Any comments appreciated!

I feel your pain.  I spent several hours this week trying to find a
source-tracking de{*filter*} for Python that works well.  No luck.

[ Is there a "Python De{*filter*} HOW-TO" lurking out there? ]

Of what I tried, PyDB with DDD is very cool:

      http://www.*-*-*.com/ ~dbhopper/aa8vb/TMP/DDD-PyDb.tif

This is the kind of interface I'm looking for.  Full source browse and
tracking, click to set a breakpoint, click to examine/watch a variable,
etc.  However it terminates abnormally a good bit, particularly with
multi-module programs.

 |This is in emacs 20.3, but emacs 20.4 has the same gud.el

I'd like one for Emacs myself (ala gdb/dbx with source tracking).  GNU if
possible but I'll do XEmacs if needed.  However, no luck with the brief try
I gave PDB/pdb.el/XEmacs.  User friendly PDB is not (see attached for your
amu{*filter*}t).

No time to continue this search now.  Possibly the best route is to dig in
and help beef up PyDB.

Randall

-------------------------------------------------------------------------------
NEWBIE PDB SESSION (for your amu{*filter*}t)
  - Python's terse error msgs don't help
  - "<string>(0)?()" ?
-------------------------------------------------------------------------------

Quote:
> python

Python 1.5.2 (#3, Jul  8 1999, 11:01:48) [C] on irix646-n32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Quote:
>>> import pdb
>>> import MyModule  
>>> pdb.run( 'MyModule.run()' )
> <string>(0)?()
(Pdb) where
> <string>(0)?()

(Pdb) list
[EOF]
(Pdb) run
*** NameError: run
(Pdb) r
Quote:
> <string>(1)?()

(Pdb) cont
en> <string>(0)?()
(Pdb) where
Quote:
> <string>(0)?()

(Pdb) KeyboardInterrupt: <exceptions.K...e at 10281ee0>
Quote:
> <string>(1)?()
(Pdb) where
> <string>(1)?()

  MyModule.py(615)run()
-> import pdb; pdb.run( 'root.mainloop()' )
  /home/rhh/software/python-1.5.2/lib/python1.5/pdb.py(855)run()
-> Pdb().run(statement, globals, locals)
  /home/rhh/software/python-1.5.2/lib/python1.5/bdb.py(343)run()
-> exec cmd in globals, locals
  <string>(0)?()
  <string>(0)?()
  /home/rhh/software/python-1.5.2/lib/python1.5/bdb.py(39)trace_dispatch()
-> return self.dispatch_line(frame)
  /home/rhh/software/python-1.5.2/lib/python1.5/bdb.py(51)dispatch_line()
-> self.user_line(frame)
  /home/rhh/software/python-1.5.2/lib/python1.5/pdb.py(90)user_line()
-> self.interaction(frame, None)
  /home/rhh/software/python-1.5.2/lib/python1.5/pdb.py(113)interaction()
-> self.cmdloop()
  /home/rhh/software/python-1.5.2/lib/python1.5/cmd.py(73)cmdloop()
-> line = raw_input(self.prompt)
(Pdb) print MyModule.run
<function run at 10265278>
(Pdb) print MyModule.run.root
*** AttributeError: root
(Pdb) quit


Tue, 05 Mar 2002 03:00:00 GMT  
 using python debugger (pdb) inside emacs debugger mode ...

Quote:

>  |This is in emacs 20.3, but emacs 20.4 has the same gud.el

> I'd like one for Emacs myself (ala gdb/dbx with source tracking).  GNU if
> possible but I'll do XEmacs if needed.  However, no luck with the brief try
> I gave PDB/pdb.el/XEmacs.  User friendly PDB is not (see attached for your
> amu{*filter*}t).

I'm using pdb with Xemacs here with no problem. Is a little different from the
gdb interface but is definitely more usable that pdb in command line. I'm using
Xemacs 21.1.6 with pdb.el that comes with it. I would still like to have a
pdb-mode for source files, similar with gdb-mode, but I guess the gdb-mode uses
the gdb annotations to be able to do that, which pdb doesn't have.

A better thing might be to have gdb support debugging Python programs, just
like it supports the other languages, but this is a different topic.

Greetings,
Ovidiu

--

http://www.*-*-*.com/ ;(inside HP's firewall only)
http://www.*-*-*.com/



Tue, 05 Mar 2002 03:00:00 GMT  
 using python debugger (pdb) inside emacs debugger mode ...

Quote:
Ovidiu Predescu writes:

 > I would still like to have a pdb-mode for source files, similar
 > with gdb-mode

Could you elaborate a little bit on what you would like this mode to
do?  Do you mean being able to click on expressions in the source
buffer and print out their values, etc?  This might not be too hard to
add to pdb.el without needing any big modifications to pdb.py, in
particular I'm not sure that gdb annotations are required.  Or are you
talking about something else?

 >
 > A better thing might be to have gdb support debugging Python programs, just
 > like it supports the other languages, but this is a different topic.

It's probably safe to say that this will never happen, support for
Python debugging would be just *too* different than the languages GDB
already supports.  But what would be good would be to have a Python
de{*filter*} that presents the identical interface as GDB, so that it
could be used in contexts where GDB is used (like XEmacs, and the
other various GUI front-ends to GDB that are out there).... This is
something I'd like to work on but quite honestly I haven't had the
time recently, possibly in a few months when I finish up some current
projects, I'll be able to get back to my "PyGDB" project.



Wed, 06 Mar 2002 03:00:00 GMT  
 using python debugger (pdb) inside emacs debugger mode ...


Quote:
> Ovidiu Predescu writes:

>  > I would still like to have a pdb-mode for source files, similar
>  > with gdb-mode

> Could you elaborate a little bit on what you would like this mode to
> do?  Do you mean being able to click on expressions in the source
> buffer and print out their values, etc?  This might not be too hard to
> add to pdb.el without needing any big modifications to pdb.py, in
> particular I'm not sure that gdb annotations are required.  Or are you
> talking about something else?

Yes, I was referring to this ability. In Xemacs, there are two different modes
that support debugging, one is implemented in gud.el and another one is gdb.el.
The gdbsrc mode that implements the "click on expression and print" is
implemented as an extension to gdb.el. On the other hand, pdb.el is implemented
as an extension to gud.el, that doesn't have this functionality. I don't know
how hard will be to extend gud.el to have this functionality.

Regarding the gdb annotations, I just looked on gdb.el in the Xemacs sources
and it looks like you're right, they don't seem to be used in gdb.el. However
gud.el does seem to use annotations for keeping the internal emacs buffers in
sync with gdb's location.

Quote:
>  > A better thing might be to have gdb support debugging Python programs, just
>  > like it supports the other languages, but this is a different topic.

> It's probably safe to say that this will never happen, support for
> Python debugging would be just *too* different than the languages GDB
> already supports.  But what would be good would be to have a Python
> de{*filter*} that presents the identical interface as GDB, so that it
> could be used in contexts where GDB is used (like XEmacs, and the
> other various GUI front-ends to GDB that are out there).... This is
> something I'd like to work on but quite honestly I haven't had the
> time recently, possibly in a few months when I finish up some current
> projects, I'll be able to get back to my "PyGDB" project.

GDB indeed doesn't have support for debugging interpreted languages at this
time, but this doesn't mean it cannot support this. I believe this can be
achieved pretty easily by having the GDB process invoke the Python de{*filter*} in
the target program.

I didn't figure out exactly all the details, but the basic idea is to use GDB
to handle all the interaction with the user instead of pdb. pdb becomes only a
debugging engine that's loaded in a Python program and knows how to setup
breakpoints, continue the program etc. All these operations are published in a
simple Python API that could be called from GDB.

Pdb needs to be extended to call some C functions in the Python interpreter
when it reaches certain states. For example, each time the pdb engine hits a
Python breakpoint in the target program, it calls a C function. GDB has a
breakpoint setup in this function and it knows that whenever this breakpoint is
hit, the pdb de{*filter*} in the target process reached a breakpoint. At this point
the control is returned back to GDB. When GDB wants to continue the program it
calls pdb in the target program and changes its state. Then GDB simply
continues the program, at which point pdb discovers that its internal state has
changed and proceeds accordingly.

What I'm working on right now is adding scripting language support to GDB so
that this kind of functionality could be implemented in GDB using an
interpreted language and not C. The language I'm embedding is surprise, Python
;-). This work is part of the WDB project here, at HP, but all the work we're
doing is going back in the FSF main tree. For more information on WDB, take a
look at:

http://www.*-*-*.com/ {*filter*}s/index.html

Greetings,
Ovidiu

--

http://www.*-*-*.com/ ;(inside HP's firewall only)
http://www.*-*-*.com/



Wed, 06 Mar 2002 03:00:00 GMT  
 using python debugger (pdb) inside emacs debugger mode ...

Quote:

> Ovidiu Predescu:
>  |I didn't figure out exactly all the details, but the basic idea is to use
>  |GDB to handle all the interaction with the user instead of pdb. pdb
>  |becomes only a debugging engine that's loaded in a Python program and
>  |knows how to setup breakpoints, continue the program etc. All these
>  |operations are published in a simple Python API that could be called from
>  |GDB.

> I believe this is how DDD/PyDB works as well (providing the user with a
> graphical Python de{*filter*}).

Actually PyDB works as a front-end for GDB. It sets up breakpoints inside the
interpreter and analyzes the internal C data structures to discover the state
of the Python program.

The thing I was thinking of is a much tighter integration between GDB and the
Python program, as GDB would make calls into the Python program to find out
about its state.

Quote:
>  |What I'm working on right now is adding scripting language support to GDB
>  |so that this kind of functionality could be implemented in GDB using an
>  |interpreted language and not C. The language I'm embedding is surprise,
>  |Python ;-). This work is part of the WDB project here, at HP, but all the
>  |work we're doing is going back in the FSF main tree. For more information
>  |on WDB, take a look at:
>  |
>  | http://www.*-*-*.com/ {*filter*}s/index.html

> Sounds interesting.  Hope to hear more about this later.

Sure, I'll let you all know when I have something you can play with.

Greetings,
Ovidiu

--

http://www.*-*-*.com/ ;(inside HP's firewall only)
http://www.*-*-*.com/



Sat, 09 Mar 2002 03:00:00 GMT  
 using python debugger (pdb) inside emacs debugger mode ...
: Actually PyDB works as a front-end for GDB....

One thing that would be great would be to replace GDB's rather
inexpressive control language with something more like Python
or Scheme. I once tried to cajole the Cygnus folks into doing
this but they weren't interested. It sounds like PyDB might be
doing something similar, but with the assumption that the C
program under study is always the Python interpreter. But a
Pythonized GDB that could be applied to any C program would be
a very cool thing.
--
 - - - - - - - - - - - - - - - - - - - - - - - -
Resistance is futile. Capacitance is efficacious.



Sat, 09 Mar 2002 03:00:00 GMT  
 using python debugger (pdb) inside emacs debugger mode ...

Quote:


> : Actually PyDB works as a front-end for GDB....

> One thing that would be great would be to replace GDB's rather
> inexpressive control language with something more like Python
> or Scheme. I once tried to cajole the Cygnus folks into doing
> this but they weren't interested. It sounds like PyDB might be
> doing something similar, but with the assumption that the C
> program under study is always the Python interpreter. But a
> Pythonized GDB that could be applied to any C program would be
> a very cool thing.

As I said in a previous posting, this is exactly what we're working on here at
HP, in the WDB project. You will be able to actually extend GDB by writing your
own scripts in Python to help you debug your program. I hope this code will be
eventually be accepted for inclusion on the main FSF tree of GDB (now
maintained by the Cygnus folks).

Greetings,
Ovidiu

--

http://andromeda.cup.hp.com/  (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/



Sat, 09 Mar 2002 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Using emacs gud/pdb python debugger under windows

2. using emacs pdb with a running python process?

3. Emacs package to the Python debugger?

4. debugger (pdb)

5. how can one pass command-line parameters to debugger pdb

6. Debuggers, Static Debuggers, and Algebraic Steppers

7. IDE Debugger breakpoints inside a thread?

8. Documentation for using python mode in emacs

9. Using etags and speedbar from (X)Emacs in python-mode

10. Python pdb and emacs

11. Advice for using emacs python-mode

12. emacs / debugger

 

 
Powered by phpBB® Forum Software