UDB To-Do List

This page tracks anything we know is needed in order for UDB to become the full-featured Unicon debugger that it was intended to be.

Improve UDB Support for Objects/Classes

Consider whether to modify "print" command output to be friendlier than ximage(), and/or to parameterize ximage() output format.
Allow breakpoints for methods whose name occurs in another class earlier in the same file.
Test and check action of breakpoints, "where" command etc. in the presence of inheritance and multiple inheritance. Can we easily print values of inherited variables? Can we set breakpoints for both overriding and superclass methods?

Support Debugging Threads

This probably involves extending the Unicon monitoring and threads facilities. There likely need to be events for creation, communication, and activations/transfers of control. There needs to be an execution model that makes sense. For example, if you hit a "breakpoint" in one thread, how are all threads stopped? Do you have to have one monitor per thread, or do all threads report events to the same monitor, or what?

Pattern Debugging

need a command to print long form of current pattern that ps has elided
check for missing || in image around a .> operator
does ps2 actually do 2 pattern steps? More generally, figure out how to make pattern step more aggressive, skip over dummy steps.
can the output images' use of "tmp" be improved e.g. printout of an unevaluated function call as `test(tmp,tmp,tmp)` is not very helpful

Miscellany

Some of these might be lower hanging fruit, others not so much.

fix the redirection bug: run <data/foo.dat doesn't seem to work
echo suppression: udb should check what kind of tty it is on and/or figure out it is on a tty that is not raw and should not echo a whole line when each character is typed, e.g. inside an emacs subshell, or an ide session.
command completion: udb already accepts short versions of commands like pr for print. But if you are not sure if an abbreviation is for the command you think it is, perhaps ESC or similar should complete your command for you.
automating -line detection: detect whether we are talking to a real console, and auto-enable -line mode on pseudo-tty's, e.g. inside emacs. Problems here include the fact that ordinary Terminal consoles on Linux seem to use pseudo-ttys, so how do we tell the difference?
context-based help for things like "break ?" and "break f ?": making help easier to get is a good idea.
graphics programs: debugging graphics programs is usually more difficult than debugging textual programs, both because the "action" is not tied to the console, and because it is hard to single-step through acres and acres of GUI class library code. How might udb help with this?
CGI / web applications: programs run at the behest of a web server are often harder to debug, since end users don't have access to their stderr or stdout. How hard would it be for such a program to have an attached udb process that gets the debugger access, possibly via an X server connection?
debugger tutorial for non-gdb users: this is a document, or possibly a scripted interactive tutorial, for generic Unicon users who are not big C/C++ programmers. The tutorial should discuss how to change variables in mid-execution, so as to change the outcome or test whether a different value would work in a given situation. Do you say "p x=15" or something else? Why would it be a "p" (that is, print) command?
check control-C behavior: Control-C is supposed to break out of a program execution and back to the debugger prompt in a usable way. udb occasionally has hanging problems, or control-C might kill the whole execution and udb, instead of getting you to a prompt.
visualization support?: Jeffery naturally would like to extend udb's existing capability to run "agents" for automatic debugging with examples of agents that draw pictures of what's going on while the program runs. In other words, extend this (agents) existing feature's value
GUI front-end??: this is the least of our sponsor's priorities