4 ms·

Do you ever have to deal with concurrency or external services? Trying to debug a program which is making an RPC call will likely cause the remote service to ti

by theamk 6y ago

Do you ever have to deal with concurrency or external services? Trying to debug a program which is making an RPC call will likely cause the remote service to timeout and fail by the time you resume program, ruining your experience. And there is also classical logic/algorithms problems: your program did not crash, but after 50 iterations of the main loop, the result set is empty. With prints, you get it all on screen and stare at the intermediate progress for a few minutes. With debugger, you can set a breakpoint... and then you have to hit "continue" 50 times, trying to remember what the values were 20 steps ago.

ehnto 6y ago
You do have to work around concurrency sometimes, it will obviously depend entirely on your stack but for me there is usually way to still get a debugger on the thread I want. For your second point, logic/algorithmic problems are when the debugger shines the most. If you don't know where the problem is, you can put a breakpoint somewhere you know is after the problem then climb back up the recorded stack frames to find the issue. If the issue is in a loop, you can put in a conditional watcher to only break when your condition is met, or just set a breakpoint one line after the loop and inspect the loop result right there. The most useful part of debugging is the ability to rapidly excercise your "aha" moments. When you print debug, you see the issue and go "Aha!" now you have to go verify with another print. If I see the issue in a debugger, I go "Aha!" and then immediately get to look at the variable or variables I've discovered is part of the problem. I want to make sure it's clear that I don't think print debugging is useless, it's got it's moments of usefulness. I just don't understand how someone would not want to take advantage of an advanced debugger when it's available. They are so powerful, it would be like watching a mechanic use a pair of pliers when they have access to an impact gun.
db48x 6y ago
You really should try Pernosco. You can record your program, and replay it as often as you like without ever having to contact the RPC service again; it replays the same response from the server in exactly the same way as it was recorded. The server never times out while you’re paused, because RR remembers the exact pattern of syscalls that your program executed, and always replays them deterministically. The server won’t time out in the play back because it didn’t time out in the recording. It really is a superpower. And instead of putting a breakpoint and then hitting continue 50 times, you query the Pernosco database for all executions of that line, and it shows them to you as a list. You can then have it evaluate expressions at those points in time, and it shows them in the same list. It’s fast too; it can evaluate your expression at hundreds of points in time faster than you can type them in.

by theamk 6y ago

ehnto 6y ago

You do have to work around concurrency sometimes, it will obviously depend entirely on your stack but for me there is usually way to still get a debugger on the thread I want. For your second point, logic/algorithmic problems are when the debugger shines the most. If you don't know where the problem is, you can put a breakpoint somewhere you know is after the problem then climb back up the recorded stack frames to find the issue. If the issue is in a loop, you can put in a conditional watcher to only break when your condition is met, or just set a breakpoint one line after the loop and inspect the loop result right there. The most useful part of debugging is the ability to rapidly excercise your "aha" moments. When you print debug, you see the issue and go "Aha!" now you have to go verify with another print. If I see the issue in a debugger, I go "Aha!" and then immediately get to look at the variable or variables I've discovered is part of the problem. I want to make sure it's clear that I don't think print debugging is useless, it's got it's moments of usefulness. I just don't understand how someone would not want to take advantage of an advanced debugger when it's available. They are so powerful, it would be like watching a mechanic use a pair of pliers when they have access to an impact gun.

db48x 6y ago

You really should try Pernosco. You can record your program, and replay it as often as you like without ever having to contact the RPC service again; it replays the same response from the server in exactly the same way as it was recorded. The server never times out while you’re paused, because RR remembers the exact pattern of syscalls that your program executed, and always replays them deterministically. The server won’t time out in the play back because it didn’t time out in the recording. It really is a superpower. And instead of putting a breakpoint and then hitting continue 50 times, you query the Pernosco database for all executions of that line, and it shows them to you as a list. You can then have it evaluate expressions at those points in time, and it shows them in the same list. It’s fast too; it can evaluate your expression at hundreds of points in time faster than you can type them in.