Pro Perl Debugging

Michael J. Ross writes "The typical computer program has more bugs than there are ants at a picnic -- except ants are usually easier to find. Programs written in Perl are no exception, because the compactness of the language does not make any existent bugs easier to spot; they can simply be packed into fewer lines of code. To help remedy this problem, Richard Foley and Andy Lester, two seasoned Perl programmers, offer a new book, Pro Perl Debugging: From Professional to Expert." Read the rest of Michael's review.

Pro Perl Debugging: From Professional to Expert
author	Richard Foley with Andy Lester
pages	269
publisher	Apress
rating	8
reviewer	Michael J. Ross
ISBN	1590594541
summary	A comprehensive tutorial and reference for the Perl debugger

This title was published in hardcover in March 2005 by Apress, a relatively new member of the technical publishing world. The publisher has a Web page for the book that includes links to all of the source code in a Zip file, the table of contents in PDF format, and a form for submitting errata. The book comprises 269 pages, the majority of which are organized into 16 chapters: Introduction (not to be confused with the true Introduction immediately preceding it), Inspecting Variables and Getting Help, Controlling Program Execution, Debugging a Simple Command Line Program, Tracing Execution, Debugging Modules, Debugging Object-Oriented Perl, Using the Debugger As a Shell, Debugging a CGI Program, Perl Threads and Forked Processes, Debugging Regular Expressions, Debugger Customization, Optimization and Performance Hints and Tips, Command Line and GUI Debuggers, Comprehensive Command Reference, Book References and URLs.

For programmers who wish to learn how to fully utilize Perl's debugger, what options are open to them? A terse summary of the debugger's commands are always close by, within the debugger itself. Those Perl coders who have yet to try the built-in Perl debugger, really owe it to themselves to give it a whirl. In most cases, it is superior to embedding lots of "print" statements in your scripts, and then wading through the results. Simply include perl.exe's -d flag on the system command line, and you should be put right into the debugger, and see the debugger's "DB<1>" command prompt -- the "1" meaning that it is ready for your first command. To display the aforementioned command summary, simply enter "h", or "|h" to see the output one screen-ful at a time, which you will probably want to do unless your system window can show all of the dozens of lines at once. The command summary is best used as a quick reference, and naturally cannot be expected to serve as any sort of tutorial. Yet it has its use, and for that, it's fine.

Most Perl books devote at least some space to explaining the basics of firing up and using Perl's debugger. The (in)famous "camel book," Larry Wall's Programming Perl, has a chapter on the debugger. It covers breakpoints, running, stepping, tracing, displaying code, commands, debugger customization, debugger options, unattended execution, creating your own debugger, and performance profiling. Aside from that last topic, the chapter is mostly an expansion of the command summary mentioned earlier. It is sparse on examples, and does not cover any advanced topics, such as using the debugger in the context of forking, threads, and POE, as well as the debugger's special capabilities for regular expressions, CGI programs, and shelling out.

The advanced topics are where Pro Perl Debugging really shines in relation to the coverage that I have seen in any other book, partly because the authors have the space to thoroughly explore those topics in depth, and to provide much more meaty examples, with adequately illustrative sample code. Even for the more complex topics, the writing is clear, and the examples are worthwhile.

The authors clearly intend for the book to serve as both a comprehensive tutorial and a reference for the Perl debugger. In both respects, they succeed admirably. But the practical value of their accomplishment could be called into question by any programmer who has grown tired of the limitations of the Perl debugger, and has switched over to any Perl-capable standalone GUI debugger or integrated development environment (IDE). More specifically, watching a variable change value, while stepping through the lines of a Perl script using the debugger, requires that the programmer manually or programmatically echo that variable's value, by issuing a print command ("p") followed by the variable name, one way or another. This process quickly becomes tedious when multiple variables need to be watched, because each individual variable must be printed, one at a time. Admittedly, previously entered print statements can be recalled by using the up-arrow key, but only if the particular command has not been pushed out of the debugger's limited storage. This usually becomes even more frustrating when trying to print the values of indexed arrays, hashes, and nested arrays and other structures. There are workarounds, but none are pretty, and even the most promising techniques still seem to require excessive focusing on the debugger commands themselves, drawing attention away from the code being debugged.

As a result, some disheartened Perl coders eventually switch back to embedding "print" statements in their code. Fortunately, there is a better alternative, in the form of IDEs, which can automatically report the changing values of a large set of variables, none of which need to be typed in, owing to the drag-and-drop capabilities of most IDEs. There are many IDEs available, including freeware and open source offerings. Most if not all of them support advanced editing, syntax highlighting and verification, visual breakpoints, and other much-appreciated capabilities. Even if they were to lack all of these features, and only have the advantage of easily and dynamically displaying the current values of variables, then they would be much more pleasant to use than the built-in Perl debugger. This is especially true in the case of nested structures, which can be expanded with a mouse click within most IDEs. All of this being said, it should be noted that the authors include a chapter that briefly touches upon the most well-known Perl GUI debuggers -- but at only seven pages in length, the chosen applications get only a cursory treatment, highlighting their major features.

Nonetheless, given the intended purpose of Pro Perl Debugging, and its target audience, the book cannot be faulted for its contents nor its approach to presenting the material. Anyone looking for a detailed and competent explication of the native Perl debugger, would likely not be able to find a more thorough treatment anywhere else.

Michael J. Ross is a freelance writer, computer consultant, and the editor of PristinePlanet.com's free newsletter."

---

You can purchase Pro Perl Debugging from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

In defense of print statements

[winkydink]

Properly placed and well-thought out, I can leave:

print "a bunch o' stuff\n" if $Debugging;

in my code forever and never have to go through the trouble of firing up an IDE.

Compactness of language????? wtf

[iggymanz]

Perl is a very bloated scripted language, now ruby is compact, and python somewhat compact, but Perl is surely the RPG-II of the scripting language world. And yes, I've been using Perl for over 9 years, and written tcp daemons and web portals in Perl. I love/hate it.

Re:I luv Perl, but...

[winkydink]

IMHO, that says more about the programmer than the language.

use strict and Data::Dumper!

[licamell]

#! /usr/local/bin/perl
#
# Two things that make debugging perl easy:
#

use strict;
use Data::Dumper;



The first one will solve most peoples perl problems, and the second one is helpfull sometimes when dealing with complex datastructures.

Re:In defense of print statements

[Billosaur]

print "a bunch o' stuff\n" if $Debugging;

Alternatively, I convert print statements into logging facilities:

open LOG, ">> $log_file" or die "Can't open $log_file: $!\n";
# Magical happenings
print LOG "And this happens here...\n" if $debug_flag;

I can then match things up to my pseudocode and determine if I'm pushing values around the way I should. Of course it's made a a lot easier with "use strict;" and the -w switch enabled.

Re:In defense of print statements

[hattmoward]

How many times is that conditional checked at runtime? They can add up. In perl, you could have it optimized away at compile time...

sub DEBUG() { return 1; }

...

DEBUG and print "value of blah:", $blah, $/;

but... TIMTOWTDI ;)

Re:Obsolete before printing?

[Baron von Leezard]

I've been a serious Perl programmer for about eight years, and I never use an IDE. I always do my debugging at the terminal. [I do use a syntax highlighting editor.] I understand that a lot of people like IDEs, but I find them annoying and hampering. I'd prefer to have a text mode debugger pipe a large data structure to less and let me use / and ? to find various things in the pager. I haven't found an IDE yet that lets you do that easily. This is a very useful technique--especially in the perl debugger, where you can run arbitrary perl code at any point in the program and pipe the output to a pager.

Moveover, you're assuming that you can run an IDE in your development environment. I often have to work on deployed server systems that have neither a windowing system not an IDE installed. However, I can always run the perl debugger and interact with it in an SSH session.

[B/v/L]