I usually call this ddd, debug driven development, or in case of php die() driven development :)
Printf debugging is ok
81–90 of 152 posts
Re: Printf debugging is ok
#82Print debugging us for when you have a quick itteration cycle. I don't know what debuggers are for because if you don't have a quick itteration cycle you should be killing yourself to have a quick iteration cycle.
On the contrary, adding print statements increases iteration time, because you need to edit the file, recompile and relaunch the program. Whereas adding a breakpoint is just one click in the margin of the editor.
Re: Printf debugging is ok
#83Earlier quoted context omitted.
Maybe it takes less than 2 hours to add such a configuration knob?
That’s a good idea except it is in another team’s service and I’m not very familiar with their code. But I can try Well, the hard part isn’t actually the code change (reasonably obvious) it is deploying my own copy of their service…
Can you just set the local time two hours into the future?
Or modify the expiry time locally / not use the one from the token at all.
Re: Printf debugging is ok
#84Earlier quoted context omitted.
The crashes/bugs I deal with are rarely straight down failures, they are often the 1 out of 100 runs kind, so printf debugging is the only way to go really. And I used to be big on using debuggers, but now I’m horribly out of practice.
> The crashes/bugs I deal with are rarely straight down failures, they are often the 1 out of 100 runs kind, so printf debugging is the only way to go really. Another thing I’ve found helpful, is to write out a “system state dump” (say in JSON) to a file whenever certain errors happen. Like we had a production system that was randomly hanging and running out of DB connections. So now whenever the DB connection pool i…
Why not just dump a core, rather than going to all that effort?
Re: Printf debugging is ok
#85Whatever works so I can fix it and be home on time. I will even print (in paper) the code and step through it with a pen. Again, whatever works. Also, will we ever move forward from these sort of discussions? Back when I was a mechanic no one argued about basics troubleshooting strategies. We just aimed to learn them and apply them all (as necessary).
eternal september; people new people are continually learning new strategies. You're correct, the real issue comes down to 1. making sure those printf statements don't wind up in prod, spilling potentially sensitive data or corrupting a data stream 2. making sure that non-printf tooling is built so that only printf debugging isn't used We tend to get caught up in false dichotomies.
I use a DBUG() macro that wraps fprintf to stderr when a DEBUG is defined and NDEBUG is not defined, or otherwise is nothing.
Re: Printf debugging is ok
#86Printf debugging is definitely OK, when that is the only tool available.
Other than that, people should spend time learning the ins and outs of their debugging tools, like they do for the compiler switches and language details.
Additionally, when having the option to pick the programming language, it isn't only the syntax sugar of the grammar, or its semantics that matter, it is the whole ecosystem, including debugging tools.
Personally I rather have a great debugging experience than less characters per line of code.
Re: Printf debugging is ok
#87If you have a reproducible test case that runs reasonably quickly, then I think printf debugging is usually just as good as a "real" debugger, and a lot easier. I typically have my test output log open in one editor frame. I make a change to the code in another frame, save it, my build system immediately re-runs the test, and the test log immediately refreshes. So when the test isn't working, I just keep adding print…
Things like variable watchpoints mean that debuggers are still the better option.
Re: Printf debugging is ok
#88If using the debugger is less efficient than using printf then it's a symptom of a wider problem. To be clear though, "printf debugging" is not the same thing as adding structured debug logs to your service and enabling it on demand via some config. Most production services should never be logging unstructured output to stdout. Printf debugging is just throwing out some text to stdout, and it generally means running…
That wider problem may simply be that you're using C or C++ with optimized binaries and can't reproduce the bug in the unoptimized/debug build.
Re: Printf debugging is ok
#89If you have a reproducible test case that runs reasonably quickly, then I think printf debugging is usually just as good as a "real" debugger, and a lot easier. I typically have my test output log open in one editor frame. I make a change to the code in another frame, save it, my build system immediately re-runs the test, and the test log immediately refreshes. So when the test isn't working, I just keep adding print…
Things like variable watchpoints mean that debuggers are still the better option.
You can add the condition to the print statement and grep for it if it gets too verbose.
Re: Printf debugging is ok
#90Earlier quoted context omitted.
That’s a good idea except it is in another team’s service and I’m not very familiar with their code. But I can try Well, the hard part isn’t actually the code change (reasonably obvious) it is deploying my own copy of their service…
Can you just set the local time two hours into the future? Or modify the expiry time locally / not use the one from the token at all.
The token isn’t being verified in my service it is being verified in a remote service. I can’t easily change the clock on the remote service. It runs in a K8S pod and (AFAIK) K8S doesn’t support time namespaces. And even if it does, the pod is deployed by a custom K8S operator so unsure if I could make the operator turn that on even if it is available. And the remote service is a complex monolith which uses lots of RAM so trying to run it on my own laptop will be painful