Pro Perl Debugging 164
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.
I luv Perl, but... (Score:1)
Re:I luv Perl, but... (Score:5, Insightful)
Re:I luv Perl, but... (Score:2)
Re:I luv Perl, but... (Score:2)
But isn't that the point of writing your own code?
Re:I luv Perl, but... (Score:2)
What do you mean by "optimized down to nearly the size of machine code" though? I'm not sure what you're talking about.
Re:I luv Perl, but... (Score:3, Interesting)
Hey, just cuz you can't write a decent regex...
Re:I luv Perl, but... (Score:2)
Re:I luv Perl, but... (Score:2, Interesting)
> (a page generator for 195 content categories in2 languages from
> source data files) than it would have to write it in perl and
> debug it.
*shrug*. Maybe you just think Guido's Way. Some of us don't. I tried to learn Python, but every time I tried to do anything in it, I ran into frustrating scenarios wherein I'd need to write eighty lines of code just to do something really simple. Maybe it's because I didn't know Python well
Re:I luv Perl, but... (Score:2)
Learning enough python to do the job took less than an hour.
If you already have a decent background in c and at least one scripting language, say php, you should be good to go.
The hardest part? I kept putting in semicolons.
There'
Re:I luv Perl, but... (Score:2)
Ouch. My condolences :-)
There were newspaper reports of a teenager who had to undergo therapy because he got to the point where he WAS thinking in basic. Literally. His thoughts, if he wanted to do anything, ended up being short snippets of "code", complete with line numbers.
Re:I luv Perl, but... (Score:2)
Or just use something like [^>] (if you're looking for a closing angle bracket to end a phrase).
Re:I luv Perl, but... (Score:2)
Re:I luv Perl, but... (Score:2)
What do you want, $x matches a_letter_between_a_and_z or something?
There's a reason lot of languages have adopted the Perl regex rules (which were in turn based on earlier Unix programs). Don't blame your failure to understand the technology ON the technology when millions of us do just fine.
Those that decry the complexity of regexes often have yet to realize how powerful they are, when used correctly.
Re:I luv Perl, but... (Score:2)
Oh, wait - its easier to just rewrite the damn thing in pretty much ANY other language. Its not a question of understanding it - its a question of maintainability. Isn't that what debugging is about 90% of the time - fixing bugs that creep in because code is, in fact, NOT maintainable?
Re:I luv Perl, but... (Score:2)
2) learn to use the language
3) No, it's intentional.
What language zealots (of ANY language) fail to realize is that there are different styles of coding for different uses and different users. Insisting that there is ONE TRUE WAY to program isn't a sign of wisdom...
Re:I luv Perl, but... (Score:2)
Perl has its uses - but not on large projects or long lifetimes. Its ambiguities in terms of language structure renders it pretty much unmaintainable.
As for the whole "learn to use the language" - I've been using it for years. In terms of maintainability of code, c has it beat by a mile. Perl has got to be one of the worst languages around in that respect. And that's what the topic is - debugging perl. I
existent? (Score:1)
Re:existent? (Score:2, Interesting)
extant [bartleby.com] and existent [bartleby.com].
Re:existent? (Score:1)
In defense of print statements (Score:5, Insightful)
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.
Re:In defense of print statements (Score:3, Insightful)
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 (Score:5, Insightful)
Re:In defense of print statements (Score:2)
Re:In defense of print statements (Score:2)
BTW, you might want to take a look at mod_perl. It's speedy.
Re:In defense of print statements (Score:2)
My comment was not about my time vs computer time, but overall program execution time.
Re:In defense of print statements (Score:2)
Re:In defense of print statements (Score:2)
Re:In defense of print statements (Score:2)
The empty prototype is a requirement.
Re:In defense of print statements (Score:3, Informative)
I didn't see that anyone gave you the full explanation here. What happens is during the compile pass (perl first does a parse/compile pass, then executes), it encounters the definition of sub DEBUG(). The closed parenthesis indicate that this sub will never accept any arguments -- not like a C prototype, more of a compiler hint. It effectively becomes a constant within this package that never needs to be written as DEBUG() because there is no ambiguity as to whether there are parameters. During the comp
Re:In defense of print statements (Score:3, Informative)
Re:In defense of print statements (Score:2)
Re:In defense of print statements (Score:4, Informative)
This is vital when you code just plain blows up. Using "print" means that a statement which got executed before the disaster may not make it to console, thus leading you to believe that it never got executed. "warn" avoids this problem and thus leads you to the problem more accurately. It also makes it easy to globally comment out the warn statements before going releasing the code.
Re:In defense of print statements (Score:2)
Re:In defense of print statements (Score:2, Informative)
Exactly. And that's what warn does. It prints to STDERR.
Re:In defense of print statements (Score:1)
use Smart::Comments;
### Expected: "a bunch o stuff" Got: $stuff
. . . and have debugging statements that are easier to write, can be turned off in one place, and don't waste efficiency checking a bunch of conditionals.0 .1/lib/Smart/Comments.pm [cpan.org]
see http://search.cpan.org/~dconway/Smart-Comments-1.
Re:In defense of print statements (Score:2)
I still think vim is the best development environment, but even gtkvim is just a fancy xterm with a toolbar and menus. Hopefully soon a better developer than I will take vims powerful commands/features and mangle it into a full blown IDE with
Re:In defense of print statements (Score:2, Interesting)
Re:In defense of print statements (Score:2)
The only real way (the perl debugger sucks beyond belief and is only there for little bittie programs, and I've tried using it to debug client/server problems) is to use the perl debugger is through emacs, and the GUD interface, but I've given that up in favour of Log4perl.
Compactness of language????? wtf (Score:2, Insightful)
Re:Compactness of language????? wtf (Score:2)
Re:Compactness of language????? wtf (Score:1)
Re:Compactness of language????? wtf (Score:2)
Re:Compactness of language????? wtf (Score:2)
Re:Compactness of language????? wtf (Score:1)
Obsolete before printing? (Score:4, Interesting)
I suppose this might be handy a bit the same way knowing something like ed or vi is handy for anybody using UNIX (or similar) systems -- even the absolute strangest distribution (or installation) will almost inevitably include at least that much and it's pretty consistent. OTOH, debugging Perl on a machine that hasn't really been equipped for it doesn't sound to me like a lot better idea than using ed to write most of my code...
Re:Obsolete before printing? (Score:2)
but, but, ed is the standard editor [gnu.org], dammit!
Re:Obsolete before printing? (Score:2, Insightful)
Credentials completely shot in 3rd PP (Score:2)
Also, lets see if we can debug the website and make that next button work......Not functioning in FF1.5/Win
-B
Perl makes bugs very hard to spot (Score:5, Funny)
Debugging?! (Score:5, Funny)
Re:Debugging?! (Score:2)
If it's Tuesday . . . (Score:5, Funny)
Unless the moon is gibbous.
Re:If it's Tuesday . . . (Score:2)
PS I'm sorry if that perl oneliner doesn't work when you try it, but I'm taking the server offline for short periods of time while doing some upgrading... If it's down when you try it just try again a minute later.
use strict and Data::Dumper! (Score:5, Insightful)
#
# 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:use strict and Data::Dumper! (Score:1)
I one was hired by a company that did a lot of C programming, and if there was something not working right, the rule was you had to fire up the debugger, and single step. I ignored that silly advice, and added a print statement, or reread my code.
Re:use strict and Data::Dumper! (Score:1)
Seriously, I'm one of those people who use a debugger every day. Actually, when I write new code in Perl, often the first thing I do is step through it in the debugger to make sure it does what I think it should. Especially in Perl, it is very easy to accidentally do something that's a little off. With the "wait until something goes wrong before I investigate" attitude demonstrated here, you'll never know anything is amiss until some
Re:use strict and Data::Dumper! (Score:2)
Excellent. A coder with the same ideals. I do this for Perl, and I did the same thing in C -- run it in the debugger, but only after a severe thrashing through PC-lint (Gimpel Software?) until it came out squeaky clean.
Why? To make absolutely sure that the machine and I are in perfect agreement about what the expected behaviour is. It's time consuming, but bett
Re:use strict and Data::Dumper! (Score:1)
Re:use strict and Data::Dumper! (Score:2)
Re:use strict and Data::Dumper! (Score:3, Interesting)
use Coy; [cpan.org]
Debug this... (Score:3, Funny)
Re:Debug this... (Score:1, Flamebait)
Re:Debug this... (Score:1)
Re:Debug this... (Score:5, Informative)
Re:Debug this... (Score:1, Redundant)
The code or the fact that you read it and understood it at plain site???
God I have some perl scripts but I am afraid to put advertise that I wrote them on my resume. That code proves to me what I never want to become a professional perl programmer if my life depended on it.
Shudder
Re:Debug this... (Score:4, Informative)
The code or the fact that you read it and understood it at plain site???
The code is obfuscated. It basically takes a really big string, and runs it through a couple of regex substitutions to turn it back into perl code, then eval's it. I replaced "eval" with "print", which made it output the code instead of executing it, then I used "perl -MO=Deparse" to clean it up. This gave a compilation error at ($X+$F=$A). Changing that to ($X+$F==$A) makes it compile... but Deparse optimized several whole subs away entirely, and I really don't care enough to figure out exactly what it's supposed to do.
And no, I'm not going to run it.
first half of the deparsed code (Score:3)
$A = 15;
$B = 30;
select stdin;
$| = 1;
select stdout;
$| = 1;
system "stty -echo -icanon eol \cA";
foreach $C (split(/\s/, '010.010.010.010 77.77 022.020.020 330.030.030 440.044.000 055.550.000 666.060.000', 0)) {
$D = 0;
foreach $E (split(/\./, $C, 0)) {
$F = 0;
foreach $G (split(//, $E, 0)) {
$C[$P][$F++][$D] = $G;
}
++$D;
part 2 (working around lameness filter) (Score:2)
sub p
sub o
sub n
sub c
a 'm=0;0 a=0;37;40 c';
print "\n\n" . 4 x ' ' . ' ' x ($A - 4) . "perltris\n" . ' ' x 4 . '--' x $A . "\n" . (' ' x 3 . '|' . ' ' x ($A * 2) . "|\n") x $B . ' ' x 4 . '--' x $A . "\n";
n
part 3 (working around lameness filter) (Score:2)
u
$R = chr 1;
($S, $T) = select($R, $U, $V, 0.01);
if ($S) {
$Z = getc;
}
else {
if ($e++ > 20) {
$Z = ' ';
$e = 0;
}
else {
next;
}
}
My favorite (Score:1)
Re:My favorite (Score:1)
[B/v/L]
Re:My favorite (Score:2)
Print statements (Score:3, Interesting)
Actually, after ~25 years of writing code, I've found that 'print' statements are the best alternative. I've used every kind of debugger and IDE in the past, but in the last couple of years I've found that I rarely use them.
When you're in a debugger, you're down in the trees and it's hard to see the forest. With skillfully placed print statements that pick out the relevant data, stack traces for exceptions and a decent language, you can get a commanding overview of what's going on in your app. With a good editor, you can manipulate print statements just about as fast as breakpoints in an IDE, too. Just map a function key in your editor to "save file; make go".
Re:Print statements (Score:2)
In fact, the best IDEs allow you to have the value of a variable or expression printed every time a particular part of your code is hit, without modifying that code at all. (VS.NET, for instance.)
In the end, you really shouldn't have to modify source code to figure out the value of variables at various points in the execution of that code.
older books (Score:2, Informative)
Effective Perl, Hall and Schwartz
Debugging Perl, Martin Brown
Perl Debugged, Scott / Wright
debugging loops (Score:2, Interesting)
This method will debug loops of all kinds, and if eac
Watched variables (Score:4, Informative)
> 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.
$ perl -d -e 1
DB h
h [db_cmd] Get help on command w expr Add a watch expression
h h Complete help page W expr|* Delete a/all watch exprs
Admittedly, the watch expressions don't detect changes in deep data structures. But it works just find on dependant expressions. I'll regularrly set watches on a loop index and a data structure being indexed by said loop var. The watch expressions will display both results.
In addition, the 'x' command works much better than 'p'. 'x' dumps the data structure, so it will display arbitrarily complex and deep data.
Perl debugger is fine, Log::Log4perl way better (Score:5, Informative)
I love the debugger -- my background is BASIC, assembler, C and finally Perl, so it fits right in with all those "programmning down to the bare metal" tools.
However, a way cooler method is to use logging. The one I use these days is Log::Log4perl [cpan.org], a terrific logger that you can turn on and off at will. Thus, if you have a bit of disk space, you can turn the knob up to 11 (DEBUG) and let the application go until you get to the Weird Bug. Then it's just a matter of pawing through the log files to find all of your excellent messages. Print statements sprinkled through the code? Please.
And the bit about having to print the variable value every step in the debugger is a bit of a red herring .. you can set up commands that get executed before and after each step. Yes, it's a geeky thing to do .. that's why they call it Engineering.
One question (Score:2)
Re:One question (Score:1)
[B/v/L]
Re:One question (Score:2)
Re:One question (Score:2)
Just redirect stdin and stdout to your script, fire up the program in debug mode and have your script feed it debug commands until something interesting (which of course you have predetermined) happens, or in response to your own input (you have of course saved the original stdin and stdout handles so you can still do io to your own program).
Actually, I have only ever done this with gdb but I expect it will work with perl debug too.
PRO perl debugging? (Score:3, Funny)
linking to C libraries (Score:3)
This guy is making money off this post (Score:4, Informative)
Also work4hire refers to his website to make his google page rank go up.
What about more intuitive tools? (Score:1)
IDEs? (Score:2)
nevermind... (Score:2)
Re:Who Uses Perl Anymore? (Score:1, Troll)
Re:Who Uses Perl Anymore? (Score:3, Informative)
Re:Who Uses Perl Anymore? (Score:1)
Not everything needs objects, though Perl can certainly do that. Also, there are fairly large bodies of code written in Perl, which require maintenance. What most orgs use for an IT budget these days isn't going to allow a rewrite of running code unless there's a very clear reason for it. I most cases, you'd have to prove a stunning performance win, or some thumping great decrease in maintenance costs, etc. It would probably n
You must not maintain servers (Score:1)
Re:You must not maintain servers (Score:3, Informative)
Re:Who Uses Perl Anymore? (Score:2, Informative)
I can list several [wired.com] very [yahoo.com] high [ticketmaster.com] volume [slashdot.com] sites/applications [valueclick.com] that [adobe.com] use [imdb.com] Perl [citysearch.com].
Re:Who Uses Perl Anymore? (Score:2)
Re:Who Uses Perl Anymore? (Score:2)
Mod down, same kaleidojewel spam as always. (Score:1, Informative)
And "if you're a pro, why do you need to debug"? Clearly he has no clue about programming, and is only in it for the $0.05 per click you give him.
Re:Isn't it time to bury Perl? (Score:2)
yeah, but for real job security, nothing's as good as being the only person to understand the company's major application written in perl, and even better, you don't have to try very hard to make it so!!!
-- Note to mods: this is an attempt at humour.Re:Isn't it time to bury Perl? (Score:2)
flamebait I know, but have any of you seen the amount of crud that Java projects accumulate these days, unless you know the syntax for the XML files and inheritance hierarchy for all the different MVC/ORM/IOC etc frameworks that get used you are in for a whole load of headaches. If you *dont* use them then you are in for a headache from having to write reams of tiresome code that would just a few short lines in a language such as perl.
Re:Horrible Code I must debug (Score:2)