Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

When my script doesn't work, I ...

by cavac (Deacon)
on Oct 01, 2012 at 13:15 UTC ( #996654=poll: print w/replies, xml ) Need Help??

vote on When my script doesn't work, I ...

Try to debug it
[bar] 220/24%
Go for a coffee break
[bar] 74/8%
Ask in SoPW for help
[bar] 3/0%
Demand in SoPW that someone fix it! Now!!!
[bar] 12/1%
Repeatedly bash my head against the wall
[bar] 25/3%
Repeatedly bash someone else's head against the wall
[bar] 36/4%
Ignore the problem in the hope nobody will notice
[bar] 12/1%
Declare that it's a feature, not a bug
[bar] 24/3%
Write an RFC to make my "solution" an internet standard
[bar] 15/2%
Run it again "just in case"
[bar] 96/11%
Wait until the next morning, hoping "reverse code rot" fixes it
[bar] 33/4%
Change all characters to semi-colons
[bar] 30/3%
[bar] 319/35%
899 total votes
Replies are listed 'Best First'.
Re: When my script doesn't work, I ...
by talexb (Canon) on Oct 01, 2012 at 14: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

      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."
Re: When my script doesn't work, I ...
by Ratazong (Monsignor) on Oct 01, 2012 at 20: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.


    (*) 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...


Re: When my script doesn't work, I ...
by eyepopslikeamosquito (Chancellor) on Oct 01, 2012 at 23: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."

Re: When my script doesn't work, I ...
by jdporter (Canon) on Oct 01, 2012 at 15:28 UTC

    Rewrite the entire thing from scratch.

Re: When my script doesn't work, I ...
by thomas895 (Chaplain) on Oct 01, 2012 at 16:58 UTC

    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
    It's a never-ending cycle :-/

    confess( "I offer no guarantees on my code." );
Re: When my script doesn't work, I ...
by tobyink (Abbot) on Oct 01, 2012 at 19: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'
      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

Re: When my script doesn't work, I ...
by vitoco (Friar) on Oct 01, 2012 at 13:41 UTC

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

Re: When my script doesn't work, I ...
by SuicideJunkie (Vicar) on Oct 01, 2012 at 13:47 UTC
    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.

Re: When my script doesn't work, I ...
by Anonymous Monk on Oct 01, 2012 at 13:47 UTC
Re: When my script doesn't work, I ...
by mertserger (Curate) on Oct 02, 2012 at 09: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.

      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!!!"
Re: When my script doesn't work, I ...
by ChuckularOne (Parson) on Oct 01, 2012 at 18: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

Re: When my script doesn't work, I ...
by jmlynesjr (Hermit) on Oct 01, 2012 at 19:56 UTC

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

Re: When my script doesn't work, I ...
by Voronich (Hermit) on Oct 03, 2012 at 20: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.

Re: When my script doesn't work, I ...
by ELISHEVA (Prior) on Oct 04, 2012 at 17:24 UTC
    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.

Re: When my script doesn't work, I ...
by Anique (Acolyte) on Oct 02, 2012 at 10: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...

      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.

Re: When my script doesn't work, I ...
by FloydATC (Chaplain) on Oct 02, 2012 at 18:31 UTC
    Other: Add more logging


    Try to debug it.

    -- Time flies when you don't know what you're doing
Re: When my script doesn't work, I ...
by polypompholyx (Chaplain) on Oct 02, 2012 at 12:39 UTC
    use Data::Dumper; die Dumper $suspect_variable;
Re: When my script doesn't work, I ...
by chacham (Parson) on Oct 04, 2012 at 04: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.

Re: When my script doesn't work, I ...
by gok8000 (Scribe) on Oct 04, 2012 at 14:45 UTC
    I Google for the solution, for example sorting strings in Perl. (And I'm almost always redirected here...)
Re: When my script doesn't work, I ...
by xiaoyafeng (Chaplain) on Oct 08, 2012 at 08: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

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

Re: When my script doesn't work, I ...
by raybies (Chaplain) on Oct 15, 2012 at 16:47 UTC

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


Re: When my script doesn't work, I ...
by rpnoble419 (Pilgrim) on Oct 01, 2012 at 23: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.
Re: When my script doesn't work, I ...
by GeneralElektrix (Acolyte) on Oct 03, 2012 at 19:46 UTC
    Debugging's always better after a Coffee break!
Re: When my script doesn't work, I ...
by cord-bin (Friar) on Oct 05, 2012 at 09: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. ;)
Re: When my script doesn't work, I ...
by blue_cowdawg (Monsignor) on Oct 17, 2012 at 18:51 UTC

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

      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!!!"
Re: When my script doesn't work, I ...
by stonecolddevin (Vicar) on Oct 17, 2012 at 21: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

View List Of Past Polls

Log In?

What's my password?
Create A New User
[chacham]: with google, you kinda just gotta do what it recomends.
[chacham]: finally fixed it. just changing it in all my projects... then maybe to finally fix the junit error i've been ignoring

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2017-03-29 08:08 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (344 votes). Check out past polls.