=head1 NAME
Perlcast Interview 14 - Interview with Richard Foley
=head1 ABSTRACT
Recently, Perlcast interviewed Richard Foley about his book "Pro Perl
Debugging." In the interview Richard talks about the often overlooked Perl
debugger.
The audio of this interview can be found at L.
=head1 PRELUDE
B: Welcome to another Perlcast interview. This interview, recorded on
October 13th 2005, was with Richard Foley. In the interview we discuss
Richard's book "Pro Perl Debugging." For this interview, Apress is giving
away three copies of Richard's "Pro Perl Debugging" book. To get entered into
the drawing, just email perlcast at gmail dot com before December 1st, and let
me know that you want to be in the contest.
=head1 INTERVIEW
B: Today on Perlcast, I am speaking with Richard Foley. Richard is the
author of "Pro Perl Debugging," published by Apress. He also previously
authored "Perl Debugger Pocket Reference" and co-authored "RT Essential,"
both published by O'Reilly. Richard is a Perl and Oracle developer living in
Germany. He's worked in both the aerospace and banking industries. He is an
active member of the Perl community, with contributions to CPAN and the Perl
source. He is also a member of the YAPC Europe committee. Richard, welcome to
Perlcast.
B: Hi Josh.
B: Hi. Well, Richard let's dive on in and start asking some questions.
First, we should probably start off with defining what debugging is. I'm sure
that everyone of Perlcast's listeners does it in one form or another, just not
possibly in the most efficient manner. Would you mind elaborating?
B: Debugging is basically the process of finding and eliminating
software bugs. Well, bugs of any sort, really. The debugger can help you
with that in a number of different ways. Most people probably use a print
statement, generally, because it is a little easier. You don't have to learn
a new syntax. The debugger can be quite formidable to inexperienced users.
But it's really quite a fun tool, when you get to know to use it.
B: Whenever we talk about the Perl debugger, is that actually something
that comes packaged with Perl?
B: Yeah. In fact, it has alway been there from version 1, right back
to stone age of Perl, if you like. Every single version has had a debugger
there. And it's alway been there stable to use. The instructions have always
been there inside the perldoc, which again is something that I find that many
programmers I meet don't actually use perldoc in the way it should be used, an
instant online reference in middle of their programming tasks. They very often
spend a lot of time running around looking on the web for information, when it
is actually right there, accessible from their command line while they are
programming. And it is the same with the debugger. It's always been there.
People just don't use because they are unfamiliar with it.
B: Now, the only debuggers that I have really used have been in visual
debugging environments, and there were breakpoints, watches, tracing, all
these types of things. Does the Perl debugger come with these, and how do you
actually use them, since I am pretty sure that it's not a GUI debugger.
B: Essentially, the debugger is a command line debugger, and yes, it
does support all the standard debugging features, like breakpoints, watches
and tracing, setting actions, and such. Essentially, what you can do with the
debugger is that you can inside your program when it's running, and you can
get it and stop its execution at any time, and then observe all the variables,
or you can inspect the state of your program at any point in its execution,
which can be very useful. In course to make it stop at a particular point
when, say, let's say, for example, a line or file that you are parsing has a
particular content, so you can set a breakpoint to watch a particular
variable, and when this variable contains certain information, the debugger
will stop your program and then you can look around at your leisure at the
data and the state it's in at that moment in time. So it's very useful,
rather then setting, for example, print statements everywhere, and you have to
start your program at the beginning, run it ... wait, and at the end you
might have several megabytes of debugging information, or logging information,
that's been printed to a file somewhere, and then you need to grep through it
for the right information, and you might not have enough information, why,
then you need to go back and start digging around somewhere else, and printing
out dumps of complex data structures, for example, just using the print
command, which can get very messy. You can do all that sort of thing inside
the debugger, without it running on ahead of you, or behind you. You just
stop it, and you can just look around exactly where you are. It's very
convenient.
B: Beyond looking, are you actually able to change the values of
variables, midstream?
B: Yes, indeed. You are basically there inside your Perl program,
and you can execute any Perl statement you want, and it will take in the
context you are in. You can even overload some of the libraries you are
using, and change the code you are about to call. Well, this is going to get
a little bit advanced, possibly, but a more simple example would be just to
simply change the variable you are using at that time, you would just execute
it as a simple Perl statement.
B: You mentioned earlier that the perldoc, and also the debugger, kind
of two tools that come with Perl, that people don't really pay attention to,
or don't use as much or as good as they should, and so whenever it comes to
it, using the Perl debugger, why do so many people not use it? Is it too
slow, or too complicated?
B: It is of course a little bit slower using the debugger on a
program, because it's doing some checks for log on your behalf. And it's a
little bit more complicated, because to use it, you really have to learn a
slightly different set of commands. In a way, the learning curve is a little
steep, but it's very short, it's not really too complicated. Most of the
commands are very intuitive, like "p" for "print" and "h" for "help," "b" for
setting a breakpoint. It is a very friendly environment, but you do just have
to step over the threshold. I use it quite often to try out simple
programming constructs, foreach or map, for example, you know, it's like using
"perl -e" on the command line. You can wrap up a very simple command and
experiment with it, without writing a whole program and going out of the file,
and then running the file from the command line. Which is convenience
mechanism, really. And the more you use it, the more convenient it becomes.
B: And that is something that I did notice in the book that I didn't
realize Perl had, and it's through the debugger, and that is a Perl type of
console, similar to "perl -e," where you can have an interactive programming
console, and, you said you don't really use Python so you don't know, but it
sounds very similar to what happens when you just type "python" on the command
line.
B: Being able to interactively work with your code is a very powerful
mechanism, really. Because, you can just experiment on the fly with all sort
of constructs. You know, simple constructs, or things like when you're
unsure about how somethings evaluates in a list context, or scalar context, or
whether it is a list or scalar context. So you can just experiment and find
out.
B: Okay, so on the subject of the book, you divided into three primary
sections. The first being a general overview of the debugger, the second
takes you through usage scenarios and customizing the debugger, and the final
is a reference section. So, I was just wondering why you chose to layout the
book in this way.
B: It seemed a fairly natural spread for me, I think, I was hoping that
the book would be able to appeal to both people that hadn't really used the
debugger before, hadn't really had much experience in, and therefore the
first several chapters are completely oriented toward the beginner. If you
are a more experienced Perl user and, quite possibly, already a debugger user,
but you weren't sure of all the details, then that is where middle of the book
was going to come more into effect, to get you up to speed there, really. And
of course you need to have a reference, and every books have references,
goodness me. The debugger command, well, there's quite lot of them really,
especially the options. We needed to have some form of definitive reference
of all the various command possibilities and the various syntaxes. Which,
while they are multiplely intuitive, some of them can be a bit obscure,
especially when you get down to the options. You need to have the absolutely
right name in some places. So, you sort of need to know where to look and
that's where the online help, again, comes into hand there. In the debugger
itself, there is a small screen, a help screen, that you can use. That you
can bring up just with a simple "h" command at the prompt. And that gives you
almost all the information you need to know at that point. To get more
information, you would use "h" and then the command name itself.
B: You covered debugging modules and debugging objects separately in the
book, and it seems like those two areas kind of overlap some in Perl because
of the very loose object definitions. So, what is the difference when you're
debugging those?
B: Essentially, a module is just a library. We've come to associate
object oriented programming with little modules, but the two aren't strictly
bound together in that way. I think treating a number of libraries as a
debuggable entity is valid on its own, and there are things the debugger can
help you with there. Equally when you use object oriented code it's entirely
irrelevant whether you are actually using modules or you just got a whole
bundle of code in a single file. You can still set up inheritance and member
variables, classes and so on. And the debugger offers you certain commands to
help you with your object oriented programming as well, like the "i" command,
which just tells you a little bit about the inheritance of the object you're
looking at. Or rather the executable statement you've got in front of you,
but you would normally use it on an object.
B: Whenever I debug CGI scripts, typically I just print out to the
screen and run them through the web browser, or something. So, you can
actually debug [CGI scripts using, or] Perl CGI scripts, using the Perl
debugger, but it does seem like it been a little bit tricky, if not
impossible, honestly to me. So how would you go about doing that?
B: The debugger is a very useful tool when you are dealing with CGI
scripts, just like any other Perl program. There's no particular magic
there. You would just call your CGI script using "-d," where appropriate, at
the end of the Perl path, and the debugger kicks in, takes control of the
situation and offers you a prompt. The point where it gets tricky is if you
are using Apache mod_perl, for example, where you are combining with a web
server and you've got the debugger essentially already sitting inside, well
Perl, already sitting inside C space, inside the web server. Even there,
thanks to Doug MacEachern's work with the mod_perl code, Pierce provided a very
simple interface which you can effectively switch on, and you can step inside
mod_perl, as well. All you have to do is you have to get the server running
in single user mode, and there's a small configuration file change you have to
make in the Apache server config file. And then you can step through mod_perl
programs, just like you can step through any other Perl programs. So, it's
very, very sweet, and very, very, simple. It's not complicated at all. The
only complicated about it is trying it the first time. And once you have done
that you think "Oh, it's so easy, why didn't I do this before." And that's
the case over and over again I found that with the debugger. That people
always where saying "isn't it complicated" or "isn't it strange," you know,
and "how can you possibly do this and do that." And it basically just makes
your live much, much easier and much more straightforward. It's a very
powerful tool that people seem to miss because it's essentially unfamiliar.
I was at one job here in Germany where there were some people on a programming
team here that spent, I think probably months of man-hours, well maybe weeks.
They were trying to get a tracing mechanism in their moderately complicated
Perl code, and they were using caller all the time to essentially step in all
the time and print out stack traces during the runtime execution of their
program. And all of this, of course, comes in standard with Perl. You can
get stack traces, printing out all the arguments going into subroutines, what
the return values are, just with a switch, with the "-t," inside the Perl
debugger. It was an awful lot of work, which would have been completely saved
had they bothered to read the documentation, you know. Which isn't to say
that none of us ever don't like to reinvent every now and then, but that was
an lot of work for absolutely nothing. It wasn't even as good, of course, as
the debugger solution.
B: Whenever you say "reinventing the wheel," I am not sure if this is a
reinvention or an improvement, or not, but there are some debugger
replacements, or at least supplements, that are available, and one of these is
"Devel-ebug." And how does this module actually compare to the Perl debugger?
B: I've not yet time to recall on this to dive into that a great
deal. But I believe that's Leon's newer module, or at least I know he has
been working on one. And I think any approach to making debugging Perl
programs is a good thing. And if there's several debuggers out there to
choose from that can only be a good thing too. There have been various
attempts in the past, I think, to replace the debugger, because it is a little
bit crusty. It essentially had a bit of a rewrite when Perl 5 came in, and
since it has only been extended and extended and extended, and as you can
imagine that led to very spaghetti like bundle of code to maintain, which can
lead to its own problems. Essentially, any further development tools that we
can get our hands on can only be a good thing.
B: Is there any GUI to sit on top of the debugger to maybe make it
easier for beginning users to use that, other than the command line where you
have to remember the commands?
B: Yeah, the classic one is probably coming from the UNIX background,
is the ptkdb, the Perl/Tk Debugger interface, which works very well with all
the Linux platforms. You just have Tk installed and you can run that. And
that's a very mouse oriented debugger interface, and quite friendly. The
other one, quite well known, is the Komodo debugger and Perl IDE from
ActiveState, which, because I work mostly on UNIX and Linux I don't have
actually much experience with. But from what I have seen of it it's very
sweet. Any of the GUI interfaces that are available. Excellent particularly
for CGI debugging. I mean, this is the case where with ptkdb, for example,
you can set a display variable where you are using it. A neat little trick is
the Perl code that's running by a web server will send a window to wherever
set the display variable to, and you can debug from there. So you can debug
from a completely remote machine.
B: In the book, you also show how to debug threaded applications and POE
based applications. So, what kind of special support does the debugger have
to make debugging these types of applications easier?
B: Where POE is concerned, really, there is all the extra support
needed, because it's simply a single running application that's pretending to
be threaded, or forked. So it works with that quite happily. Where you are
using actual fork calls, and some program do, the debugger does support that.
The only problem at hand is setting up a new console. And than you have to a
little bit of higgery-pokery to get the correct console running, the correct
xterm. The support for forked programs is moderately limited, but it is
actually there. What we actually need is for some fork experts to come along,
and to write all the various chunks of code to support the debugger on those
platforms. The main problem at the moment really is that the Perl debugger is
running inside what it thinks is an xterm, and it doesn't really know how to
create more, because you need a new input and output for the debugger itself,
not the program as such. There is some minimal support there for forks.
Where threads are concerned, that was a problem until quite recently, because
all the variables inside the Perl debugger were being shared among all the
threaded programs, and no one really knew which variable was in which thread.
And that led to some quite interesting results. But that was fixed quite
recently, 5.8.5 I think. And you can now use the Perl debugger with threads
as well.
B: One feature of the debugger that looks really neat was the ability to
debug regular expressions. But before we dive into that, a non-debugger
related tip for working with regexes was to avoid contracting the "Leaning
Toothpick Syndrome," and what is that, and how do I avoid it?
B: Right, Leaning Toothpick Syndrome is when you normally have a
regexp, you normally start with a forward slash and then you end with a
forward slash. And so, if you got any forward slash in your regex, like for
example in a typical path name on a UNIX like system, it can get very
confusing very quickly, which is the start slash and which is the end slash,
and which is the slash in the middle, and has it been backslashed yet to
escape it. If you just use different delimiters at the end, maybe a comment
mark or open and close brackets or braces, that can make the regex a lot
easier to read. And then you don't have to backslash your forward slashes any
more, and you no longer get the Leaning Toothpick Syndrome. So when you just
have so many forward slashes and backslashes to try to keep them in sync, it
get very bitterly confusing.
B: Regular expression debugging seem to produce a lot of data, but then
again regexes are almost miniature programs within your script. So, what types
of information and controls does the debugger provide for regular expressions?
B: The debugger itself doesn't actually provide terribly much regex
support itself. It uses what support there is in Perl already. Perl has its
own regex engine, that will give you a lot of information if you ask it
correctly. It seemed moderately relevant to include a chapter on this in
the book, because there was so little information about it anywhere else, and
people do have problems with their regexes. So it's nice to see one thing
exploded. Essentially, you've got a couple of choices with regexes. You can
use the C pragma, use regular expression module then or pragma
(C