Re: I usually debug via...
by gaal (Parson) on Feb 15, 2005 at 07: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.) | [reply] [d/l] [select] |
|
| [reply] |
|
| [reply] |
|
|
|
|
|
|
print and perl -d for me
between these two I get my debugging done
oh, and heavy use of Data::Dumper
| [reply] |
Re: I usually debug via...
by matija (Priest) on Feb 15, 2005 at 08: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. | [reply] [d/l] [select] |
Re: I usually debug via...
by K_M_McMahon (Hermit) on Feb 15, 2005 at 09: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.
-Kevin
my $a='62696c6c77667269656e6440676d61696c2e636f6d';
while ($a=~m/(^.{2})/s)
{print unpack('A',pack('H*',"$1"));$a=~s/^.{2}//s;}
| [reply] [d/l] [select] |
|
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.
| [reply] [d/l] |
|
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.
| [reply] |
|
|
Re: I usually debug via...
by cog (Parson) on Feb 15, 2005 at 12: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) | [reply] |
|
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
| [reply] |
|
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? | [reply] |
|
but what about maintenance programming and debuging the work of mortal (wo)men
| [reply] |
|
Then I guess print combined with Data::Dumper is my tool of choice :-)
| [reply] |
Re: I usually debug via...
by Animator (Hermit) on Feb 15, 2005 at 12:49 UTC
|
I debug with warn... but it isn't an option in the list... :( | [reply] |
|
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.
| [reply] [d/l] [select] |
|
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.
| [reply] [d/l] [select] |
|
|
|
|
|
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;
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";
}
| [reply] [d/l] [select] |
|
Yeah, I use warn too... print is kinda useless in a mod_perl environment.
| [reply] |
Re: I usually debug via...
by jmcnamara (Monsignor) on Feb 15, 2005 at 10:11 UTC
|
| [reply] |
|
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)
| [reply] |
|
| [reply] |
|
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.
| [reply] |
|
|
|
|
| [reply] |
|
Re: I usually debug via...
by tbone1 (Monsignor) on Feb 15, 2005 at 12: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
| [reply] |
Re: I usually debug via...
by Courage (Parson) on Feb 15, 2005 at 09:17 UTC
|
I answered ptkdb, and also I use its brother tcltkdb from Tcl::Tk.
Best regards,
Courage, the Cowardly Dog
| [reply] |
Re: I usually debug via...
by gopalr (Priest) on Feb 15, 2005 at 12:24 UTC
|
| [reply] |
Re: I usually debug via...
by perlsen (Chaplain) on Feb 15, 2005 at 12: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?.
Thanks
| [reply] |
Re: I usually debug via...
by gube (Parson) on Feb 15, 2005 at 11:52 UTC
|
I always debug using print statement
I have to see the values for all the variables, i often use PERL IDE
Regards,
Gubendran.L
| [reply] |
Re: I usually debug via...
by Dietz (Curate) on Feb 15, 2005 at 13: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. | [reply] |
Re: I usually debug via...
by Steve_p (Priest) on Feb 15, 2005 at 21:16 UTC
|
perlbug
I assume all bugs I find are actually bugs in Perl, so everything that goes wrong goes there first.
</removesTongueFromCheek> | [reply] |
Re: I usually debug via...
by Popcorn Dave (Abbot) on Feb 16, 2005 at 00: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.
| [reply] |
Re: I usually debug via...
by Aristotle (Chancellor) on Feb 19, 2005 at 05:15 UTC
|
print/warn and Devel::Trace. Very useful module, you want it in your toolbox.
Makeshifts last the longest.
| [reply] |
|
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. |
| [reply] |
Re: I usually debug via...
by zakzebrowski (Curate) on Feb 15, 2005 at 16: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...
| [reply] |
Re: I usually debug via...
by tilly (Archbishop) on Mar 07, 2005 at 05:48 UTC
|
I'm amazed that Are debuggers good? has not been mentioned in this discussion yet. Let me fix that. :-) | [reply] |
Re: I usually debug via...
by InfiniteLoop (Hermit) on Feb 17, 2005 at 04:55 UTC
|
| [reply] |
Re: I usually debug via...
by sh1tn (Priest) on Feb 15, 2005 at 13:20 UTC
|
Debug?!
I am not java(script)? coder.
I am Perl programmer.
| [reply] |
|
| [reply] |
|
| [reply] |
Re: I usually debug via...
by ChuckularOne (Prior) on Feb 15, 2005 at 16:11 UTC
|
I usually use "print" but, I voted SoPW because nobody who really does, will admit to it :-) | [reply] |
Re: I usually debug via...
by macPerl (Beadle) on Feb 16, 2005 at 13:12 UTC
|
| [reply] |
Re: I usually debug via...
by blue_cowdawg (Monsignor) on Mar 13, 2005 at 17: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.
| [reply] |
Re: I usually debug via...
by talexb (Chancellor) on Feb 22, 2005 at 19: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
| [reply] [d/l] |
Re: I usually debug via...
by Mr. Lee (Scribe) on Feb 22, 2005 at 21:01 UTC
|
What bugs?
lol
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
| [reply] |
Re: I usually debug via...
by mr_jpeg (Beadle) on Feb 17, 2005 at 08: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. | [reply] |
Re: I usually debug via...
by nothingmuch (Priest) on Feb 20, 2005 at 08: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
| [reply] [d/l] |
|
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
| [reply] |
Re: I usually debug via...
by wolfger (Deacon) on Feb 22, 2005 at 19: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)))'
| [reply] [d/l] |
Re: I usually debug via...
by Mago (Parson) on Feb 16, 2005 at 12:30 UTC
|
print and warn !
Mago
mago@rio.pm.org
| [reply] |
Re: I usually debug via...
by bheckel (Beadle) on Feb 18, 2005 at 21: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.
| [reply] |
Re: I usually debug via...
by etcshadow (Priest) on Feb 15, 2005 at 21: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
| [reply] [d/l] [select] |
Re: I usually debug via...
by Scarborough (Hermit) on Feb 16, 2005 at 16: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. | [reply] |
|
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).
| [reply] |
Re: I usually debug via...
by TedPride (Priest) on Feb 28, 2005 at 06: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. | [reply] |
Re: I usually debug via...
by Takophiliac (Novice) on Feb 16, 2005 at 19:10 UTC
|
| [reply] |
Re: I usually debug via...
by legato (Monk) on Mar 03, 2005 at 00: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
| [reply] [d/l] [select] |
Re: I usually debug via...
by marinersk (Priest) on Mar 01, 2005 at 20:35 UTC
|
I wrote a debug.pm 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".
| [reply] |
Re: I usually debug via...
by arhuman (Vicar) on Mar 04, 2005 at 15:02 UTC
|
| [reply] |
Re: I usually debug via...
by Xiong (Hermit) on Aug 15, 2010 at 10: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.
| [reply] [d/l] [select] |