Visual LISP: Hunting Down Problems - Part 2

Julius Caesar would have made a great programmer. In my view, his battle strategy of "Divide and Conquer" is still the best way to develop a complex application. Divide up the application into chunks and attack each separately. Once you are satisfied that a chunk of the design is operating correctly, proceed to the next chunk and develop it. When all of the chunks are operating correctly, you can tie together the application with confidence. In my own experience programming large applications, I find that if I'm confident in how I've developed a particular module and know the boundaries of that module's accepted input, then I can track down problems very fast when they appear.

The Visual LISP™ integrated development environment (VLIDE) is a powerful tool for developing chunks of programs and then putting them together into larger applications. Last month I introduced the concepts behind breakpoints in programming and showed you how to use them in debugging a programming task. This month we are going to dig into more of the Visual LISP debug tools and take a look at:

How the VLIDE alleviates the problem of missing or extra parentheses.
How to use the keyboard to select code fragments or functions.
Breakpoint tools in the VLIDE.

Missing or Extra Parentheses

One of the most frustrating problems you'll encounter as a programmer is an imbalance in the parentheses in your own coding—or in someone else's code, which you may be trying to debug. (That's why LISP is sometimes referred to jokingly as Lost In Stupid Parentheses.) Before Visual LISP I told my classes that you could tell the best LISP programmers because they wore sandals to help them count up to 20 open parentheses (10 on the fingers, 10 on the toes). Keeping track of how many closing parentheses are needed when writing complex code used to be part of the job, often requiring you to read back through the program source and count again.

But now Visual LISP makes parentheses balancing easy in two ways:

Source code is automatically formatted every time you press the Enter key.
The Ctrl+[ and Ctrl+] key combinations jump the cursor to the next opening or closing parenthesis in the code.

Let's take a closer look at both functions.

Figure 1: Ready for next entry.

Type the expression (setq A 10 and press the Enter key (see Figure 1). Because you started the SETQ expression, the cursor automatically indents directly under the symbol name so that you can enter the definition of the next symbol name.

Pressing the closing parenthesis quickly highlights the code segment back to the starting parenthesis, providing a rapid view of the nesting. At first I found this behavior annoying and did not appreciate what it was doing for me. Then I started using it simply to count off closing parentheses until the program was back to the level I wanted to continue coding at. Now I use this feature all the time.

Note: You can control the style of formatting that is used in Visual LISP, which we will explore in a later article about the VLIDE and how to get the most from it.

I find the Ctrl+[ and Ctrl+] key combinations most useful when looking at code created a long time ago or by someone else. Oftentimes you need to insert new code into an existing expression and that can be difficult if the expression is deeply nested because PROGN is strategically included to allow more expressions to be evaluated and so forth. Using the Ctrl+[ and Ctrl+] key combinations I can quickly find where the balancing parenthesis may be needed after inserting a new level of nesting into an existing program module.

Selecting Blocks of Code

The bracket-jumping tool enables you to quickly check code you have just entered or are inserting from one module into another. And once again, the formatting tools are quite useful in this regard. You can select a function or group of expressions by using the Ctrl and Bracket key along with the Shift key. Hold down Ctrl+Shift+[ to select back to the previous balancing open parenthesis. Hold down Ctrl+Shift+] to select forward.

Thus, if you want to select an entire function, use Ctrl+[ to move to the (DEFUN expression, and then hold down Ctrl and Shift while pressing ]. This operation selects the entire function so you can quickly see if the function's parentheses are properly balanced.

This operation is also handy when you're importing a program and want to reformat just a selection of the code or a function. Start by selecting the function as just described and then click the Reformat Selection button (see Figure 2). The code is reformatted and in most cases is easier to read.

You can also load the function by clicking the Load Selection button (see Figure 3) or check the syntax of the code using the Check Selection button (see Figure 4). When the function is loaded, you can evaluate (run) it by typing the name at the console (_$ prompt) or in AutoCAD® software at the command prompt.

Figure 3: Load Selection button.

Figure 2: Reformat Selection button.

Figure 4: Check Selection button.

Using these buttons won't verify or validate your program. What they can do is quickly locate areas where there are parentheses imbalances and look at the parameter lists of the reserved functions to see if they are properly stated. If you type in an improper name for a function, the checking won't catch it because it assumes you have created a function elsewhere that uses that name. On the other hand, using these buttons will catch problems such as an incorrect number of arguments to a function and improper constants. And what is nice is that you merely need to double-click the indicated error and it is displayed in the source code window. In most cases the parentheses block that is in error is highlighted. Just look at the first part of the highlighted area if there are too few parentheses and towards the end of it if there are too many.

The sequence of checking, loading, and then testing functions is the best path to developing any complex application. Divide the task into functions or groups of functions that you can test independently of the entire application. You can fake the input to the function by just assigning global symbols to the values expected and then perform the tests. Suppose your example function requires a selection set of just text entity objects. In that case you can create a selection set ahead of time that contains the types of objects you expect and supply it as an argument to the function.

More About Breakpoints

As you create complex applications, you may need to go back and revisit some of the previously created modules to allow for additional items "discovered" in the development or to test some new twist to the input data. Given this possibility, think about preserving any breakpoints (see Part 1 of this article) that you find useful in the modules you're creating. They will come in handy as you move on to other modules and eventually start to tie the entire application together. Of course, residual breakpoints may be a nuisance in your testing. But just temporarily turn them off as you test other aspects of the program.

Figure 5: Shortcut menu at breakpoint.

You can do this through the Breakpoint service dialog box:

1. Place the cursor over the breakpoint you want to disable and right-click.

2. Select Breakpoint service from the shortcut menu that appears (see Figure 5).

3. At the Breakpoint service dialog box that appears (see Figure 6), select the Disable button to temporarily turn off the breakpoint.

Note: To turn the breakpoint back on, repeat the process by selecting the Enable button (it will replace the Disable button in the second presentation of the dialog box).

Figure 6: Breakpoint service dialog box.

Here's another way to access breakpoints defined in your program modules:

1. From the main menu, select View > Breakpoints, which opens the Breakpoints dialog box (see Figure 7).

At the beginning of each breakpoint will be a plus sign or a minus sign signifying that the breakpoint is enabled or disabled respectively. Following the plus or minus sign will be the name of the source module in which the breakpoint resides.

2. To jump to a particular breakpoint and view the associated code, select the breakpoint entry in the list and then click Show. The code where the breakpoint is set will be displayed.

3. To enable or disable a breakpoint, select the breakpoint entry in the list and then click Edit. A dialog box will be displayed as in Figure 6.

Figure 7: Breakpoints dialog box.

Breakpoints, parentheses-balance testing, quickly moving through blocks of code, and syntax checking are wonderful tools that speed the application development process along once you master them. Because they are new in Visual LISP, many AutoLISP® programmers may not be entirely aware of all the power they possess. So you are strongly urged to experiment with them.

Also keep in mind that programmers wrote the VLIDE for other programmers, which means it will save you time and increase productivity. It also means that some of the tools are complex and are not intended for beginners.

Next time we’ll be taking a look at how to organize your programs using Projects in the VLIDE. Keep on programmin'!