I am a puts debuggerer • Hacker News Board

Re: I am a puts debuggerer

#51

Post by blueblob » Sun, Feb 07, 2016, 2:09 PM UTC

akkartik wrote: post #45

Mithaldu wrote: post #2

I'm an everything debuggerer. I use print statements when its convenient (mainly when i want to know what's going on in a longer process), i use interactive debuggers when its convenient (mainly when i want to inspect complex data structures), sometimes i run the interactive debugger and then dump a complext data structure to STDOUT with a print (mainly when i want to reference it later on). I don't get the people wh…

The fact remains that when we think of debugging tools we tend to build monolithic debugging environments rather than unix-style primitives that do one thing well. Thinking deeply about when prints work best and how we can ameliorate their drawbacks is a fertile place to change this. A couple of concrete ideas: a) For a while now, I've experimented with editor macros to comment/uncomment code that insert a special ma…

> Print too much and it becomes easy to get lost in all the verbiage.

very much related to how much is too much. If you can simply filter out lines you don't want to see, like `grep -v '^first comment'`

Re: I am a puts debuggerer

#52

Post by cwilkes » Sun, Feb 07, 2016, 3:40 PM UTC

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…

I would ask myself why he felt he needed to add such statements. Provided he isn't an idiot it is probably because the flow was hard to understand. Was that his fault?

I've found that if I can't understand the code it is because it is unnecessarily complex or, to mimic an above poster, there's too much state going on. Refactor to remove confusion.

Imagine yourself as a newbie asked to support such thing in production. Could you do it? If no why not?

Re: I am a puts debuggerer

#53

Post by dominotw » Sun, Feb 07, 2016, 4:31 PM UTC

usagimaru wrote: post #28

dominotw wrote: post #12

Earlier quoted context omitted.

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

ah yea I meant without.

Godebug doesn't work with 1.5 vendor-ed deps, sigh !

Re: I am a puts debuggerer

#54

Post by tenderlove » Sun, Feb 07, 2016, 5:10 PM UTC

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.

Oh I've done this too on my TI Launchpad projects. Supposedly there is a way to attach a debugger, but I haven't figured out how to do that yet. I turned the LED on and used longer and shorter "on" times to differentiate between 1's and 0's. It was fun, but the feedback loop was very slow.

Re: I am a puts debuggerer

#55

Post by mikeash » Sun, Feb 07, 2016, 5:19 PM UTC

pkaye wrote: post #29

mikeash wrote: post #25

Earlier quoted context omitted.

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 tem…

Sounds like you were lucky to have that bad instruction disappear with your modification. Cool story.

Re: I am a puts debuggerer

#56

Post by PeCaN » Sun, Feb 07, 2016, 7:35 PM UTC

mattiemass wrote: post #3

I've always found people skilled with debuggers look like they have super powers. Symbolic debuggers really are tricky, and these are some good tips.

I used to think symbolic debuggers were tricky until I actually bothered to pick up GDB. It seems hard and complicated at first, but it's really not. You can get very far with just "break", "next", and "print". It's so much nicer than printf debugging (and I used to be a hardcore printf debuggerer).

Re: I am a puts debuggerer

#57

Post by djcapelis » Sun, Feb 07, 2016, 8:50 PM UTC

eps wrote: post #47

djcapelis wrote: post #33

Earlier quoted context omitted.

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.

Impressive. Saying as someone who once debugged something by ear making the motherboard emit a cathode ray tube like hum instead of blinking or beeping.

Nice! How'd you end up generating the hum? I assume you oscillated something, remember what it was?

Re: I am a puts debuggerer

#58

Post by eps » Sun, Feb 07, 2016, 9:41 PM UTC

djcapelis wrote: post #57

eps wrote: post #47

Earlier quoted context omitted.

Impressive. Saying as someone who once debugged something by ear making the motherboard emit a cathode ray tube like hum instead of blinking or beeping.

Nice! How'd you end up generating the hum? I assume you oscillated something, remember what it was?

I think it involved a NIC, but I don't remember what it was exactly that I was doing to it. It was over 10 years ago.

Re: I am a puts debuggerer

#59

Post by mbfg » Mon, Feb 08, 2016, 3:59 AM UTC

it's the 21st century. i use a debugger.

Re: I am a puts debuggerer

#60

Post by bhaak » Fri, Feb 19, 2016, 9:59 AM UTC

eps wrote: post #48

bhaak wrote: post #38

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 stru…

__FILE__, __LINE__, __FUNCTION__ Yes, there's no default pretty print for structs, but no sane C programmer would ever expect or want that blubber to come available by default. Mainly because there's very rarely a need to printf-dump anything more than a select variable or a struct field. Different language - different debugging realities.

Those only act on the currently defined context.

Especially __FUNCTION__ is by no means an equivalent to source_location.

__FUNCTION__ tells you, in what function you currently are.

source_location tells you "in what file has this method of this object been defined". Because of duck typing this is much harder to answer in Ruby. But even in C, because of linking it can be non obvious what function actually gets called.