Is it a complete answer? Of course not. Neither is trying to spin a wheel that you are truing. Produces a ton of output that is roughly in an expected pattern, and can be acted on.
I do not enjoy stepping through all of the context setting up the system to fail. I’ve not tried a debugger that can “back up”, that may well be a different experience. But I loathe stepping through code, walking on eggs, overstepping, “oops, thar she blows, start over”. Like Bugs Bunny on the piana.
Rather just toss in some prints, let fly, sift through the wreckage. My builds are fast enough to make the turn around acceptable.
> Print debugging.... It works on any system
No it does not. It requires a console, and not all systems have a console.
By the way, there are actually ways to expose a print function on shader code, provided there is driver support.
https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob...
"gl_FragColor.x = 1.0; is the printf of graphics debugging. Stone knives and bearskins."
— https://mobile.twitter.com/id_aa_carmack/status/568861553245...
It has great Vulkan compatibility and it helped me greatly when building an object picking buffer by visualising everything from call trees to resource contents and metadata. I believe it should come in handy for any GPU-based project, not just 3D/2D graphics.
If the system can't emit any data, well, you're kind of stuck anyway.
It's also by all recognition, functioning perfectly :)
A huge proportion of computing devices have no method of producing any out put, other than to some form of actuator, at all.
"print statements" are useless in this class of device.
Stretching the definition of "print statement" to recording pulses from a pin is, well, a stretch!
Poor young programmers. If the only tool you have is a hemmer, every problem is a thumb.
Yes, they are. How do you think text terminals work?
It is a long way from "pulses on GPIO pins" to a print statement.
This is quite strange. Let us remember the context
> Print debugging is a technique that will never go out of style. It works on any system,
So you are suggesting that watching the blinking of a GPIO pin (I hope you have an oscilloscope, or some other probe, rather than applying to to your tongue) is the same as "Print debugging"?
I contend that in any sensible use of technical English "print debugging" is text output to a console.
In that context there are a lot of systems, possibly most computer systems, do not have access to that. It is not unusual for developers to go to elaborate lengths to attach consoles to these systems - not the same as " It works on any system, "
If your simply monitoring activity through an external source (whether it’s an oscilloscope or watching traffic through a network analyzer) then that’s basically black box testing.
Actuators work too. It's not unheard of in robotics to debug by adding statements that make some actuator do specific movements that communicate the information you want to surface.
Anything you can use to output nonzero amount of bits to the environment can work for print debugging.
You can print debug on an Arduino for example
So, yes, it works on pretty much any system.
And you then have a different system.
My point is consoles are not ubiquitous in computing. Computer systems that lack them are very common
Because all those systems, even the very nicest, all over the palnet, very really have "JTAG etc connections,"
Those are things you attached to the system. You attach them in a complex error prone process, at the end of it you have a different system.
A lot of (most?) computers do not have consoles.
It is a common error amongst developers (who do not work in embedded systems) to assume there is a screen supporting text of some sort. It is an error
So if you connect up a bunch of wires and everything goes well "too easy" you can get output from some, not all, systems.
What you describe is no what the comment about "print debugging" means, to me.
Only when you get into realm of few cents per microcontroller then you don't have it
It does not. You just send the log output somewhere (often a different system). If you have a deployment with no logging infrastructure (either local for smaller setups or distributed for large scale), you have a major problem beyond just debugging visibility.
How?
If it's an actual standalone deaf, dumb, and blind black box with zero world interaction then you should, at least, have a hardware probe and step debugging capabilities and you can always flash a sign of some kind on some bus or another.