Buddy Burden

Short Version: I’ve released version 2.04 of Debuggit.  It allows you to substitute Data::Printer for Data::Dumper when dumping variables.

Long Version:

If I’m known for anything on CPAN (and I’m not saying I am), it’s probably for my work on other people’s modules: my co-maintenance of Method::Signatures in particular, or perhaps my co-maintenance of Test::File (both of which I’ve talked about before).  But the first CPAN module I ever released was Debuggit.

I wrote a post upon the occasion, on my other blog.  I didn’t put it here, mostly because I hadn’t started this blog yet.  But also because it was more of a philosophical musing on procrastination than a useful commentary about CPAN or my particular module.

In fact, I haven’t talked much about Debuggit on this blog.  That’s partly because it’s one of those modules I wrote for me, and I don’t much care if anyone else uses it or not.  I’m not in the business of evangelizing in general, but, if I were, I’d spend my time telling you how cool Method::Signatures is, not Debuggit.  Debuggit is just a little thing, a bit nifty, but nothing you couldn’t write yourself, most likely.  Nothing you haven’t already written yourself, most likely, or at least some version of it.  But perhaps my version, which I’ve mucking about with for over 10 years now,^* has something which your version(s) didn’t, or don’t, so perhaps it’s worth chatting about for a bit.  Or you can just completely ignore me; I’m fine with that too.

So the idea behind Debuggit is, sometimes you need to put output in your Perl scripts to tell you the values of variables, or just to let you know how far your program is getting before it bombs out.  You could use the debugger for this, but some people don’t like debuggers—I personally developed a distaste for them ever since I once spent 3 days tracking down a bug in a C++ program that it turned out didn’t even exist outside the debugger—or sometimes it’s hard to get to the code you need to debug (perhaps it’s in a BEGIN block, and you forgot how to make the debugger run through that, or perhaps it’s being run in mod_perl), or sometimes you just forget what all the single-letter debugger commands are and you just want an alternative.  So you start putting in print statements, until you realize that STDOUT is buffered and you might not be seeing all the statements that are executed, so you change to print STDERR statements until you realize that warn would be much easier to type, so you do that until you realize that in some mod_perl setups warn and print STDERR can go to two different places, or what if you have a SIGWARN handler or you have Carp always doing stack traces?  Anyways, you pepper your code full of output statements, of whatever stripe, until you find the problem, and then you take them all back out.

Until the next problem, when you have to put them all back in again.

So your next attempt is to create some global variable called $DEBUG which allows you turn all those output statements off at once, so now you just leave them in all the time.  Of course, now they’re in all the time: they take up memory, and they take up execution time (even though the output never gets run, the if $DEBUG is always evaluated, over and over again).  It’s not much memory or time, of course, and in most instances you’ll never even notice, but then again what if it’s in some tight loop, which is called by another loop?  You can’t guarantee that it’ll never matter if you just leave them in ... right?

But then you discover use constant and the magic of compile-time folding, and warn("foo") if DEBUG turns out not to take any memory or execution time at all, if the DEBUG constant is set to 0.  So that’s nifty.  Of course, you may other have annoyances, like constantly having to remember to put spaces between your arguments so your output is readable, or what if your variable has leading or trailing spaces? that can be hard to see sometimes, and then if your variable is undefined, you get a nasty “uninitialized” warning, and, if you have warnings set to fatal, that will actually blow up your program itself, and what if your variable is an arrayref or hashref? then what you really want is to use Data::Dumper to print it out legibly, except you really don’t want to leave a use Data::Dumper lying around in your code for eternity because Data::Dumper can eat a healthy chunk of memory, depending on Perl version and DD version and various and sundry other things (phases of the moon? I have no idea, actually), so ...

So you really don’t want to have to think about all that crap, right?  You just want to slap some debugging in your code, be able to leave it there forever, not have it take up any extra memory or CPU time, and not to have to remember too many special rules to make the output look nice.

You want Debuggit.  You just never knew it.

Anyway, Debuggit handles all that, and more, like letting you trick out where your output goes, what it looks like when it gets there, and add little “debugging functions” like the default one that calls Data::Dumper for you:

use Debuggit;

my $hash = { some => 'very', complex => 'hashref' };

debuggit("hash is currently", DUMP => $hash) if DEBUG >= 3;

Of course now Data::Dumper is old and busted, and Data::Printer is the new hotness.  So I fixed that:

use Debuggit DataPrinter => 1;

my $hash = { some => 'very', complex => 'hashref' };

debuggit("hash is currently", DUMP => $hash) if DEBUG >= 3;

Perhaps one day I’ll change it so that Data::Printer is the default and you have to specify DataPrinter => 0 to get Data::Dumper.  But this is good for now.

Anyways, I mostly put this on CPAN because I got tired of trying to send people a tarfile of it, not so I could convince the world to use my super-cool debugging module.  But, then again, if you want to check it out, that’s cool too.  Maybe it’ll be as useful for you as it has been for me.

* The original version of Debuggit was called Barefoot::debug, and my first commit to it was on August 28, 2000.