New Guile Debugging Interface

I've recently been hacking on a new Emacs-based interface for debugging and developing Guile applications. My thoughts and partial design are described in Guile CVS in the file workbook/use/debugging.text.

The following screenshots give an idea of what the new interface does so far; I'm very interested to receive comments, whether for features to add, or for changes to improve or rework what's there already, or for improving this page itself.

Thanks in advance - Neil Jerram

Getting started

An application XYZ that wants to use this interface needs to kick off the communication by including

(use-modules (ice-9 debugger ui-client))
(ui-connect "XYZ")

The application has stopped as though a breakpoint was set just after the ui-connect call, and won't run again until the user tells it to continue.

While the application is stopped like this, the user can set a breakpoint on some procedure(s). Say an interesting procedure is in the (ossau fns) module, the user clicks on that module's [+] button to see its bindings --

-- then moves down to, say, facti and types b <RET>.

When all breakpoints are set, the user types g (for "go"), which tells the application to continue running.

Hitting a breakpoint

The upper window shows

• a message describing the breakpoint hit and its source location
• the stack at the breakpoint
• the module list as before, to help with adding further breakpoints if needed.

There are now several options.

• <SPC> runs the debugger's "next" command -- allows the application to run to the next application or evaluation in the same file.
• i runs "step" -- application runs to the next application or evaluation regardless of source location.
• o runs "finish" -- application runs to the exit of the selected frame.
• e reads an expression to be evaluated in the selected frame, and evaluates it.
• g tells the application to continue running.
• A different stack frame can be selected by clicking the radio button next to the desired frame.

Example 1 - single stepping

Note: The "T" in the stack section indicates a tail-recursive frame; in other words, that when that frame returns, all the frames above it marked "T" will also return in the same operation. "T" is the exact opposite of what Guile's current backtraces denote by "*".

Example 2 - evaluation

At this point one might like to know what n is, and what the result of (= n 0) is going to be. This can be discovered by evaluating a suitable expression in the selected stack frame, for example

(cons n (= n 0))

If you therefore type e (cons n (= n 0)) <RET>, the debug window responds:

The line near the top tells you that n is 2 and that (= n 0) is #f.

Coming next...

• support for "debug on error" and "debug on interrupt"
• making it possible for a command line application, such as the standard Guile REPL, to accept debug instructions at any time, not just when stopped at a breakpoint
• clarifying the interface, including explaining what's going on for those not intimate with the Guile stack
• support for listing existing breakpoints and changing breakpoint properties
• any other operations that are useful when stopped at an error or breakpoint
• any other forms of "reflection" (following the existing module and bindings lists) that may be useful, documentation for example.