Updated August 29th 2000

SITH: Debugging

Introduction

I have learned an important thing when making a system: Make the compiler and debugger first! So, here is the debugger, much later in the development process than it should have been. The debugger is the ultimate example of the SITH butt-ugly-GUI theme.

Setting a Function to Debug Mode.

Since the DBOS is a dynamically compiling system, turning on debugging mode must be localized. The grain of localization is at the function level. Let us pick an existing function to debug. First, go to the Class Table window: I have filtered the table so I can see the Object Class:

Right click on the row button for Object Class and select "Change".

You can see that I went to the Class Class tab, and I highlighted the attribute (function) we are going to inspect. Right click on the row button for the "print" attribute and select "Change":

The print attribute has instances of many classes, and you may have seen this all before in the SITH Compiling documentation. To turn on debugging we must make this function an instance of the Debug Function class. This is done by selecting Function Type in the menu bar and then choosing "Debug Function". A moment will pass and the function window changes to:

The Debug Function class has no fields yet, so it is very uninteresting. All we have to do is request that this function be run. We do this by passing the print message to an object. See the SITH Messaging document to know how to do this.

Once the DBOS realizes it is about to execute a debugged function, the debugger appears: (I am looking into what takes so long)

The debug window is a minimalist design. You can see the ubiquitous Step, Continue, and Step Into buttons. The left column of check boxes is where breakpoints can be set. The right column of check boxes indicate the current row the debugger is about to execute. Pressing the Step button will advance the current line. Continue will run to the next breakpoint. And Step Into will make the function on the current line a Debug Function and step into it. I am sure you know what to do from here.

Future Directions and Issues

• The GUI of the debugger will eventually be made in the DBOS, so improving it in hard code is certainly not worth the effort.
• The Debug Function class should have breakpoint attributes to remember the breakpoints across sessions
• Their should be a faster method to turning on/off the debugging mode
• Once a function is stepped into, the debugging option is not turned off.
• Debugging of functions is not context sensitive, therefore if any part of the DBOS uses the function it will open up the debugger. Debugging functions that are routinely used virtually halts the DBOS
• The debugger uses the MSM to interpret code, and not the Java instructions. Therefore, if the second stage of the compiler is not perfect, the debugged code and the interpreted code could result in different functionality.

Conclusion

Just like every SITH aspect, the debugger could use some work, but it is easier to use than a text debugger.

August 29th 2000 - Replaced the function image with a more current one. Noted that the debugger window is still old.

June 2000 - Initial version.