trepan 0.2.5

Source-code Syntax Colorization

Terminal source code is colorized and we make use of terminal bold and emphasized text in debugger output and help text. Of course, you can also turn this off.

Smart Eval

If you want to evaluate the current source line before it is run in the code, use eval. To evaluate text of a common fragment of line, such as the expression part of an if statement, you can do that with eval?. See the help for eval for more information.

Better stepping granularity

Sometimes you want small steps, and sometimes large stepping.

This fundamental issue is handled in a couple ways:

Step Granularity

There are now step event and next event commands with aliases to s+, s> and so on. The plus-suffixed commands force a different line on a subsequent stop, the dash-suffixed commands don’t. Suffixes >, <, and ! specify call, return and exception events respectively. And without a suffix you get the default; this is set by the set different command.

Event Filtering and Tracing

By default the debugger stops at every event: call, return, line, exception, c-call, c-exception. If you just want to stop at line events (which is largely what you happens in _pdb_) you can. If however you just want to stop at calls and returns, that’s possible too. Or pick some combination.

In conjunction with handling all events by default, the event status is shown when stopped. The reason for stopping is also available via info program.

Event Tracing of Calls and Returns

I’m not sure why this was not done before. Probably because of the lack of the ability to set and move by different granularities, tracing calls and returns lead to too many uninteresting stops (such as at the same place you just were at). Also, stopping on function definitions probably also added to this tedium.

Because we’re really handling return events, we can show you the return value. (_pdb_ has an “undocumented” _retval_ command that doesn’t seem to work.)

Debugger Macros via Python Lambda expressions

In gdb, there is a macro debugger command to extend debugger commands. However Python has its own rich programming language so it seems silly to recreate the macro language that is in gdb. Simpler and more powerful is just to use Python here. A debugger macro here is just a lambda expression which returns a string or a list of strings. Each string returned should be a debugger command.

We also have _aliases_ for the extremely simple situation where you want to give an alias to an existing debugger command. But beware: some commands, like step inspect command suffixes and change their behavior accordingly.

We also envision a number of other ways to allow extension of this debugger either through additional modules, or user-supplied debugger command directories.

If what you were looking for in macros was more front-end control over the debugger, then consider using the experimental (and not finished) Bullwinkle protocol.

Byte-code Instruction Introspection

We do more in the way of looking at the byte codes to give better information. Through this we can provide: * a skip command. It is like the jump command, but you don’t have to deal with line numbers. * disassembly of code fragments. You can now disassemble relative to the stack frames you are currently stopped at. * Better interpretation of where you are when inside execfile or exec. (But really though this is probably a Python compiler misfeature.) * Check that breakpoints are set only where they make sense. * A more accurate determination of if you are at a function-defining def statement (because the caller instruction contains MAKE_FUNCTION.)