Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

I usually debug via...

by rinceWind (Monsignor)
on Feb 15, 2005 at 02:09 UTC ( #431048=poll: print w/replies, xml ) Need Help??

Vote on this poll

perl -d
[bar] 164/17%
[bar] 41/4%
[bar] 31/3%
gdb / dbx
[bar] 8/1%
[bar] 519/55%
[bar] 4/0%
[bar] 9/1%
What bugs?
[bar] 165/18%
941 total votes
Replies are listed 'Best First'.
Re: I usually debug via...
by gaal (Parson) on Feb 15, 2005 at 02:34 UTC
    I'm a printer.

    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;

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

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


        So close to a haiku....

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

        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
Re: I usually debug via...
by matija (Priest) on Feb 15, 2005 at 03:47 UTC
    I often use print. But I also often (perhaps even more often, step through my code with perl -d even when I'm not chasing a specific bug - it's just that if the code is in anyway tricky, I like stepping through it, examining variables at my leisure, and see if the code does what I thought it would.

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

Re: I usually debug via...
by K_M_McMahon (Hermit) on Feb 15, 2005 at 04:32 UTC
    I start with  -w and use strict so I generally catch errors as I go. I use a lot of print statements as I am creating a script to make sure everything is where I expect it to be, and if I am stuck chasing something specific, good old perl -d usually does the trick.

    my $a='62696c6c77667269656e6440676d61696c2e636f6d'; while ($a=~m/(^.{2})/s) {print unpack('A',pack('H*',"$1"));$a=~s/^.{2}//s;}
      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.
Re: I usually debug via...
by cog (Parson) on Feb 15, 2005 at 07:15 UTC
    I usually don't debug, because I write tests beforehand, and code in small units. Hence, it's very rare for me to have bugs.

    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 )
      --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 :-)
Re: I usually debug via...
by Animator (Hermit) on Feb 15, 2005 at 07:49 UTC
    I debug with warn... but it isn't an option in the list... :(
      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 ''; my $foo = { 'abc', 123, 'def', 456 }; gs::do_dumper( 'foo423:', $foo ) # 423 a silly, easy-to-find label if 0;

        and a helper file/libary named '' might contain:

        package gs; use strict; use Data::Dumper; sub do_dumper { my ( $label, $variable ) = @_; my $msg = Dumper( $variable ); warn "$label:\n$msg\n"; }
      Yeah, I use warn too... print is kinda useless in a mod_perl environment.
Re: I usually debug via...
by jmcnamara (Monsignor) on Feb 15, 2005 at 05:11 UTC

    I use perldb via emacs.

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


      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.


        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.

Re: I usually debug via...
by tbone1 (Monsignor) on Feb 15, 2005 at 07:42 UTC
    I think 'print' is underrated as a debugging tool, particularly when you don't know what to look for. You can at least start zeroing in on the line where things fall down, go boom.

    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.

    tbone1, YAPS (Yet Another Perl Schlub)
    And remember, if he succeeds, so what.
    - Chick McGee

Re: I usually debug via...
by Courage (Parson) on Feb 15, 2005 at 04:17 UTC
    I answered ptkdb, and also I use its brother tcltkdb from Tcl::Tk.

    Best regards,
    Courage, the Cowardly Dog

Re: I usually debug via...
by gopalr (Priest) on Feb 15, 2005 at 07:24 UTC

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

Re: I usually debug via...
by perlsen (Chaplain) on Feb 15, 2005 at 07:38 UTC

    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?.


Re: I usually debug via...
by gube (Parson) on Feb 15, 2005 at 06:52 UTC

    I always debug using print statement

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


Re: I usually debug via...
by Dietz (Curate) on Feb 15, 2005 at 08:41 UTC
    For code in development I usually use print.

    For code which is already in production I usually use perl -d, so I can make changes during runtime without altering the original code.

    I voted for print, since this is what I use more often.
Re: I usually debug via...
by Steve_p (Priest) on Feb 15, 2005 at 16:16 UTC


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


Re: I usually debug via...
by Popcorn Dave (Abbot) on Feb 15, 2005 at 19:32 UTC
    Personally I'd be lost without ptkdb, but I'd love to see a debugger that would work with an Perl/Tk app so you could do realtime debugging there.

    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. :)

    Useless trivia: In the 2004 Las Vegas phone book there are approximately 28 pages of ads for massage, but almost 200 for lawyers.
Re: I usually debug via...
by Aristotle (Chancellor) on Feb 19, 2005 at 00:15 UTC

    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.

Re: I usually debug via...
by zakzebrowski (Curate) on Feb 15, 2005 at 11:28 UTC
    I know I'm not a roll model for debugging, but I generally just run the application on a development server, then when it breaks, I use print "Hi Mom"; or Data::Dumper to fix the problem... I also then look into the database that I was using to see if I altered the data based on the improper run...

    Zak - the office
Re: I usually debug via...
by tilly (Archbishop) on Mar 07, 2005 at 00:48 UTC
    I'm amazed that Are debuggers good? has not been mentioned in this discussion yet. Let me fix that. :-)
Re: I usually debug via...
by InfiniteLoop (Hermit) on Feb 16, 2005 at 23:55 UTC
    I generally use print to debug my code. I found this style very helpful:

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

Re: I usually debug via...
by sh1tn (Priest) on Feb 15, 2005 at 08:20 UTC
    I am not java(script)? coder.
    I am Perl programmer.

      Beware false hubris.

Re: I usually debug via...
by ChuckularOne (Prior) on Feb 15, 2005 at 11:11 UTC
    I usually use "print" but, I voted SoPW because nobody who really does, will admit to it :-)
Re: I usually debug via...
by macPerl (Beadle) on Feb 16, 2005 at 08:12 UTC

    Code: print

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

    SQL I use trace

Re: I usually debug via...
by blue_cowdawg (Monsignor) on Mar 13, 2005 at 12:53 UTC

    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.

Re: I usually debug via...
by Mr. Lee (Scribe) on Feb 22, 2005 at 16:01 UTC
    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

Re: I usually debug via...
by mr_jpeg (Beadle) on Feb 17, 2005 at 03:02 UTC
    the venerable print for anything up to 300 lines or so. One window taking up most of the screen vim'ing the script, and one smaller window where I run the script and watch the output. It's sweet.

    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.

Re: I usually debug via...
by talexb (Chancellor) on Feb 22, 2005 at 14:22 UTC

    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.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: I usually debug via...
by wolfger (Deacon) on Feb 22, 2005 at 14:31 UTC

    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...

    Linux, sci-fi, and Nat Torkington, all at Penguicon 3.0
    perl -e 'print(map(chr,(0x4a,0x41,0x50,0x48,0xa)))'
Re: I usually debug via...
by Mago (Parson) on Feb 16, 2005 at 07:30 UTC
    print and warn !


Re: I usually debug via...
by bheckel (Beadle) on Feb 18, 2005 at 16:00 UTC
    I am completely committed to the vi/command line IDE with the sole exception being non-trivial debugging. For that ptkdb is incredibly useful, here are a few examples:

    I can view the state of several variables simultaneously.

    I can avoid print statement clutter by mouse hovering over variables, etc.

    I can watch a hash of anonymous arrays of anonymous hashes get populated one step at a time

    It is a very valuable tool for the toolbox.
Re: I usually debug via...
by nothingmuch (Priest) on Feb 20, 2005 at 03:39 UTC
    I think the perl debugger is not that fun.

    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

    zz zZ Z Z #!perl
      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
Re: I usually debug via...
by etcshadow (Priest) on Feb 15, 2005 at 16:28 UTC
    I get a lot of use out of sqlplus (or various other sql clients) for debugging. That's one of the great parts of writing database applications: the database is a debugger, you can examine and manipulate the state of your program as it runs.

    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
Re: I usually debug via...
by Scarborough (Hermit) on Feb 16, 2005 at 11:29 UTC
    I seem to be one of the few who use Komodo. Started out using print then managed to master perl -d, but Komodo just seems to work for me.
    Even if it does crash about 5 times a day.
      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).
Re: I usually debug via...
by TedPride (Priest) on Feb 28, 2005 at 01:36 UTC
    I use print to debug. You don't need anything more advanced than this if you are smart and build your program from small, easily tested parts that can be added to one another.
Re: I usually debug via...
by Takophiliac (Novice) on Feb 16, 2005 at 14:10 UTC
    I use open PerlIDE. Mostly because I'm a windows scripter and don't want to pay for anything higher. That and i'm not aware of anything easier to use that cost as much or less.
    I am Takophiliac. The evil souls remind me and in the darkness find me.
Re: I usually debug via...
by marinersk (Priest) on Mar 01, 2005 at 15:35 UTC
    I wrote a module which allows me to embed debugging statements in my code but only see them if I asked for them via -debug on the command line. Relative to the options on the poll, this translates to more or less to "print".
Re: I usually debug via...
by legato (Monk) on Mar 02, 2005 at 19:04 UTC

    While I use ptkdb for tracing, I also use the indispensible Data::Dumper::Simple0. 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 (@_); }
    This results in:
    #- in mySub $record = [ 'aUser', 'aPassword' ]

    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.

    0: I use this instead of Data::Dumper simply because it automagically prints the actual name of the variable instead of $VAR1 and the like. It's possible to do that with the Data::Dumper module, too, but the ::Simple version does it anyhow, so why reinvent that wheel?

    Anima Legato
    .oO all things connect through the motion of the mind

Re: I usually debug via...
by arhuman (Vicar) on Mar 04, 2005 at 10:02 UTC
    I sometimes use Devel::StealthDebug but I may be biased ;-)

    "Only Bad Coders Code Badly In Perl" (OBC2BIP)
Re: I usually debug via...
by Xiong (Hermit) on Aug 15, 2010 at 06:43 UTC

    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;

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

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

    ### $myvar

    ... 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.

    We don't need the conch anymore. We know who ought to say things.... It's time some people knew they've got to keep quiet and leave deciding things to the rest of us.

View List Of Past Polls

Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (6)
As of 2023-12-06 08:28 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (30 votes). Check out past polls.