I'm always surprised when I hear someone's never used the Perl debugger. But then again, I wrote assembler on and off for the first eight years after I graduated from Waterloo, and the only reasonable way to debug assembler is with a debugger, single-stepping through to confirm what's happening is what you meant to happen. (First was 6809 and 68000 assembler, and after that, x86 assembler for DOS on the IBM PC, for TSRs and my own function library. Good times.)

As a bonus, perl -de 1 lets you try out *any* Perl code you want. You can even pull in modules you want to try out and write some code on the fly. But that's the way I work -- not everyone develops the same way.

I'm always surprised when I hear someone's used the Perl debugger. First of all, please don't mention debugger in assembler context. Because, well, in those days debugger tool was 'a-must-have tool'. Nowadays I think it is not.

In general case, you need a debugger to see a) control flow and b) variable state. In modern reality when it is simplier to edit script file and add some 'print' statements to see both (a) and (b) I see no need in debugger at all. Again: it is true only for high-level programming, for language interpretators, and possibly false for C language, for example. Especially for gcc -O2 =)

More deeply, I think it is a best practice to make -- as many as it is possible -- of your functions to be side-effect free and test them using QuickCheck (haskell), PropEr (Erlang) and mix it up with unit testing, Test::More at least. And again, the state of variable data you can always print out turning on some 'DEBUG' macro or alike.

Please nota bene -- I have no intention to offend you. And I, for sure, can be wrong.

I'm always surprised when I hear someone's never used the Perl debugger.

It seems the list of someone's (who dislike debuggers) includes: Larry Wall, merlyn, and Linus Torvalds. :)

Don't forget Kernighan and Pike... Looking for their quote on the topic, I came across this page, which immediately follows their quote by also adding Bob Martin to the list, with Bob having commented that "Using a debugger is a code smell."

Well - a non-working script is normal for me. In Perl I'm used to write just a couple of lines, run them, debug them and then continue. (*) Actually I'm much more concerned if a script runs faultless on the first try. Then I have the really bad feeling that I have overlooked something and something went terribly wrong.

(*) a couple of years ago I was developing in a huge telecommunication-environment using CHILL. There we had linkage-times of 2-3 weeks! You really had to plan what (and how) to do before submitting your code. And of course you didn't want to be the reason if a linkage failed ... the "try out what happens"-approach I use in Perl is so much nicer! :-)

Back in the 70s, I supported a utility power control system of about 100,000 lines of assembler code(Lockheed Electronics LEC-16). The code couldn't be assembled and linked on-site, so we got one shot per year on a cross-complier and linker at the vender's home office. The rest of the year, all changes were made via hand assembled patches, some 1000s of lines long. The good old days...

James

From Conway's Ten Essential Development Practices:

9. Add New Test Cases Before you Start Debugging

"Don't try to fix the problem straight away, though. Instead, immediately add those tests to your test suite. The point is: if the original test suite didn't report this bug, then that test suite was broken. It simply didn't do its job (finding bugs) adequately. Fix the test suite first by adding tests that cause it to fail. Once the test suite is detecting the problem correctly, then you'll be able to tell when you've correctly fixed the actual bug, because the tests will once again fall silent ... The more thoroughly you test the bug, the more completely you will fix it."

Rewrite the entire thing from scratch.

Waiting until the next morning usually does it. If reverse code rot doesn't fix things, then seeing things with a fresh mind usually does.

Ya, last night I was banging my head against the wall on a web app and then this morning in the shower the answer was so obvious. I ran to my computer, still wet and nekid to fix it. What a great way to start the day!

So you tried two of the listed code-fixing techniques!

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

I immediately recognized the process you described as my own! Thank you for the validation.

Craig Richards, film & tv producer/writer/director/web entrepreneur
creator of popular web apps AdminPro, BigSender, Envirolyzer, etc.
Craig Richards LLC
"What now seems inevitable was once thought impossible" – Craig Richards

1. First I try to run it again, of course
2. Put warn and die after every other line
3. Take a break to do something less frustrating
4. Consider how my problem would be done in Java
5. Decide against Java and dejectedly scrolling through the code I wrote
6. Abandon the project for a while
7. Rewrite everything

warn everything, everywhere. When the bug is removed, all warnings are commented out, just in case it appears again!

1. Save the extra code written while it was compiling & running, and run it again.
2. Fix any obvious typos pointed out by the compile phase, run it again.
3. Goto (2) until the code segment currently being worked on is done.
4. Work on problem from (1)

Most of the time the problem is that a function hasn't been written yet, but if its a real bug, then dumper + code folding text editor is the way to go.

As I think I've posted before, when I get to the stage of posting a Perl problem in SoPW I often find that writing the question out triggers a thought which leads to the solution.

So there are a host of potential postings I was about to make but didn't.

This sounds like the problem-solving-strategy I know as teddy-bear-method or rubber-duck-method: by trying to explain a problem (or a bug) clearly, the fault becomes obvious. It works extremely well.

In my case, it's a plush, blue elephant i got from a PostgreSQL stand at Chemnitzer Linuxtage ;-)

"I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"

Go for a coffee break is closest. If I have time I shelve it until the next day and then step through it.

If that doesn't do it, I then try to debug, followed by an extensive search of the archives.

THEN, and only then, will I post in SoPW

Love the question and selection of responses. Hard to pick just one. Sore foreheads love company!

...check to make sure my script REALLY doesn't work.

Never ceases to amaze me how many bugs are entirely cases of not seeing what I think I'm seeing.

PS: I contend the question should be phrased "the first thing I do is..." because I regularly go through most of those steps eventually.

1. make sure its really a bug (agreed Vornitch) - I even have a name for this: "expectation errors"
2. sprinkle printf STDERR liberally around the suspected problem spot. In my own code, I only use STDERR for debugging so it makes it very easy for me to find my debugging statements and comment them out. For other peoples code, I sometimes add #DEBUG before or at the end of a line so I can find all of my debugging statements easily (I tend to forget where I put them).
3. for wierd compile time bugs, I use ___END__. Perl sometimes notices a problem loooong after the actual bad syntax, so I put __END__ at a place where the file compiles without a problem. Then I move it downward in the file until Perl starts complaining. The true location of the bad syntax is somewhere near that point.
4. look for stray key strokes -- sometimes if the Alt key gets stuck alt-fs (file-save) turns into "fs" in some odd place in the current document. I've seen some REALLY wierd bugs suddenly appear that way.
5. write a test suite to either (a) check to see which values cause problems (b) to pummel subroutine calls with data and verify they are working correctly

For serious debugging problems the test suite is really the way to go.

The only time I've ever used a debugger was when I had to solve problems at the C level of Perl. But often even that isn't necessary because there are Perl routines that will dump out the guts of the C data structure. So even internals can often be tested using good old Test::More and a few print STDERR statements.

In C/C++ you DO sometimes need a debugger because simply putting in a print statement can end up changing where data gets put and make a memory error go away. Perl doesn't have the same issues though.

The "__END__" point becomes hopeless when it appears before definitions of functions being used before (__END__). At this point, instead, a die is introduced.

You should use Devel::Trace. That would save you a lot of adding checkpoints :)

FWIW, I also use the invaluable Devel::TraceUse to find out why a script works flawless on machine A where it fails on machine B and quite often find out that it isn't my code that fails, but a bad/old module that is not updated on machine B.


Enjoy, Have FUN! H.Merijn

Thanks for the tip! I'll look into that.

then

Try to debug it.

I chose other. Although some of the other choices are good from time to time, the best solution when it isn't "working" is to see what it actually is doing

Comparing what it should be doing with what it is doing usually solves the problem. Though it often has the delightful side-effect of finding a better way to do it.

AMEN!

... quoth the quintuple-chinned xiaoyafeng. lolololol.

More often than not I just put in print statements... and with structs... print Dumper

--Ray

There's a process for that:

1. Cuss like a sailor asking the Universe why the <BLEEP!> this thing ain't working??????
2. Smack monitor
3. Go for more coffee
4. Cuss some more
5. rerun the code and hope the problem isn't still there.
6. cuss more when the problem remanifests itself.
7. try blaming the input data.
8. go for more coffee
9. re-run code
10. Turn on script's built in debug logging
11. stare at terminal
12. Go to lunch
13. read debug output
14. Add more debug logging in strategic locations
15. Get Diet Mountain Dew from vending machine
16. rerun script
17. found bug, fix.
18. Go home

Sound familiar.

Although lately, working with big databases and data files, more often enough the story ends more like "realize that the script does exactly the right thing, but $OTHERSCRIPT supplied broken data. (Junk in/Junk out principle)".

"I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"