views:

708

answers:

17

Are there any other ways for debugging Perl apart from Data::Dumper and perl -d?

+11  A: 

Available tools for debugging

There are several tools available in Perl for debugging and similar tasks.


Built-in command line debugger.

perl -d yourcode.pl


Devel::ptkdb

Perl/Tk based graphical debugger by Andrew E. Page.


Regex Coach

This a free tool running both on Linux and Windows written in Lisp. Source code is not available.


Rx: A Regex Debugger for Perl

The Perl Regex debugger and an article about it written by Mark Jason Dominus.


A GUI for the Perl Debugger

Haim Evgi
+ WishPerl - is nice one too
joe
+4  A: 

Some people use print statements in order to see what's going on in sections of a program that aren't doing what they thought the code would do. (I.e., as a way of checking what is actually contained in a variable at a given point of execution.)

That said, the question is pretty vague. Is there something you are trying to do that Data::Dumper and perl -d aren't helping with?

Telemachus
Its not like . just curiosity want to know other way of Perl debugging
joe
I like to use "warn" instead of "print" so it goes to stderr and not stdout. "print STDERR" works too but needs more typing.
laalto
A: 

Writing tests can mostly decrease debugging time, I think.

Alan Haggai Alavi
+5  A: 

My usual range of tools is:

  • print statements and Data::Dumper for simple cases
  • perl -d

That's usually enough. There is ddd; I heard it's quite nice, but never played with it.

For some tasks (which are not really debugging, but close to it) I use Devel::NYTProf.

depesz
Suggestion: s/Data::Dumper/Data::Dump/. It's way more nutritious.
j_random_hacker
+8  A: 

I like Devel::Trace. Basically it gives you an execution dump, showing you the code paths.

On another side, Test Driven Development is all the rage now, so you could also be interested in profiling tools like Devel::NYTProf for highly advanced testing. See this Tim bunce's blog post for an interesting overview.

wazoox
+6  A: 

I use ActiveState Komodo for step-by-step debugging.

Eclipse has a step by step debugger for its EPIC plugin.

Personally I prefer the ActiveState version. It just seems more solid and stable, but it does cost (and work is paying for me). If it was my money then I would use Eclipse and EPIC as these are free.

Xetius
+3  A: 

Test::More for writing basic tests, Hook::LexWrap, Test::MockObject, Test::Deep, Test::MockTime, Test::WWW::Mechanize and many others for advanced tests. Attribute::Signature for checking sub params. Carp::Assert for contract-based programming.

Devel::Ebug::Wx or Devel::ptkdb (and soon better support in Padre) can be used for easier debugging.

Alexandr Ciornii
+11  A: 

There are lots of things out there to help you:

  • Devel::Trace - print every line that executes
  • Carp::REPL - drop into a REPL* when the code throws a warning
  • Devel::ebug - a debugger you can control from Perl code
  • Enbugger - use debugger at runtime regardless of whether your process was started with debugging
Chas. Owens
* REPL = Read, Eval, Print Loop (== interactive interpreter)
j_random_hacker
@j_random_hacker Thanks, I am out of it thanks to YAPC.
Chas. Owens
+4  A: 

Depending on what you're doing, Log::Log4perl provides an easy way to manage the 'print' style of debugging particularly in bigger applications:

  • provides various logging levels (Debug, Info, Error, Warning, Fatal)
  • controlled from config files (easy to have debugging on development box, only errors on production box, for example)
  • configurable by sections of your application (e.g. web app in one log file at one level, cron scripts in another at a different log level)
  • configurable by Class - easy to quieten noisy modules, or add detailed debugging to somewhere deep within an app
plusplus
Most people use Log::Log4perl when Log::Message (a core module) would do.
MkV
+5  A: 

The best debugging aids are small routines, short scopes, limited side effects, and lots of tests. Stop bugs before they hatch.

brian d foy
A: 

Some Other methods

CGI::Dump

Benchmark

Command-line options 

__DATA__ & <DATA> 

$.

__FILE__ & __LINE__ 

warn() & die()
joe
+2  A: 

Use, Devel::SimpleTrace, for the most elegant seemless stateless-debugging.

perl -MDevel::SimpleTrace -we'warn "main"; sub foo{ warn "outer"; sub { warn "inner" } }; foo()->()'

Evan Carroll
+1  A: 

Generally I use

perl -d

for debugging.

YOu can also use Eclipse Perl Integration (EPIC) plug-in for Eclipse It offers a rich debugging environment available and integrated with the EPIC Perl development environment. You can use it and is generally helpful.

PJ
+1  A: 

During development, I like to embed printf statements in strategic places (not too many) which are enabled with a debug flag like this:

printf("h='$h', j='$j', ... (%d)\n", __LINE__) if $debug;

where the debug flag is defined at the top of the script:

my $debug = $ENV{DEBUG} || 0;

Now instead of having to remember to comment out all of the printf lines, I just run the script as follows:

DEBUG=1 ./script.pl

After testing when everything is ready for production, the debug lines can be removed:

cat script.pl | grep -v 'if $debug;'
Kiffin
+2  A: 

If you don't like perl -d then http://search.cpan.org/perldoc?Devel::REPL and Carp::REPL are both nice alternatives.

singingfish
pity Devel::REPL requires the 400 pound Moose (and various MooseX modules), and Carp::REPL depends on Devel::REPL
MkV
And this is a problem because...?
singingfish
+1  A: 

Personally, I'm a big fan of Smart::Comments. Makes tracing dead simple, no need to strip it out again, either.

use Smart::Comments -ENV;
...
sub myroutine {
    my ($self, @args) = @_ ;
    ### args: @args
    ...
}

If Smart_Comments has been set in the environment, the lines commencing with ### are converted to debug output, with Dumper() used automagically. If the environment variable isn't set, the debug stuff is completely inert.

It has heaps of features, and will produce progress bars, warnings, abort conditions as well as plain old debug output.

Appropriate tests are all good, and I'm not dismissing a good TDD development methodology, but when trying to get to the bottom of an existing bug, Smart::Comments is the go.

RET
And it is a source filter, hence fragile.
MkV
A: 

Emacs, hands down.

   emacs my_script.pl
   M-x perldb
   Emacs will prompt you :
   Run perldb (like this): perl my_script.pl
   Hit enter (or add command line switches)

   Now use the debugger as usual.
   Type 'c' to continue executing the code, which will now follow
   your code as you execute through it.

   Emacs is fully integrated with its debuggers and will make debugging perl code nearly trivial.
Felix