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

21–30 of 60 posts

Re: I am a puts debuggerer

#21

Post by sergiotapia »

stevebmark wrote: post #17

This appears to be a post by a novice developer, discouraging the use of time tested, invaluable debugging tools? Encouraging slower, worse debugging...for what? And "tender lovemaking" for the title of a tech blog? That's childish and short sighted. Rails has vibrant problems in its ecosystem (everything is global, tracing behavior is hard, everything is magic, many Rails developers have no idea how what they're usi…

It looks like you are the novice here, Tenderlove is a well known Rails core contributor and all around tender guy.

https://twitter.com/tenderlove

Re: I am a puts debuggerer

#23

Post by pkaye »

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.

I have done things like modulating a GPIO pin or LED to return a byte or two and see it on a oscilloscope. One time I was debugging an embedded device from a customer for a temperature controller where periodically the readings would be out of range. Turned out the CPU IP had a bug with interrupt handling when a particular instruction was used and after confirming no other side effect in simulations, the solution was to avoid using that instruction in the firmware.

Re: I am a puts debuggerer

#24

Post by stevebmark »

hereandthere2 wrote: post #20
stevebmark wrote: post #17

This appears to be a post by a novice developer, discouraging the use of time tested, invaluable debugging tools? Encouraging slower, worse debugging...for what? And "tender lovemaking" for the title of a tech blog? That's childish and short sighted. Rails has vibrant problems in its ecosystem (everything is global, tracing behavior is hard, everything is magic, many Rails developers have no idea how what they're usi…

Just wanted to point out that you may disagree with him here but @tenderlove is far from a novice https://github.com/tenderlove?tab=activity

Yes, it appears I am wrong about my label of "novice" from the pure verbosity point of view. Being a core contributor to anything does not imply being a good programmer. I don't know this person (and don't care, I have no ties to the Rails community). I think that dismissing the use of a runtime debugger is a novice action.

Re: I am a puts debuggerer

#25

Post by mikeash »

pkaye wrote: post #23
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.

I have done things like modulating a GPIO pin or LED to return a byte or two and see it on a oscilloscope. One time I was debugging an embedded device from a customer for a temperature controller where periodically the readings would be out of range. Turned out the CPU IP had a bug with interrupt handling when a particular instruction was used and after confirming no other side effect in simulations, the solution was…

That sounds really interesting. How did you get from modulating a GPIO pin to figuring out that particular instruction was bad?

Re: I am a puts debuggerer

#26

Post by teh_klev »

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.

Re: I am a puts debuggerer

#27

Post by rolodato »

lostcolony wrote: post #7

I've noticed that the more stateful my code, the more use I get from a debugger. Being able to poke and prod and see the various values in memory can be extremely helpful when I'm writing in an OO language, that just spitting to console doesn't really do (because I don't know up front what I'm going to care about; what influences what, what values are in the stack, in a containing object, etc). Conversely, the less s…

I have the exact same experience. Being able to work with a value substitution model is incredibly helpful for mental debugging, just from reading the code. It just tires me to have to track where values are being modified, by who, putting watchers on variables, etc.

Re: I am a puts debuggerer

#28

Post by usagimaru »

dominotw wrote: post #12
yandrypozo wrote: post #9

It's great find people like you and me :) I'm a pprint, fmt.Println, panic, console.debug, log.Print debugger !!

does golang even have a debugger with horrible gdb hacks?

There's godebug[0], which has all the hacks you could ever want! But I'm guessing you meant 'without', to which the answer is: no.

[0] https://github.com/mailgun/godebug

Re: I am a puts debuggerer

#29

Post by pkaye »

mikeash wrote: post #25
pkaye wrote: post #23

Earlier quoted context omitted.

I have done things like modulating a GPIO pin or LED to return a byte or two and see it on a oscilloscope. One time I was debugging an embedded device from a customer for a temperature controller where periodically the readings would be out of range. Turned out the CPU IP had a bug with interrupt handling when a particular instruction was used and after confirming no other side effect in simulations, the solution was…

That sounds really interesting. How did you get from modulating a GPIO pin to figuring out that particular instruction was bad?

It is from a long time back so things are fuzzy now but here is my recollection. I wanted to determine the source of the corrupted temperature readings but every pin on the MCU were utilized so no easy way to read it out. I noticed one pin was used just for an activity LED so I modified that routine to pump out a serial bit pattern read from a variable. Then I instrumented various parts of the code related to the temperature measurement algorithm to see the earliest point where it was corrupted. I traced it to the interrupt routine that reads the temperature sensor. In investigating that code I modified it slightly which caused the problem to disappear. Experimenting showed that a particular instruction would be the source of the problem. At that point I consulted with the ASIC designer and the confirmed the bug and identified the scope of the issue. Also should add that various debugging hardware like ICE didn't work maybe due to timing differences.

Re: I am a puts debuggerer

#30

Post by gizmo686 »

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.

Back at an old job, I was working on a new embedded system. It took us about a month before we bothered setting up UART for printf debugging. Fortunately the CPU/devboard supported gdb out of the box. What we ended doing was having a global char pointer point to somewhere in the middle of the memoryspace, and we would log things by appending to that string. Then we could gdb in and print the contents of the string.
Post reply on HN