Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I am a puts debuggerer

tenderlovemaking.com

Post reply on HN
Print view View original

31–40 of 60 posts

Re: I am a puts debuggerer

#31

Post by jschwartzi »

sergiotapia wrote: post #19

It's nice to see I'm not alone! I haven't really used a 'legit' debugging tool since my days as a C# developer. And that was because how easy debugging was in Visual Studio. I have yet to find something that just works, as easily. (I imagine XCode works perfect too, never programmed in Obj-C though).

Gdb works well for embedded Linux targets, provided you have Ethernet or a serial port. You can bring gdb up I the target and then connect the host to it and debug from there. If you're using an Eclipse-based tool then you can set that tool up to connect to a remote gdb.

At least, that's how it works when I'm developing under Linux. I'm not sure about Windows or Mac OS.

Re: I am a puts debuggerer

#32

Post by pmarreck »

Any time you use the console or a printed output to debug something, that is an embryonic test assertion in the making, and all you have to do is move it to a proper suite. ;)

If you are doing it because you are deep in some nested conditionals... you need to refactor.

Re: I am a puts debuggerer

#33

Post by djcapelis »

teuobk wrote: post #14

In the embedded world, sometimes you can't even be a puts/printf debuggerer. There have been some situations, typically early in development, where I've had to be a "turn the LED on or turn it off" debuggerer. Amazingly, that binary output is usually enough to fix whatever problem is happening and bootstrap into printf debugging or full ICE interactive debugging.

One time I couldn't get to an LED so I used an IR thermometer pointed at chip to debug it.

Telling the difference between hot and cold and whether it was getting warmer or colder told me what I needed to know.

Re: I am a puts debuggerer

#34

Post by kevin_thibedeau »

teuobk wrote: post #14

In the embedded world, sometimes you can't even be a puts/printf debuggerer. There have been some situations, typically early in development, where I've had to be a "turn the LED on or turn it off" debuggerer. Amazingly, that binary output is usually enough to fix whatever problem is happening and bootstrap into printf debugging or full ICE interactive debugging.

Just did that the other day trying to track down a hard fault at startup. Binary code on LEDs was all it took to zero in on the cause.

Re: I am a puts debuggerer

#35

Post by djcapelis »

teh_klev wrote: post #26
teuobk wrote: post #14

In the embedded world, sometimes you can't even be a puts/printf debuggerer. There have been some situations, typically early in development, where I've had to be a "turn the LED on or turn it off" debuggerer. Amazingly, that binary output is usually enough to fix whatever problem is happening and bootstrap into printf debugging or full ICE interactive debugging.

Once upon a time in the olden days, if certain makes of PC couldn't successfully complete the Power On Self Test and couldn't initialise video output to report the problem, it would beep the fault code through the system speaker.

Most motherboards still do this.

Re: I am a puts debuggerer

#36

Post by altano »

mberning wrote: post #10

I don't even understand the 'have to learn a debugger' statement. Is he referring to things like pry? I rather enjoy the debugger in Rubymine, and part of the reason for this is that it more or less works like every other debugger I have ever used (eclipse, vs, chrome debugger, etc.) There is not much to learn if you have used any debugger in the past.

Debuggers are very powerful tools and if they're worth anything, they'll have a learning curve.

For example:

- When debugging multi-threaded code, you can test interlace events by manually pausing executing of certain threads at certain points. I've used this many times to manually reproduce a rare race condition.

- Tweaking a conditional breakpoint at runtime can be easier than rewriting code and re-running.

- Visual Studio has "tracepoints" which are like inserting a puts/printf statement in the code, but allows you to output things you might not easily want to write code to do like the current callstack or function name, e.g. "Print the callstack when I enter this function every 100 times I enter it"

- Poking around in memory can reveal things you wouldn't have thought to output, or is invisible in output, e.g. discovering a BOM in one string and not the other and having that be the cause of a comparison failure or a different path through the code than you think it should be taking.

- Trying to understand control flow when exceptions might be thrown or assertions might be triggered just isn't as easy with puts/print. You're likely to make a bad assumption. Understanding exceptions and how to make your application easy to debug is definitely a skill that begins at coding, not opening the debugger.

If you don't think you "have to learn a debugger" you're missing out on a lot of opportunities to be better at finding bugs.

Re: I am a puts debuggerer

#37

Post by aptwebapps »

teh_klev wrote: post #26
teuobk wrote: post #14

In the embedded world, sometimes you can't even be a puts/printf debuggerer. There have been some situations, typically early in development, where I've had to be a "turn the LED on or turn it off" debuggerer. Amazingly, that binary output is usually enough to fix whatever problem is happening and bootstrap into printf debugging or full ICE interactive debugging.

Once upon a time in the olden days, if certain makes of PC couldn't successfully complete the Power On Self Test and couldn't initialise video output to report the problem, it would beep the fault code through the system speaker.

Except, for some makes, it wouldn't get that far but at least that narrowed down the possibilities.

Re: I am a puts debuggerer

#38

Post by bhaak »

I guess it is by far easier to be a puts debugger than a printf debugger (I'm saying that as someone who prefers printf over a debugger but pry on Ruby over simple puts).

You can get a much longer way with what Ruby lets you do with puts than you would with printf in C/C++.

Like the example with `method(:render).source_location` from the article. You can't do that in C/C++ on a general base.

Or pretty printing a struct is cumbersome. In Ruby you just do `puts obj.inspect` and get a readable representation of the object.

Re: I am a puts debuggerer

#39

Post by pmontra »

jedisct1 wrote: post #16

printf()-based debugging is okay when these statements are temporary, or when they are only present in development branches. At $previousjob we had a guy who literally spent a year adding printf() statements everywhere to production code in order to help himself understand the existing code base he had to work on. "It's not printf()-debugging, I'm doing extensive permanent instrumentation". He even developed a whole…

Maybe he should have added log points instead of printfs. He could have used an existing logging framework instead of writing his own. Still

1) writing your own code is a valuable learning experience

2) wasting time is a drag on the team and on the company so he should compromise between learning and producing (but where was management?)

3) too much logging pollutes the code too

Re: I am a puts debuggerer

#40

Post by steve-howard »

djcapelis wrote: post #35
teh_klev wrote: post #26

Earlier quoted context omitted.

Once upon a time in the olden days, if certain makes of PC couldn't successfully complete the Power On Self Test and couldn't initialise video output to report the problem, it would beep the fault code through the system speaker.

Most motherboards still do this.

Just not as often, I imagine.
Post reply on HN