If you are writing your program entirely by yourself (one-man-band), you of course have more choice over print statements scattered liberally around. On the other hand, if you're working in a team, or are maintaining someone else's code, who may have left the company for instance, this choice becomes somewhat more limited. Different people may have different ideas about where to place print statements and what they should contain. In this case, being able to run and control the code, and what feedback to offer, without (adversely?) affecting anyone else can be very handy.
You may have production code to debug, and are unable to, (read should not), change or move/copy it elsewhere, because of dependencies or circumstance. In this case, the ability to run your code and to modify it WITHOUT CHANGING THE SOURCE can be very useful.
The debugger is one tool among many, use whichever suits your purpose and ability as appropriate.
R.
Re:Reviewer is obviously not a programmer
on
Pro Perl Debugging
·
· Score: 1
I wouldn't like to comment too harshly on the review, because as far as the book goes, as someone once said: "all advertising is good advertising".;-)
R.
Re:part 3 (working around lameness filter)
on
Pro Perl Debugging
·
· Score: 1
Phroggy,
Yours is an excellent example of using the right tool for the job!
10/10:-)
R.
Re:Credentials completely shot in 3rd PP
on
Pro Perl Debugging
·
· Score: 1
Oh dear, 'crashing once a week or so' and 'inside a certain C function' sounds exciting. It might be worth looking at attaching gdb to the running process, that way, when it crashes, (at some indeterminate time in the future), gdb may have a handle on the particular point.
Sometimes we have to use the most appropriate tool for the job / correct screwdriver...
R.
Re:Credentials completely shot in 3rd PP
on
Pro Perl Debugging
·
· Score: 1
It might be worth remembering that in anything other than a perfect world, testing is likely to reduce, but will never eliminate all bugs. Why? Because humans write computer programs. Knowing how to use any form of debugging tool, (print statement or otherwise), can be an advantage in finding and eliminating the problem. Of course when you're trying to debug a moving target like javascript, (on both FF and IE at the very least), now there's a whole new can of worms;-)
R.
Slashdot Mirror
If you are writing your program entirely by yourself (one-man-band), you of course have more choice over print statements scattered liberally around. On the other hand, if you're working in a team, or are maintaining someone else's code, who may have left the company for instance, this choice becomes somewhat more limited. Different people may have different ideas about where to place print statements and what they should contain. In this case, being able to run and control the code, and what feedback to offer, without (adversely?) affecting anyone else can be very handy. You may have production code to debug, and are unable to, (read should not), change or move/copy it elsewhere, because of dependencies or circumstance. In this case, the ability to run your code and to modify it WITHOUT CHANGING THE SOURCE can be very useful. The debugger is one tool among many, use whichever suits your purpose and ability as appropriate. R.
I wouldn't like to comment too harshly on the review, because as far as the book goes, as someone once said: "all advertising is good advertising". ;-)
R.
Phroggy, Yours is an excellent example of using the right tool for the job! 10/10 :-)
R.
Did I mention I don't fly ?-) R.
Oh dear, 'crashing once a week or so' and 'inside a certain C function' sounds exciting. It might be worth looking at attaching gdb to the running process, that way, when it crashes, (at some indeterminate time in the future), gdb may have a handle on the particular point. Sometimes we have to use the most appropriate tool for the job / correct screwdriver... R.
It might be worth remembering that in anything other than a perfect world, testing is likely to reduce, but will never eliminate all bugs. Why? Because humans write computer programs. Knowing how to use any form of debugging tool, (print statement or otherwise), can be an advantage in finding and eliminating the problem. Of course when you're trying to debug a moving target like javascript, (on both FF and IE at the very least), now there's a whole new can of worms ;-)
R.