SourceBug is a source browser, a MacApp inspector window, and a SADE-style MPW debugging utility with a Symantec-style debugger user interface.
Mike Lockwood created SourceBug to debug MacApp applications written in C++ or Object Pascal. It has some debugging facilities that are specialized for MacApp, but should also do a good job with other programs that are compiled in MPW 3.2 with the symbolic debugging information option.
This review is based on a beta release of SourceBug-version 1.0b2x1-so perhaps it is better described as a preview. It was tested with Zortech C++, MPW CFront, Pascal and C under MPW 3.2. In each case, I tested SourceBug with one or more of the standard example programs that come with MPW, using SourceBug to explore the code and functions of the application, and to trace its operation. I tested it with several MacApp-specific applications-Apple's samples-using both C++ and Pascal versions. I also tested it with a C++ application.
SourceBug asks for a three megabytes partition. I ran it using virtual memory under System 7.0 on a Mac IIcx without obvious problems. SourceBug's compatibility with VM may ease the problem of memory squeeze when debugging large applications. MPW contributes to this problem because it requires a large slice of memory to build MacApp applications. For this reason, and due to the number of windows in use, and performance requirements, I recommend using a Mac II or better. MPW 3.2 is required since .sym information from the 3.2 linker differs from previous versions.
Here's one example of an MPW command used to build one of the MacApp samples, DemoText:
MABuild demotext -names -sym -nodebug -pascal -noload
"-names" is not necessary for SourceBug, but helps with low level debuggers;Ê"-nodebug" is there because the MacApp debugger and SourceBug are partially incompatible; and "-pascal -noload" avoids bugs that exist in some versions of MPW's Pascal. You don't need to specify other special compiler directives, or make alterations to the make file, in order to use SourceBug.
Using SourceBug with a non-MacApp application is even simpler. The main thing is to run "Create Build Commands..." and to switch on "Symbolic debugger information." When the application is built, the information needed by SourceBug is saved in a separate file.
Once the information is loaded, you can select the "Go" menu item to start the application. To break back into SourceBug, you must set up breakpoints in the source code-either before running the application, or by switching into the debugger, then setting a breakpoint in the source code browser and switching back to the application. This is unlike the Think C debugger which has a "stop" command that halts the application and gives access to the debugger-usually at "waitNextEvent." Such a feature would be a useful addition to SourceBug; presently, merely switching into SourceBug presents a blank stack crawl window.
SourceBug can debug several applications at once, which is helpful if you have a monitor large enough to arrange all the windows conveniently. SourceBug would be more usable if it included some kind of "hide other application's debugging windows" command in the windows menu like the one in the new Finder. Nevertheless, this facility will prove invaluable for developers that are working on applications that use IAC and publish and subscribe. It's also convenient for reviewers!
The window for the source code browser has three panes; each one can be resized according to taste. The window is split horizontally, and the top half is split vertically. When debugging a C program, the top left pane lists the source code files, and the top right lists the functions in the currently selected file. If the application is written in C++ and the objects do not descend from a Pascal object, the functions display with their scope, but no class hierarchy is shown. For example, in the CPlusShapesApp, the window displays TArc::Draw. It also shows constructors and destructors properly.
I did notice a glitch with two functions in CPlusShapesApp; they had almost nonsensical names, and when selected, caused repeated dialog boxes to display. This may be a failure of C++ name unmangling rather than SourceBug. Apparently, CFront generates subtly different .sym files, and SourceBug has had to be specially modified to handle these variations.
Unfortunately, Zortech C++ did not at review time generate symbolic debugger information files that were usable by SourceBug, so I couldn't test the compiler properly with it. However, applications built with MPW CFront worked well, with the one exception mentioned above. In a Pascal application that doesn't use objects, the top left window displays all the units of the application and, as before, functions and procedures on the right.
The main difference between a conventional application and a MacApp application is that in the case of MacApp, the source code browser lists object classes in the top left panel in addition to any files containing procedures or functions. For example, in the MacApp DrawShapes sample, all the classes are listed, and at the bottom is a list of Pascal units such as UFailure. The classes can be displayed alphabetically or in a hierarchy according to inheritance. The top left pane displays methods of the currently selected class.
The bottom half of the window displays the code for the selected method, procedure or function. If the debugger can't find the source code, the object code is disassembled and displayed in assembler mnemonics. You can also use a menu command to cause the code to be displayed in assembler mnemonics.
You can select and copy the source code from this window. Also, by option clicking in the window, you can open a new window showing that code. This might be useful for keeping an eye on an important function, while using the browser to look at lesser used functions, or to see a trace through the same function in source and assembly.
This feature also applies to the source code displayed in the stack crawler. Also, there is a command to show the name of the source code file from which a particular method or function derives. On the down side, the operations of source code browsing sometimes seems a little viscous. And the ability to choose the fonts for display would be welcome; for example, I prefer Helvetica over Geneva or Monaco 9 point.
You can also run a trace through the program by selecting "Animate" on the control menu. This steps through instructions slowly, and always yields to a mouse event in the debugger so the trace can be stopped. This is useful for people like me who are too lazy to keep pressing command-S to step. It can also be helpful for debugging interactive processes where yielding control to the debugger at every instruction would prevent normal operation of the application.
When stepping through an application under test, SourceBug displays a stack crawl window. This is divided in half by a horizontal break. The top half displays a stack of function calls. In a C application, for example, the top of the list shows "main," and then "function one" which calls "subfunction one" which is at the bottom of the stack. This is similar to the display in Think Pascal's debugger. It's useful for tracing through the methods of an object program where the flow of control can seem a rather inscrutable to a newcomer. The bottom half shows the function currently being executed in the same format as the source code browser.
As you step or trace through the application, a small pointing hand rests to the left of the instruction currently being executed. On a color display, the hand and breakpoints are shown in color. In the source code browser, when control passes to a subroutine, the hand turns grey until control returns to the visible function. However, in the stack crawler, stepping into a function brings that new function into the window. You can set breakpoints using both the stack crawl and browser windows, and any sub-windows created by option clicking on either.
As mentioned above, unlike Think C debugger, there's no way to interrupt the execution of the application from within SourceBug without first setting a breakpoint. But this is not a major inconvenience; perhaps it is only noticeable to developers reared on Think's debuggers.
There are several ways to evaluate and display variables. If you select the variable from a source code display and choose "evaluate selection," a window displays showing the contents of that variable. You can also type the variable name into a dialog box. Compound variables-such as C structures-are displayed in full, broken down into their components. Again, these variable monitor windows are updated constantly. If a variable is out of scope, SourceBug displays "out of scope" instead of a value.
It is frustrating to have each variable displayed in its own window. Think Pascal's method of monitoring several variables in one window makes for a tidier desktop, but perhaps less flexibility.
When dealing with objects, you can "evaluate self," which copes with SELF in Pascal and "this" in C++. Doing so brings up a similar window showing the variables that belong that object. Although it is titled "evaluate," no command on the evaluate menu allows expressions containing variables to be evaluated. For example, you can't evaluate "myFlag==FALSE". This is possible in language specific debuggers, because the debugger can use the language's own evaluation engine. SADE included its own procedural language, allowing similar kinds of language independent evaluations. Some form of simple evaluation would also be useful in SourceBug.
SourceBug has other features that are specific to debugging MacApp applications-see Debugging MacApp, below.
This is probably an inevitable limitation of SourceBug's approach; the two Symantec debuggers are also limited in this fashion. You can work around it by using several monitors or one large one. If you have enough screen space, you will have problems only when there are many windows visible in both applications, when several applications are being debugged simultaneously, or when trying to debug functions to do with screen updating.
During testing, I could move back and forth between SourceBug and MacsBug 6.2; I used SourceBug's command to drop into MacsBug, then MacsBug "g" command to return control back to the application, and thence back to SourceBug. Unlike Symantec's Think C source level debugger, a user break such as that caused by a Debugger() call in the source code does not enter SourceBug, but drops into the low level debugger.
It's useful to be able to embed breakpoints in the actual source code of an application. Because SourceBug is meant for use with a low level debugger and doesn't have the facility to break at A-traps, it doesn't take over control at Debugger or DebugStr. However, you can do the same thing with some little known calls defined in MPW 3.2 "Types.h" header. The SysBreak() routine is similar to Debugger(), while SysBreakStr() and SysBreakFunc() are similar to DebugStr, except that they drop into SourceBug, not MacsBug.
The code of the currently selected method is shown in the bottom half. This is useful for looking at methods that pass control back to their parents, using the INHERITED keyword in Pascal for example, where it is possible to see what each generation of the method does and how it differs from its relations. This might be useful in the descendants of the MacApp class TCommand, where a different command object exists for each menu command, but all descend from one or more base classes. You can use this command to look at all implementations of TWhateverCommand.DoIt.
The top left pane shows a list of all object classes, and the top right pane shows the addresses in memory of all objects of the class selected on the left that currently exist. Clicking on one of these shows the instance variables of that class in the bottom pane, as if it were a conventional compound variable.
This ability to deal with objects in memory as complete entities is useful. It would be even more useful if there were some way of connecting the classes in the top left with their source code in the source code browser. Unfortunately, the command "Find code for selection..." does not work in this way for a class selected in this window. Likewise, there is no direct way of looking at a class in the browser, and then saying something like "Show me all the instantiated objects of this type." These small omissions barely affect the utility of the debugger, but would have made its use more coherent.
SourceBug will eventually contain a special handler for MacApp's TList object, showing the contents of a list in another inspector-type window. The review version did not contain this feature.
However, these problems do not mar this excellent utility. There can be no doubt that SourceBug is an essential tool for debugging MacApp-based pro-grams. It is almost as useful in debugging object programs that do not use MacApp, and in debug- ging programs that do not use objects. Its major problem is the speed with which it runs.
SourceBug was designed for programmers by programmers, but this doesn't mean it needs a programming genius to install and operate it. Apart from the confusion caused by not compiling a MacApp library with symbolic information, I was able to use SourceBug immediately and without reference to the manual. This is, of course, in the best tradition of Mac application reviews.
The manual revealed no major surprises when I eventually read it, as a dutiful reviewer. It did contain some neat tricks that I wouldn't have noticed otherwise. Programmers familiar with the similar environments mentioned above, and MPW, might need only a page or two of instructions to do useful work with SourceBug. As for the installation and compiler options needed to get it running-nothing could be simpler.
.gif)
