Proposal: A symbolic debugger for OOC

[Stewart Greenhill <greenhil@murdoch.edu.au>]

Hi,

I know that there are always arguments for and against debuggers. In
reality, if you are trying to find a problem, or trying to verify that
complex code is working correctly, the ability to visualise run-time data
structures is essential. Without a debugger, you need to write code to
traverse and print these structures, which can be tedious and time-consuming.

Here's an idea that I've been considering for a while.

With a sufficiently powerful meta-programming system (eg. the Refs that
Harmut is proposing), it should be possible to introspect at run-time to
determine:
1) The state of the stack.
2) Local variables in modules.
3) Records and arrays on the heap.

A decent post-mortem debugger (such as is found in many Oberon systems)
allows the programmer to inspect the state of the system to discover the
causes of the exception. These debuggers are usually tied to Oberon
systems, and use "active documents" (eg. texts with special embedded link
objects) to allow the user to navigate the state of the system. OOC has
Visual Oberon, but many OOC programs do not use VO.

It would be possible to implement a post-mortem debugger as a small HTTP
server linked into an OOC application. This avoids the problem of having to
design a user-interface to the debugger. If debugging were enabled (perhaps
using a special command-line argument), an OOC program would not HALT on an
exception, but would print the normal error message and then wait for
connections on a pre-determined TCP/IP port. The user would then connect to
the port using any Web browser (eg. Netscape, lynx, etc) on any machine
that is connected to the network. This allows both local and remote
debugging. The debugger would output a stack back-trace as HTML. The values
of variables would be printed, and any pointer variables would be displayed
as hyper-links. By appropriately encoding URLS, it would be possible to
navigate the heap, stack and module variables. Assuming that each stack
frame has a type descriptor, it would be possible not only to print the
local variables, but to determine the procedure name and display a link to
the corresponding module static variables.

It would also be possible to allow users to insert "watch points" in their
code. These would simply be procedure calls to the debugger which check for
a waiting connection on the TCP/IP port. If there is a connection, the
debugger is started. If there is not a connection, the procedure returns as
normal. Once the user has finished inspecting a "watch point", it would be
possible to continue running the program (ie. the call to the debugger
simply returns). As far as I know, this is not possible in any existing
Oberon system.

These is just an idea at the moment. It presupposes a powerful
meta-programming system, which is quite a hard problem in itself (see my
earlier post). However, I have some experience with writing HTTP servers,
so I could probably help with this part.

Cheers,
- Stewart