Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^2: Using the perl debugger to look at a renaming files function

by Aldebaran (Curate)
on Feb 06, 2021 at 01:02 UTC ( [id://11127961]=note: print w/replies, xml ) Need Help??


in reply to Re: Using the perl debugger to look at a renaming files function (on Debuggers References)
in thread Using the perl debugger to look at a renaming files function

Linus Torvalds : I do not condone single-stepping through code to find the bug ... Without a debugger you have to look at the level above sources. At the meaning of things. You have to understand what the program does. Not just that particular line.

I find myself wanting to retort, but that's not the right spirit. My claim rather is that this fulfills Torvalds' criterion:

$ perl -d 1.debug.11.pl Loading DB routines from perl5db.pl version 1.55 Editor support available. Enter h or 'h h' for help, or 'man perldebug' for more help. main::(1.debug.11.pl:12): my $ts = "template_stuff"; DB<1> c + title is 1.debug.1 path1 is /home/hogan/6.scripts/1.debug.1 abs is /home/hogan/6.scripts/1.debug.1/1.debug.11.pl debug1::make_initial_captions(template_stuff/debug1.pm:42): 42: my $iter = $image_path ->iterator; DB<1> c + /home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image3.png Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179): 1179: my $next; DB<1> c + /home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image4.png Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179): 1179: my $next; DB<1> c + /home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image6.png Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179): 1179: my $next; DB<1> c + /home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image1.png Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179): 1179: my $next; DB<1> c + /home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image5.png Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179): 1179: my $next; DB<1> c + /home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image0.png Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179): 1179: my $next; DB<1> c + /home/hogan/6.scripts/1.debug.1/template_stuff/aimages/image2.png Path::Tiny::CODE(0x55823b1ce7d8)(/usr/share/perl5/Path/Tiny.pm:1179): 1179: my $next; DB<1> c + return2 is nothing yet ini path is /home/hogan/Documents/html_template_data/6.values.ini ... return is 1.debug.15.html http://www.merrillpjensen.com/perlmonks/1.debug.15.html Debugged program terminated. Use q to quit or R to restart, use o inhibit_exit to avoid stopping after program termination, h q, h R or h o to get additional info. DB<1> q + $

All of the people you quote are elite professional programmers as opposed to the intermediate that I am, who makes useful software for his own communications, holding it all together with bubble-gum and tie-wire. I really like the price, too. Getting output adds to an already happy day....

  • Comment on Re^2: Using the perl debugger to look at a renaming files function
  • Download Code

Replies are listed 'Best First'.
Re^3: Using the perl debugger to look at a renaming files function
by eyepopslikeamosquito (Archbishop) on Feb 06, 2021 at 05:22 UTC

    Though I've never met Linus, I suspect retorting to him would be futile, given his parting shot was "Because I'm a bastard, and proud of it!". :) Update: It seems Linus is now a reformed character (from Organizational Culture (Part V): Behavior).

    Based on the code you posted, I feel the most relevant quotes for you are from Pike, Martin, and especially Graham-Cumming:

    I suspect that the same people who use debuggers all the time are the same people who don't unit test their code
    and Conway:
    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

    That is, with clean, well-designed code with unit tests there should be less need to fire up the debugger. I suggest you at least consider the option of replacing hours of never-ending crack-pipe debugging sessions with enjoyable creative hours of Test Driven Development.

      That is, with clean, well-designed code with unit tests there should be less need to fire up the debugger.

      I don't think there's ever a need to fire up the debugger. However, there are occasions where a debugger session might just be the fastest way to narrow down an error. Unit tests and the debugger are by no means an either-or decision.

      I occasionally work on code written by someone who has retired. Code which doesn't have unit tests and/or isn't well designed and/or hasn't been touched in a decade or so. I could, of course, just argue it's not maintainable (merlyn). But when I'm interested in the code, I'd rather spit into my hands and grab whatever tools might help.

      The quotes about tracing (merlyn) or stepping through a program (Brian Kernighan and Rob Pike) just miss the point about what debuggers can do. Personally, I'd rather use the debugger than print statements (Daniel Lemire) just because debugging sessions are transient (Brian Kernighan and Rob Pike). I don't want to spend time to format data structures for printing (the debugger does it for free), and I don't want to have to remove the print statements before committing.

      I agree with most of the quotes that you need to think before starting to debug. But I also think that you need to know the debugger to some extent to decide whether it is a good tool to tackle a problem or not. Learning the debugger is not a waste of time, and it is easier to get started with than e.g. Log::Log4perl or Test-driven development.

        I don't think there's ever a need to fire up the debugger
        We support a large and complex product, running in many different countries, written in multiple languages, mostly C++. Whenever one of our executables crashes, our software automatically creates a crash dump file. When one of these crash dumps arrives in my in-box, I load it in the debugger (with matching symbols) to try to understand the root cause of the crash. Does that qualify as having a "need" to fire up the debugger?

        I might add that attaching a debugger to crash dumps is sometimes insufficient to solve the problem, for example when a program crashes because it attempts to access an object that has already been deleted ... which is why we also have a home-grown logging system (similar to Log::Log4perl) so we can see the history of events leading up to the crash.

        I agree with you that a debugger is just one tool among many, and will sometimes be the most effective tool for the job. The main reason I tried to curb the OP's enthusiasm for the debugger is because I looked at his code.

        I occasionally work on code written by someone who has retired. Code which doesn't have unit tests and/or isn't well designed and/or hasn't been touched in a decade or so. I could, of course, just argue it's not maintainable (merlyn). But when I'm interested in the code, I'd rather spit into my hands and grab whatever tools might help.
        Yes, I agree merlyn took an extreme position - perhaps he is one of the few programmers in the world who could challenge the Joel Spolsky wisdom "It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time". Or perhaps he was dealing with smallish systems. Rewriting crap from scratch quickly becomes untenable once you go past a million lines of code. BTW, I keep a list of references on the difficult topic of dealing with legacy code.

        Your liking of the transient nature of debugging sessions baffles me (I may have misunderstood your intent). After all, large successful software is written by teams, over many years ... so I feel it is our duty when faced with nasty debugging problems to make the code better and easier to maintain for our teammates and for those who maintain our code after we leave ... so throwing away the hard-earned insights from an individual's transient debugging session seems unprofessional to me. At a minimum, I would expect some judicious comments and logging that stay with the code.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11127961]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (5)
As of 2024-04-22 09:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found