Customer Reviews

Pro Perl Debugging

5 star:		(3)
4 star:		(2)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

When I first saw a listing for this book, I assumed it was going to be a book about debugging Perl -- the title sort of led me in that direction. I thought it would give an overview of the common mistakes made by Perl programmers, how to catch them, how to correct them, and how to avoid making them in the first place. When I asked about the book, though, I found out that it's a book all about the Perl debugger. I use the debugger daily, and I only use a few of its features, so I was pretty excited about the book -- and even more excited to be getting a copy to review.

The only other book that really focuses on the debugger, as far as I know, is the Perl Debugger Pocket Reference, also by Richard Foley. I picked that up for $10 or so at a TPF auction and found it to be a decent pocket reference. I was hoping, though, that now I'd have a book that would cover the debugger in depth, soup to nuts.

Pro Perl Debugging does that, and it does it fairly well. It begins by explaining how and why the debugger can be used, and then introduces the most basic debugger commands. Subsequent chapters introduce new families of commands and options, and these new features are demonstrated through the use of the debugger on example code. Once all the commands and most of the options have been explained, there are a few chapters on specific challenges in debugging: forking and threading, debugging networked applications (like CGI apps), and regex debugging. The last few chapters cover GUI debugger frontends, profiling and optimizing, and the Perl compiler.

The book covers everything that I think it needs to cover, and covers it well enough that with some coding along, the reader can learn how to use the debugger and nearly all its features.

With all that said, though, I have to add that I think Pro Perl Debugging is an adequate book and not a great one. There are a number of technical errors in the book; most of these are just little mistakes that probably crept in because there was insufficient testing of the examples. While they're minor, they seem sure to cause confusion for readers who try the examples as they go. The examples themselves often seem arbitrary, and don't contribute much to the explanation of new features. At no point in the book did I ever think, "This example really made the usefulness of that new feature very clear." Usually, the feature's usefulness is self-evident, though. Unfortunately, some features are somewhat obscure, and are never very well explained. The dot command, which resets the working position to the current execution point, is particularly confusing. I only fully understood it after piecing together statements made about it across several chapters. The debugger prompt (a related issue) is also poorly explained, with some of its features never discussed.

The book's typographic conventions are ill-suited to the book's material, and in some cases seem to change from chapter to chapter. There is no distinction in the examples between user-entered text and debugger output. Editorial changes to the sample output (elisions, for example) are not handled in a consistent way. The structure of the book is also frustrating. Some chapters appear much later than seems appropriate (that on using the debugger as a REPL, for one). Others repeat material covered earlier. Finally, each chapter begins with a quotation. While this is sometimes a fun addition to an otherwise bland text, here the quotes seem random and the segue from quote to material is often strained.

I'm glad to have a copy of this book, and I've definitely learned some things from it. (Did you know that your debugger can spawn new xterms to handle forked processes?) I really hope that the book gets a second edition, because it has the potential to be an essential book for professional Perl programmers.

I've had this book for several weeks and foolishly ignored it. Part of that was because I was busy with a lot of other stuff, but a large part was that I didn't have much interest: what do I need a perl debugger for? What's wrong with "print"'s?

Boy was I wrong. By the second chapter I was kicking myself for being so stupid. Perl's debugger is a thing of joy - it almost makes me look forward to my next confused Perl program.. well, I'd still rather not have any problem at all, but reading this book gives me a powerful tool to help me figure out where I went wrong.

The authors suggest that some programmers just won't use debuggers. I think that attitude perhaps comes from experience with poor tools; the Perl debugger is an excellent tool. This book shows how it is much like Perl itself: you can use it at a simple level without much effort, but it has tremendous power
available too if you make the effort to learn. This definitely will help you do that.

This one is definitely a keeper.

Perl is one of the easiest language for doing "quirk and dirty" tasks, such as text manipulation and writing command-line utilities for your OS of choice. However, as any Perl programmer can tell you debugging can be a nightmare and most of rely on the old-fashioned print statement to aid most of our debugging work. As powerful as Perl is, one of the drawbacks has always been its lack of an efficient way to debug and test the code. Too often than not more time is spent debugging the code than actually writing the logic to do the task at hand!

In Pro Perl Debugging, Richard Foley and Andy Lester introduce and explain the rarely-seen, often under-utilized Perl Debugger (What? You didn't know one existed; fear not, neither did I until I read this book!). Each chapter takes you through the steps of using the debugger and introduces various new concepts throughout. Chapters are further subdivided into three sections that cover more broader topics such as the final section which is devoted to mainly reference and optimization of techniques learned in the previous sections.

You will learn the concept of what the authors term fixing the bug instead of merely finding the bug. As they point out, a lot of us pursue the task of finding a bug only to introduce other bugs as we try to pinpoint it down. This book provides a working guide to help you migrate from the print statement and sloppy code searching into a more defined, technique driven approach using the debugger.

The book is a great source for the experienced Perl programmer who wants to get a better handle over bug control and code debugging techniques. I would caution beginning Perl users to get a grasp first more on the language before diving into use of the debugger as it can be complex at times. However, seasoned Perl programmers will find a lot of the concepts and techniques given to be a great timesaver and tool for use within programs that both already exist and on the drawing board.

I am an experienced Perl developer and I've been using Perl debugger for years, and yet this book has paid for itself in less than an hour! It includes a couple of sample debugging sessions to familiarize the reader with the debugger commands, and offers multiple helpful tips on saving and replaying command history and setting environment variable to control the behavior of the debugger. And then it moves on to things that I was considering either hard or impossible.

Debugging live CGI scripts running under control of a web server - make Apache drop you into a debugger session after receiving a request, when using either traditional CGI or mod_perl.

Setting compile-time breakpoints to debug the code that runs BEFORE the first executable line in the script.

Debugging processes that fork multiple copies of themselves, controlling each instance through a separate debugger window.

The list goes on - if you do any development in Perl, this book will save you hours of work. I cannot recommend it highly enough.

I was the print/warn debugging type of person before starting my current $job. I knew that there is this command `perl -d ...` but did not really used it. Just tried a few times and then returned back to good ole print(). However, when you are dealing with some HUGE codebase that you did not write (or wrote it 6 months ago), that print/warns can not help you all the time. While using a logging mechanism is also good, it will have limits too. You'll definitely need to use the debugger to see the program flow and test the code while executing it, etc.

Unfortunately, I saw this book rather late. It goes beyond the standard debugger usage and explains most topics in this area. It even encourages you to compile a separate debugging enabled version of perl and discusses lots of different debugging techniques.

A must have for every serious Perl programmer.

Another reviewer said it best: while this book takes a laudable stab at demystifying the Perl debugger, the little errors are enough to drive one bats.

It goes without saying, or should do, that if your material depends on specific content being at specific lines of code, then the source file(s) you provide need to have that content at those line numbers, and not just "in the ballpark." I have already tried to plow through this book's Chapter 3 twice & have twice wound up wanting to throw the book across the room. And the typos, etc. are not limited to this kind of thing.

The authors write well, and the subject has interest, but someone did a poor job somewhere of making sure the finished product (including the downloadable source code) was a useful package.

Please, APress, revisit this one! Please revisit as well the apparent [APress website] policy of allowing readers to submit errata but not view the ones that have already been submitted. To be able to pre-correct one's copy would be a real timesaver for those of us following along in the code.