Skip to content

Debconf2010 emacs pydbgr

R. Bernstein edited this page Dec 4, 2017 · 4 revisions

Note: names have changed since I wrote this. I gave a talk in Poland on a debugger which at that time was called “rdbgr”. I was told by the Poles that this name was really unpronounceable. When you are told by someone who speaks Polish that your name is unpronounceable, you really have a problem. (Ask a Pole to speak a Polish tongue twister sometime.) So “pydb” and “pydbgr” have been renamed to “trepan2” and “trepan3k”. The name of this package “dbgr” has been of course been renamed to “realgud”. I have Mike Welles to thank for the name “trepan”.

I’ve worked on a number of debuggers listed here. I use Emacs as a front-end to them. When you install the debuggers bashdb or pydb in Debian, you get an Emacs interface to these debuggers. The interfaces underneath use the “Grand Unified Debuggger”, or gud.el, but GUD has a number of issues. So I am rewriting the debugger interface from scratch so there is one single code base.

Shown is the link which describes how to install the Emacs package.

To load the Emacs code after the Emacs package has been installed:

M-x load-library dbgr

There are now several commands that have been added that all start dbgr-. There also are a few commands to invoke some of the debuggers which don’t start dbgr-.

For demonstration, I’ll use a new Python debugger that I’ve been working on. However the operation for the other debuggers is the same. To debug a Python program from the start, you can use the command “pydbgr”

M-x pydbgr gcd.py 3 5

For the invocation that is suggested, the pydbgr command searches the invocation history. Failing to find anything there, we use the file of the current buffer if that is a Python buffer. Failing that, other Emacs buffers are searched for Python files. Finally, the current directory is scanned for a Python file. Here, I am picking up a prior invocation.

I now have two windows, a debugger command window on the top and the source-code window on the bottom. Note there is an arrow in the fringe area of the source code window to show you the statement you are about to run. When I do a debugger “step” command, the fringe arrows are updated automatically.

step

Note that the fringe arrow at the previous location has now faded a little bit. Another step…

step

And you see three levels of shading in the command window. That is also true in the source-code window. To see this, I type Meta-up arrow which adjusts the positions in both windows to the previous spots. And Meta-down arrow goes the other direction. [repeat] up … down.

Instead of entering debugger commands in the command-line window you can also type them in the source-code window. There is minor mode that allows single key-strokes to run debugger commands. This is called dbgr-short-key-mode. Let me show that.

M-x dbgr-short-key-mode

Notice the “ShortKeys” indicator. (point to “shortkeys”) and also notice the file is now read only. (point to %%).

Now when I hit the space bar, I step a statement. And down in the bottom message area I see the debugger command that was run. The letter ‘n’ is next or step over.

To set a breakpoint I type “b”. And to continue, which here will run until the breakpoint I just set, I type ‘c’. To see a backtrace for where I am now

M-x b  (other buffer)
where

I ran the debugger from the outset here but in many dynamic languages the debugger is not run initally but instead called from inside a running program. Let me show very briefly how this works in this situation:

C-x C-f gcd-dbgcall.py

This is how to call the debugger in the specific Python debugger I will use.

M-x shell
python gcd-dbgcall.py 3 5

So I am now in the debugger.

To attach the debugger here, use dbgr-track-mode
M-x dbgr-track-mode

You are prompted for the name of the debugger. Debuggers you could list here include a couple of Python debuggers, a couple of Ruby debuggers, gdb. And you can switch from one to the another. I will use pydbgr

pydbgr

And use frame 0 to refresh the display:

frame 0