Debug Programs by Modifying Them
merveilles.town
Debug Programs by Modifying Them
1–10 of 37 posts
Re: Debug Programs by Modifying Them
#2Sometimes you can't even use print debugging.
I've debugged by modifying colors a few times.
Re: Debug Programs by Modifying Them
#3Sometimes you can't even use print debugging. I've debugged by modifying colors a few times.
With shaders this is often the best bet. You end up encoding some value you want to measure as a color, and you can observe how it varies over what you’re drawing. There are some pretty sophisticated step debugging tools these days, but just like with print debugging, debugging by color always works on all platforms and has no special setup.
Re: Debug Programs by Modifying Them
#4Sometimes you can't even use print debugging. I've debugged by modifying colors a few times.
Multiple times I've had bugs that disappeared when print debugging was added. To say that that was frustrating is an understatement.
(But where there's a will, there's a way. It just takes longer, sigh.)
Re: Debug Programs by Modifying Them
#5Sometimes you can't even use print debugging. I've debugged by modifying colors a few times.
Multiple times I've had bugs that disappeared when print debugging was added. To say that that was frustrating is an understatement. (But where there's a will, there's a way. It just takes longer, sigh.)
Those are known as Heisenbugs.
Re: Debug Programs by Modifying Them
#6Honestly, I don't get this debate.
If you were to take the pain points of debug by print, and address them, you'd come up with a debugger. Being able to put those "print" statements anywhere without recompiling, being able to go step-by-step in the code, etc. And sure, that's not always available.
Both end up having impacts on the thing they observe. A print() call can cause microscopic delays that are enough to cause a race condition not to trigger, as can waiting on a breakpoint, etc. If you compile with debug symbols, that can cause some bugs not to surface, as they are only visible when you compile with -O3 or whatnot (eg. a bug involving reading unallocated memory).
Both are just tools. Sometimes one is better in a given situation. Sometimes the other is. I just don't get how this is like an emacs vs vim thing.
Re: Debug Programs by Modifying Them
#7Here's the thing: Use the best tool for the job. Work smarter, not harder. I'm debugging something right now. I can use the rapid compile time of golang to do things like: change the binary format, so that I can trace what part of the buffer was written by which function invocation. I can also write very sophisticated conditional debugging that would be iffy on most debuggers, where the machine sifts through the possibilities for me. That "one weird trick" has earned me a reputation as a magic debugger multiple times.
Sometimes, it's best to use a printf and spot the thing in the console, or to see what's going on with the data to gain a better understanding.
Sometimes it's best to debug something to rapidly see a complex interaction firsthand.
It's always good to be smart about using multiple tools creatively.
Re: Debug Programs by Modifying Them
#8Sometimes you can't even use print debugging. I've debugged by modifying colors a few times.
Multiple times I've had bugs that disappeared when print debugging was added. To say that that was frustrating is an understatement. (But where there's a will, there's a way. It just takes longer, sigh.)
Sounds like you solved the problem though. Leave the printing in there:P
Re: Debug Programs by Modifying Them
#9Oh hey man, surprised to see a Merveilles link on HN haha :)
Debug by print/console.log is fine -- sometimes it's the fastest/easiest way to quickly troubleshoot a fairly complex flow, etc.
I've worked on mobile web apps where we had no debugging tools (back in the early days) perhaps due to lack of full access to the hardware, etc. So we would do things like set a background color based on a certain value, add borders, change font color, stuff like that. Or just draw debug console text on top of everything.
Sometimes the actual debugger for the provided software/platform is of low quality too.
Conversely, being able to set conditional breakpoints is pretty powerful and I miss doing so when it's not possible!
Re: Debug Programs by Modifying Them
#10Honestly, I don't get this debate. If you were to take the pain points of debug by print, and address them, you'd come up with a debugger. Being able to put those "print" statements anywhere without recompiling, being able to go step-by-step in the code, etc. And sure, that's not always available. Both end up having impacts on the thing they observe. A print() call can cause microscopic delays that are enough to caus…
For embedded work, I've found great value in being able to observe and manipulate running systems without interrupting code execution. A non-blocking console buffer is very handy, but even more so is instrumentation for periodically sampling arbitrary variables cooperatively / in synch with program execution.
When you're making a 50KW motor spin under PID control, a debugger breakpoint can cause a lot of real damage.