A valid definition of retarded: debugging by using your brain to simulate a machine executing your code, and then printing variables to the console to validate your assumptions.
This is why tools like GDB exist.
A valid definition of retarded: debugging by using your brain to simulate a machine executing your code, and then printing variables to the console to validate your assumptions.
This is why tools like GDB exist.
Wake up today and find myself being defined as retarded š¤Ŗ
Itās okay, we are all well regarded here
someone is born smart, which is cool. Someone sees more plentiful views on the way of from being retarded to being less retarded, which is funš
It's ok python people can follow this to de-retard themselves: https://realpython.com/python-debugging-pdb/
What is GDB?
debugging concurrent code with microsecond intervals between events makes debuggers worthless. printing logs is the only way to get something to post mortem this kind of code.
when i write code it's either too short if it's linear and too parallel, concurrent and time-dependent if it's not linear.
concurrent solutions can do a lot of things that you can't do with long winded single threads. number one thing is extremely low latency responses. parallel throughput tends to just be simple single threads and usually barely needs debugging.
Debuggers are way more efficient at manipulating points to print variables etc though.
You can also do profiling and see which threads/mutexes/functions are introducing problems and then step through those with a debgugger.
doesn't work in a sub-100ms timescale.
when someone makes a debugger that makes this kind of state inspection post mortem i'll be using it. it's simply impractical for especially low latency network protocols, the debugger assumes linearity and single threaded execution. even the Go debugger, delve is like this, despite most Go code being highly concurrent and parallel and time sensitive.