Re: When my script doesn't work, I ...
by talexb (Chancellor) on Oct 01, 2012 at 10:26 UTC
|
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.
Alex / talexb / Toronto
"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds
| [reply] [d/l] |
|
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.
| [reply] |
|
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. :)
| [reply] |
|
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."
| [reply] |
|
Re: When my script doesn't work, I ...
by Ratazong (Monsignor) on Oct 01, 2012 at 16:20 UTC
|
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.
Rata
(*) 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! :-)
| [reply] |
|
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
| [reply] |
Re: When my script doesn't work, I ...
by eyepopslikeamosquito (Archbishop) on Oct 01, 2012 at 19:53 UTC
|
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."
| [reply] |
Re: When my script doesn't work, I ...
by tobyink (Canon) on Oct 01, 2012 at 15:58 UTC
|
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.
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
| [reply] |
|
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!
| [reply] |
|
| [reply] |
|
|
|
|
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
| [reply] |
Re: When my script doesn't work, I ...
by jdporter (Chancellor) on Oct 01, 2012 at 11:28 UTC
|
| [reply] |
Re: When my script doesn't work, I ...
by thomas895 (Deacon) on Oct 01, 2012 at 12:58 UTC
|
- First I try to run it again, of course
- Put warn and die after every other line
- Take a break to do something less frustrating
- Consider how my problem would be done in Java
- Decide against Java and dejectedly scrolling through the code I wrote
- Abandon the project for a while
- Rewrite everything
It's a never-ending cycle :-/
~ Thomas~
confess( "I offer no guarantees on my code." );
| [reply] [d/l] [select] |
Re: When my script doesn't work, I ...
by vitoco (Friar) on Oct 01, 2012 at 09:41 UTC
|
warn everything, everywhere. When the bug is removed, all warnings are commented out, just in case it appears again!
| [reply] [d/l] |
Re: When my script doesn't work, I ...
by SuicideJunkie (Vicar) on Oct 01, 2012 at 09:47 UTC
|
- Save the extra code written while it was compiling & running, and run it again.
- Fix any obvious typos pointed out by the compile phase, run it again.
- Goto (2) until the code segment currently being worked on is done.
- 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.
| [reply] |
Re: When my script doesn't work, I ...
by mertserger (Curate) on Oct 02, 2012 at 05:20 UTC
|
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.
| [reply] |
|
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.
| [reply] |
|
| [reply] |
Re: When my script doesn't work, I ...
by Anonymous Monk on Oct 01, 2012 at 09:47 UTC
|
| [reply] |
Re: When my script doesn't work, I ...
by jmlynesjr (Deacon) on Oct 01, 2012 at 15:56 UTC
|
| [reply] |
Re: When my script doesn't work, I ...
by ChuckularOne (Prior) on Oct 01, 2012 at 14:28 UTC
|
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
| [reply] |
Re: When my script doesn't work, I ...
by Voronich (Hermit) on Oct 03, 2012 at 16:22 UTC
|
...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.
| [reply] |
Re: When my script doesn't work, I ...
by ELISHEVA (Prior) on Oct 04, 2012 at 13:24 UTC
|
- make sure its really a bug (agreed Vornitch) - I even have a name for this: "expectation errors"
- 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).
- 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.
- 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.
- 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.
| [reply] [d/l] |
|
| [reply] |
Re: When my script doesn't work, I ...
by Anique (Acolyte) on Oct 02, 2012 at 06:20 UTC
|
Debug until I drop
(includes writing say 'Checkpoint 1'; every other line - increasing the number of course)
Go home about five minutes before the office closes
Get back to work next morning (after dreaming about bugs)
Look at code for a few minutes
Find the obvious bug (often assignment instead of comparison, or using the wrong variable name)
Smack myself
Do happy dance that everything works now
Further development
Create bug
restart cycle...
| [reply] [d/l] |
|
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
| [reply] |
|
| [reply] |
Re: When my script doesn't work, I ...
by FloydATC (Deacon) on Oct 02, 2012 at 14:31 UTC
|
| [reply] |
Re: When my script doesn't work, I ...
by polypompholyx (Chaplain) on Oct 02, 2012 at 08:39 UTC
|
use Data::Dumper; die Dumper $suspect_variable; | [reply] [d/l] |
Re: When my script doesn't work, I ...
by chacham (Prior) on Oct 04, 2012 at 00:56 UTC
|
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.
| [reply] |
Re: When my script doesn't work, I ...
by raybies (Chaplain) on Oct 15, 2012 at 12:47 UTC
|
| [reply] |
Re: When my script doesn't work, I ...
by blue_cowdawg (Monsignor) on Oct 17, 2012 at 14:51 UTC
|
There's a process for that:
- Cuss like a sailor asking the Universe why the <BLEEP!> this thing ain't working??????
- Smack monitor
- Go for more coffee
- Cuss some more
- rerun the code and hope the problem isn't still there.
- cuss more when the problem remanifests itself.
- try blaming the input data.
- go for more coffee
- re-run code
- Turn on script's built in debug logging
- stare at terminal
- Go to lunch
- read debug output
- Add more debug logging in strategic locations
- Get Diet Mountain Dew from vending machine
- rerun script
- found bug, fix.
- Go home
And the next day we start all over again!
Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
| [reply] |
|
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!!!"
| [reply] |
Re: When my script doesn't work, I ...
by rpnoble419 (Pilgrim) on Oct 01, 2012 at 19:18 UTC
|
My Perl code never has bug until some twit calls me for the x+n time over some stupid stuff they can't have like "no my script will not make you look 10 years younger and 20 Lbs. thinner." The bug is then introduced as I ball up my hands to pound the table and I then type random keys into my program. | [reply] |
Re: When my script doesn't work, I ...
by gok8000 (Scribe) on Oct 04, 2012 at 10:45 UTC
|
I Google for the solution, for example sorting strings in Perl. (And I'm almost always redirected here...) | [reply] |
|
| [reply] |
Re: When my script doesn't work, I ...
by xiaoyafeng (Deacon) on Oct 08, 2012 at 04:37 UTC
|
rewrite it in perl6! XDDDDDD
I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction
| [reply] |
|
| [reply] |
Re: When my script doesn't work, I ...
by GeneralElektrix (Acolyte) on Oct 03, 2012 at 15:46 UTC
|
Debugging's always better after a Coffee break! | [reply] |
Re: When my script doesn't work, I ...
by cord-bin (Friar) on Oct 05, 2012 at 05:57 UTC
|
Most of the solutions I'm looking for the code I have to debug is already in here when I Google for the solution. ;) | [reply] |
Re: When my script doesn't work, I ...
by stonecolddevin (Parson) on Oct 17, 2012 at 17:49 UTC
|
Repeatedly bash someone else's head against the wall
Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past
| [reply] |