Debugging with LightSpeed Pascal

By David E. Smith, Editor & Publisher

The Boston Expo this week promises to offer a world of new Mac products of particular interest to developers. Many of these products will revolutionize how software is done on the Mac, so it is time to take stock and review the software development process on the Mac.

Where to Begin

The first step in the product development cycle is to get information. This means getting a copy of Inside Macintosh by Addison Wesley, volumes 1-3 and soon volume 4. I prefer the hard bound all in one edition (great for dropping on bugs ). Next some Mac hardware is in order. A Mac Plus with a two meg upgrade from MacMemory is a must. A hard disk, scsi type, is helpful. The DataFrame 20 has been reported as a "safe" buy, reliable, few problems. A new round of 60 to 100 meg drives is also appearing in the $2500 range. Hardware and book in hand, it's time to reach for the check book and buy additional information. Apple's software supplements and technical notes are a must, from Apple's mailing facility. For referencing the ROM, there is TOM's Program's little ROM reference deck. Finally, don't forget the MacTutor subscription!

Utilities are important. No programmer should be without Fedit Plus, Mac Nosy 2.1, TMON or Heap Show. Both Fedit Plus and Mac Nosy 2.1 are new versions being shown at Boston. All four of these products are available from MacTutor as well as other technical software outlets. Heap Show is a very valuable little utility that allows you to analyze heap use in your program, find dangling handles and pointers, and help you prevent heap fragmentation. It is one of the most valuable of utilities yet is also the least known.

Now loaded with documentation from IM, supplements and back issues of MacTutor, the next step is finding out what it all means. For this, the only way to go is to sign up for Dave Wilson's Macintosh Programming Class. This is Apple's official introduction to Mac Programming and it is indispensible. I just finished the class and I really learned a lot about the Mac that I either didn't know or didn't understand correctly. Dave is a master teacher and well versed in the Mac hacker's world. Cost is not cheap at $1,000, but it's well worth the price if your part of a company project. Six months after you're well along in development, thanks to Dave Wilson, you can then sign up for Scott Kanaster's Mac College to get the bugs out of your project. But we're getting ahead of ourselves. First you must decide on a development system.

HFS Changes Development Environment

Under MFS, the Mac supported a number of traditional development systems. The Aztec C 1.06G is preferred by Unix programmers because it preserves much of the Unix flavor of software development within the Mac interface. Consulair C and TML Pascal both present a similar Mac User Interface for software development using the traditional Edit/Compile/Link process. Under MFS, this traditional approach worked fine. However, under HFS, this approach breaks down because development systems must devise various methods of finding include files and trap files now arranged in different directories. The real problem is that HFS really makes the traditional approach of edit, compile and link obsolete. It simply takes too much time to run a program, bomb a program, debug a program, edit, compile, link and try again, when dealing with such a highly interactive and dynamic environment as Macintosh. Servant may ease this problem when available, by bringing a user configurable integrated environment to seperate programs not originally designed to be integrated, making a kind of user constructable LightSpeed environment, with the added advantage that you select the tools to install.

Solving the HFS Problem

The new world of development systems now coming out for the Mac solve the HFS problem by creating a development environment, in which all the files necessary to support the program development cycle is known to the system. These new systems are MPW from Apple, which brings Object Pascal and MacApp in a strong Unix style environment with scripts; TML Pascal 2.0, which also supports Object Pascal and units; and the newest product, LightSpeed C & Pascal, which create a "Project" that bundles files together dramatically speeding up compile and link. Let's focus on LightSpeed Pascal as this product typlifies the new "environment" approach that the Mac interface encourages.

Integrated Tools Speeds Debugging

Mac programming is primarily a process of "discovering" what the Mac ROMS will let you do and how they let you do it. Because of this, re-running programs over and over to experiment is a primary debugging task. With traditional edit, compile and link systems, this process takes several minutes. Make five change and test cycles and you've used up the better part of an hour! With the concept of a "Project", all files are loaded and available, compilation is virtually instant as only the necessary compilation is done, everything else is pre-compiled. Finally, linking is automatic since the project knows both what to link, and what needs to be re-linked after a change. The editing and executing environment are the same, so you can both edit, and execute your program from the same shell, switching back and forth with a click of the mouse between your program's window and menus, and LightSpeed Pascal's windows and menus. Source is always available for editing and source code debugging is fully supported. The result is faster turn-around time in the edit, compile, execute, bomb, re-edit cycle. Instead of several minutes, new attempts are created and tested in seconds. An interactive environment that produces fully compiled double-clickable applications, DA's and drivers.

How it works

The key to LightSpeed Pascal is the project concept. A project is a window and a file that contains a list of all filenames associated with a particular program effort. It also contains compiler and linker information that allows only changed code to be re-compiled and linked dynamically. Since libraries and include files don't have to be re-loaded and compiled as they do on traditional systems, the project approach makes fast turn-around of the compile and link process.

We write a program within our project environment with the LightSpeed Pascal "system". This system includes a multi-file editor. Our editing window is always available, even while our program is running. A build command creates a final application for us that is a fully compiled stand alone program we can move to any disk. For MDS ".REL" files, we can convert them to our project library format with a converter utility, provided. The compiler is fully Lisa and TML Pascal compatible. We compiled last month's keyboard sleuth program without any problem. The system does not have an assembler, so assembly code still must be assembled using MDS or Consulair C systems, and then converted for loading into our project.

The Debugging Process

If your frustrated at trying to marry your development system with MacsBug and TMON, then you'll really appreciate the LightsBug debugging window. Debugging is the key to this system. The system automatically debugs your source code as you type, checking for syntax errors on entry. Instant compilation checks again for normal compilation errors. Finally, running the program again checks for run-time errors. At any time, if an error occurs, you can change the source, look at the debugger window, try some parameter values in the observe window, or change variable values in the instant window. To see what your program is doing, modify the source, set breakpoints and run again. Watch your window while you also watch the debug window! The debug window is automatically linked to the point where your program stopped, showing the heap trail, register values and your global variables. A single click on a global variable, and bang! The debugger shows you a hex and ascii memory dump at the location of the variable.

Figure 1 shows the many windows of LightSpeed Pascal. Our own program window is also available! The project window lists our library, source and include files. Compiler options are set for each file by clicking in the box next to the file name. We change the link order for our project by simply dragging the file name up or down in the project window. No more editing of a link file!

Our source code is shown in another window, and we can open a window for each of our source segments. The observe window allows us to monitor the value of a variable as our program executes. The Instant window allows us to execute program source code or trap calls instantly to observe their effects. If we get what we want, we can paste the line into our source window. Text and drawing have the same purpose they did under MacPascal, but even more important, our own toolbox created windows from our running program are available and clickable along with each of the other windows shown in figure 1.

In figure 2, we see how the observe window works. Here, we've placed a breakpoint at the putstring(s) statement in the source window. After running, our program is now stopped at the break, and the value of s is shown in bold in the observe window. Note that in the LightsBug window, we instantly have the base address of the variable s and can observe it's value in both hex and ascii.

In figure 3, we now change the value of s in the instant window. As we do this, the observe window shows the new value of S, and the LightsBug window shows the new hex and ascii values for s in memory.

In figure 5, we now wish to change the value that is assigned to s directly in memory where our source code lives. We do this by clicking edit and another little debug dialog box opens allowing us to enter a new value directly into memory. As we do this, the LightsBug window shows that what used to be "there!" is now "fere!". This also changes our source code and when we run the program, as figure 6 shows, the new source code value is shown being assigned to s during execution.

Figure 7 shows that our program window exists along with LightSpeed Pascal's windows and we can swtich back and forth by clicking on the spray can (for debugging!).

Finally a Decent Manual

For some reason, Mac development systems have shipped with manuals that assume you already know every language command by heart. Very few even have a simple language definition. If you don't already know C or Pascal, forget it! The LightSpeed manuals are very well done, very large and provide a clear description of the language syntax and commands much like normal manuals on other computers have traditionally done. It is a mystery to me why it has taken this long for decent manuals to be shipped with Mac development environments.

Reaction

I personally think these products will revolutionize how software is done on the Mac. The time saved in testing and re-running programs under development is so tremendous that no one will settle for the large development time required of traditional edit, compile, and link systems. The Mac takes more time anyway in the learning curve of the ROM functions, so anything we can gain in the development cycle is extremely important. But most of all, LightSpeed Pascal will be very popular because no one will want to live without source level debugging with LightsBug if they don't have to. The debugging capabilities will cause people to stop and think if they really need all the overhead of MPW after all.