Long ago I put these two lines at the bottom of a script; nowadays I always throw them into my exception handling modules, but push them to main::.

sub ::D { require Data::Dumper; $Data::Dumper::Indent += 0; local $Dat
+a::Dumper::Indent = 1; Data::Dumper::Dumper(@_) }
sub ::DD { require Carp; Carp::confess(::D(@_)) }

# Then from anywhere, use it like this:
print ::D({ state => $some_obj });
[...]
::DD($obj) if $bugs_exist;
[download]

(The += 0 is just a stupid warning silencer.)

I debug my code with print,
my mind with alcohol,
and my dog with flea powder

chime~

So close to a haiku....

debug code with print
a mind using alcohol
dogs with flea powder


Boots

---
If you are not going to go 95, just avoid our state. Please.
-Ian Sulam

print and perl -d for me between these two I get my debugging done oh, and heavy use of Data::Dumper

I caught some bad bugs that way, and I caught them before they could bite me.

Kevin, your sig code was nagging me. I was able to shorten it down to this:

perl -e '$a="62696c6c77667269656e6440676d61696c2e636f6d";print unpack("A",pack("H*","$1")) while ($a=~s/(^.{2})//s)'

You don't need both the m// and s///, just one s/// will do. And the block { } notation after the while isn't necessary.

hmm ... superdoc's version may be shorter or whatever, but it doesn't run on windoze due to a syntax error. Kevin's has the advantage of actually working.

There :-P

(OK, OK, If I really have to, I resort to print)

Here! Here! Write Tests before you write code! Use iterative incremental development cycles! cog++

Ok, so when I'm up against a wall, I use print. Sometimes when my eyes just do not see the obvious mistake, I'll come to SoPW.

May the Force be with you

Gotta question re: unit tests. In C or C++, I'd do something like this in a foo.c/foo.cpp file:

#define FOO_UNIT_TEST
(various functions or objects... )
#ifdef FOO_UNIT_TEST
int main (int argc, char ** argv) {
(code that tests the above )
#endif

--then I'd just compile the one file when testing, or comment out the first line when integrating.

Is there a similar mechanism for Perl?

but what about maintenance programming and debuging the work of mortal (wo)men

Then I guess print combined with Data::Dumper is my tool of choice :-)

Here here, warn belongs on the list!

My app is a Perl Tk app and has grown rather large. Since I sometimes will have to rerun little bits of debugging steps in the future, I leave my warn statements in the code, just comment them out when I don't need them. The trick is to start all such debug-flavor warn messages in column 0. This makes them easy to distinguish from real warn statements which are indented further into the code. After using the warning for the first time, comment away the warning with an initial # sign.

When I want to reuse a given warning, I uncomment the line, and when I'm ready to turn them off again, finding them is easy in vim because I only have to look for warn at the beginning of lines, i.e. I search for ^warn. When I find an uncommented warn, I do a I# to comment it away again, do a n to find the next uncommented warning and do a dot command to repeat the "comment away" command.

comment them out when I don't need them

Have you considered trying something like

warn "The code is running in debug" if $::debugging;

This way you can just say $debugging = 1; instead of changing many lines of code. vim is a great tool, but it isn't a debugger. For debugging, you need emacs. :-)

Update: You could even have $::debugging set by command-line switches, or an %ENV variable or a CGI parameter. Then you would not need to change any of the code to get some debugging info. This is great if something prevents you from touching the code, for example if it is running on a production web server.

Also along these lines, I like to use lines that start with if 0 and if 1 as additional debugging tools. I particularly use this approach with a little subroutine that invokes Dumper (I could probably do this directly, but anyway). Again, when I want the program to dump the object, it's easy to flip the '0' to '1', and when I'm done with the need to see such output, I can easily find all patterns of ^if 1 and flip the '1' back to '0'.

For example, my "main" script might contain the following:

use strict;
require 'gen_subs.pl';

my $foo = { 'abc', 123, 'def', 456 };

gs::do_dumper( 'foo423:', $foo )   # 423 a silly, easy-to-find label
if 0;
[download]

and a helper file/libary named 'gen_subs.pl' might contain:

package gs;

use strict;
use Data::Dumper;

sub do_dumper {
    my ( $label, $variable ) = @_;
    my $msg = Dumper( $variable );
    warn "$label:\n$msg\n";
}
[download]

Yeah, I use warn too... print is kinda useless in a mod_perl environment.

I try to avoid bugs by thinking about what I'm coding and writing tests. But everyone is fallible.

--
John.

Do you mean, that emacs supports step-by-step debugging for Perl, or it is your own chortcut/copy-pasto circuit?

In case your technique is supported for emacs, then it is a thing that Vim can not do, but emacsers easily do; am I right? What other languages also supported?

(I am not going to start discussion about what editor is better)

The Emacs perl debugger is available via the GUD, the Grand Unified Debugger and cperl-mode.

It looks a little like this.

--
John.

it is a thing that Vim can not do, but emacsers easily do; am I right?

No. Vim can embed Perl, Python and Ruby. You can do anything with Vim that you can do with Emacs.

Makeshifts last the longest.

then it is a thing that Vim can not do, but emacsers easily do; am I right?

There are a *lot* of such things.

Read more... (3 kB)

That said, I use gdb a lot lately, since my new job at work is getting some existing C code up to snuff for a new FDA-mandated standard.

Still, I love the debugger in XCode on OS X. It's like most things you get from Apple. You think it's nice, but when you use other similar tools, you really appreciate just how good it is.

Hi, monks,

I usually use print and sleep commands for debugging.
If any logical problem in my coding then i can use Perl IDE,
It shows all the details of variables and other objects status what we require in output?.

Thanks

At the most time I am using PerlIDE to debug the script. But some time i give print statement.

I always debug using print statement

I have to see the values for all the variables, i often use PERL IDE

Regards,
Gubendran.L

perlbug

I assume all bugs I find are actually bugs in Perl, so everything that goes wrong goes there first.

</removesTongueFromCheek>

print/warn and Devel::Trace. Very useful module, you want it in your toolbox.

Makeshifts last the longest.

You'll also want to add Devel::TraceCalls, very useful in learning how modules operate (for example CGI::Application::Loop).

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

My biggest problem is not so much the bugs, but that my programs do what I've told them to do, not necessarily what I *want* them to do. :)

Beware false hubris.

Surely.

print STDERR __PACKAGE__ . ":" . __FILE__ . "-" . __LINE__ ;

What bugs?

I prefer Perl bugs, than to have no Perl at all. Earnestly I am debugging with warning switches etc. and tracking the output. So I should have better said "print".

Any way, there have been some good discussions about finding and avoiding the bugs in this forum (say monastery?) and I think this is very helpfull.

Mr. Lee

Code: print

Data eitherData::Dumper or I email vars/arrays/hashes to myself (for "uninterrupted" look at data)

SQL I use trace

Repeat after me: right tool for the job... right tool for the job.

How I go about debugging any code no matter what language it is written largely depends on the nature of the bug that I'm trying to find. Cockroaches won't come out when the lights are on, so I turn the lights off and then back on again after a while and see which way they scurry. Better yet I set up a cockroach trap and trap the little vermin.

First step in debugging is defining the nature of the bug. Is the pattern of how the bug manifests itself immediately apparent. (I.E. turn on power, smoke results every time. That's pretty apparent.)

Or is the bug more sneaky? Only shows up when you are in the middle of a good sleep dreaming about <insert sex symbol here> and having a great time of it.

Is it a data driven bug? Is it a Luser driven bug? Does it depend on planet alignment?

These are all crucial questions to ask before deciding how to go about debugging a program.

Actually, I use perl -d for any command line scripts, but for anything large and complicated, I reach for Log::Log4perl -- and I'm surprised that wasn't on the list.

Only one person uses Tie::Watch? Is it that unhelpful, or that obscure?

...then again, only 4 people admitted to using SoPW to debug, and I know that isn't accurate...

Once I really need to step through code, I use The Open-Perl-IDE, a free debugger for windows. One quirk I have noticed is it doesn't seem to like DBD connections. Oddly, I recently got a chance to try out Komodo, and it didn't like scripts that used DBD either. Both the OpenPerl IDE and Komodo would barf with an error in an internal file.

print and printf are rock solid. Primitive, but there's no learning curve to use them, no bugs in them, and they're everywhere I'll ever find myself writing code.

I usually resort to tracing with any means possible... Either the program is going in the wrong direction, or it's going the right way, but carrying around the wrong data. Data::Dumper is usually used at selected points in the trace, and tracing info is added in binary search order.

I hacked Class::Publisher to allow to to say Class::Publisher->add_subscriber('*' => sub { warn "@_" }); and get a trace of events. In my recent project this helps a lot.

I use throaway warns with Data::Dumper, or without, a lot. Data::Dumper usually helps if the objects stringify, which is sometimes the case.

I sometimes use Devel:: modules to help me get more output, or better intersected output.

Someday I'd like to say that I make use of ddd, though. Or maybe Dominus will finish the new debugger... =P

The perl debugger is very poorly documented, but it's quite useful. Unlike ad-hoc trace statements, you don't risk introducing bugs by modifying your code. You also don't have to remember to take *out* all your trace statements again: the code is only modified to fix bugs or add features. You can toss breakpoints in to test branches, examine variables, or change them to see if fixing the data fixes the bug you're encountering. You can quickly examine complex data structures to see if the data you're looking for is in there: or if there's any data at all. You can't go backwards, which is frustrating, but you *can* step through an arbitrary function as it executes, which is almost as good. That means that if you have a function with no side effects, you can run through the code, find the function call that is wrong, and then single step through the function looking for why it's wrong, without re-rerunning the program. Re-running the program can be tedious, if the program runs slowly, or has a long start up time. -- AC

Of course, that's only part of the story, and only for particular purposes... in general, I'm a warn kinda guy, but print is the nearest thing on the list.

------------
:Wq
Not an editor command: Wq
[download]

I love Komodo - but I switched to a Mac and there is nothing for me on the Mac, so back to text editor and the command line. I liked the folding and the debugging of Komodo, as well as completion. I use BBEdit now and it doesn't have all of that. There is a program out now that people are likening to Komodo for the Mac, but I haven't had a chance to use it yet (sorry, don't recall the name of it).

While I use ptkdb for tracing, I also use the indispensible Data::Dumper::Simple⁰. Combining the latter with a global $_DEBUG allows me to do this:

use strict;
use warnings;
#... blah
if ($_DEBUG) {
   require Data::Dumper::Simple;
   Data::Dumper::Simple->import;
}

sub _explain (@_);

# ... some code

$record = $sth->fetchrow_arrayref;
_explain $record;

# ... some code

sub _explain (@_) {
   return undef unless $_DEBUG;
   local $|=1;
   my @call = caller(1);
   print '#- in ',$call[3],' ',Dumper($_),"\n" for (@_);
}
[download]

#- in mySub $record = [
     'aUser',
     'aPassword'
]
[download]

I usually use STDOUT so I can redirect to a log file if I wish, but sometimes I call out to a logger module, too. One of the advantages of this is that I can set $_DEBUG in-code or with a command-line option &c., thereby controlling the verbosity level on a per-run basis.

My habit in any language, going back many years, has been to debug using the equivalent of print() and so I did at first in Perl. I appreciate the convenience of say(); it allows me to concentrate on properly quoting what I wish to say, without hanging , qq{\n} to the end of the statement.

Print-debug statements must be disabled in production. One may comment them out individually but some can be missed. For a time, I felt more secure writing, e.g.:

    say q{$myvar: }, $myvar if $::Debug;
[download]

But that's too much work and leads to other difficulties.

When I learned of it, I enthusastically adopted Smart::Comments, which permits:

    ### $myvar
[download]

... with the same effect as the say() code above; except that disabling is simpler and can also be more flexible. Complex structures are dumped (internally using Data::Dumper) in exactly the same way. (Please see In Defense of Smart::Comments.) The big fat shorcoming is that all smart output goes to STDERR.

So, I forked S::C into Devel::Comments, which permits output to be sent to one's choice of output streams or files. Other features are planned. Needless to say, in future, this will be my first choice.