Not having a debugger has made me good at debugging
-
I found a bug in my UIX library having to do with DMA and multiple transfer buffers. It only reproduces on one platform. I've narrowed it to a specific process, but I still don't know why it halts. It doesn't do it right away, so it's an intermittent problem. The best kind. *cracks knuckles* Edit: Fixed the bug. Prior to working on lil embedded widgets I was spoiled. I had numerous ways to do forensics on my running code, not the least of which was a debugger. I don't typically have a debugger anymore, and while it's possible to use debug probes with embedded gear they're usually so slow that I want to get out and push. Now since I don't have one, I've been forced to think more clearly about how my code runs and what it's doing at runtime at any given point. One day a guy told me GFX was failing after a couple of days when writing text. I immediately narrowed it mentally to three places within a labyrinth of code, with a most likely culprit that turned out to be the thing. I knew it because it smelled like heap frag and I was right. That's just one example. The opener of this post is another, assuming I'm right about it (I am) A few years ago I wouldn't have been able to do that. I'm super glad for these new abilities. It feels a bit like a superpower.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I found a bug in my UIX library having to do with DMA and multiple transfer buffers. It only reproduces on one platform. I've narrowed it to a specific process, but I still don't know why it halts. It doesn't do it right away, so it's an intermittent problem. The best kind. *cracks knuckles* Edit: Fixed the bug. Prior to working on lil embedded widgets I was spoiled. I had numerous ways to do forensics on my running code, not the least of which was a debugger. I don't typically have a debugger anymore, and while it's possible to use debug probes with embedded gear they're usually so slow that I want to get out and push. Now since I don't have one, I've been forced to think more clearly about how my code runs and what it's doing at runtime at any given point. One day a guy told me GFX was failing after a couple of days when writing text. I immediately narrowed it mentally to three places within a labyrinth of code, with a most likely culprit that turned out to be the thing. I knew it because it smelled like heap frag and I was right. That's just one example. The opener of this post is another, assuming I'm right about it (I am) A few years ago I wouldn't have been able to do that. I'm super glad for these new abilities. It feels a bit like a superpower.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Yes, back in the day we either had no debugger or one which was unusable (I'm looking at you, OpenVMS). A developer must know how to debug without a debugger and must know when to use one and when not to. 90% of bugs don't require a debugger, just common sense.
-
Yes, back in the day we either had no debugger or one which was unusable (I'm looking at you, OpenVMS). A developer must know how to debug without a debugger and must know when to use one and when not to. 90% of bugs don't require a debugger, just common sense.
I've been coding since '86 so I cut my teeth on programming without a debugger. However, my code was much simpler because my machines were at best 2MHz 16 bit lil monsters with 256KB of RAM at best a 1.44MB floppy. Now my little widgets often have megabytes of program storage, gobs more RAM and run at hundreds of MHz or even GHz speeds. That and I didn't have C and C++ available. I was using Pascal, BASIC and assembly. It's a different world. My code is so much more complicated now. I have threading to contend with, including multiple cores in many cases, several different ways of doing wireless comms, and an entire Internet to talk to. Things are just different now.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I found a bug in my UIX library having to do with DMA and multiple transfer buffers. It only reproduces on one platform. I've narrowed it to a specific process, but I still don't know why it halts. It doesn't do it right away, so it's an intermittent problem. The best kind. *cracks knuckles* Edit: Fixed the bug. Prior to working on lil embedded widgets I was spoiled. I had numerous ways to do forensics on my running code, not the least of which was a debugger. I don't typically have a debugger anymore, and while it's possible to use debug probes with embedded gear they're usually so slow that I want to get out and push. Now since I don't have one, I've been forced to think more clearly about how my code runs and what it's doing at runtime at any given point. One day a guy told me GFX was failing after a couple of days when writing text. I immediately narrowed it mentally to three places within a labyrinth of code, with a most likely culprit that turned out to be the thing. I knew it because it smelled like heap frag and I was right. That's just one example. The opener of this post is another, assuming I'm right about it (I am) A few years ago I wouldn't have been able to do that. I'm super glad for these new abilities. It feels a bit like a superpower.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
One of my university professors was talkin about 'debugging by cranial massage' :-) That was in 1977. The standard debugging method was adding console output statements in the appropriate places - which takes a lot of practice. It gave me a valuable 6th sense in where to place breakpoints in more recent debuggers: Several times, people looking over my shoulder asked 'Why do you put the breakpoint there?' I answered honestly: 'Dunno. It may be a good place for looking around' - and it was. I didn't see a decent debugger until around 1980. Some of the features of that one, I still miss: You could single step by function call rather than by line. And you could set the range for single stepping (by call or line), e.g. to a single function or module - or set in a large unit and reset in subrange within that module, leaving step breakpoints only in the interesting parts. There may be other debuggers with these features, but none of those I have been using over the years. Of course it was missing a lot that we take for granted today, and it obviously was CLI and not GUI oriented, so I wouldn't want it back in its original form. I still wish we could pick some features from that old software and add them to today's debuggers!
Religious freedom is the freedom to say that two plus two make five.
-
One of my university professors was talkin about 'debugging by cranial massage' :-) That was in 1977. The standard debugging method was adding console output statements in the appropriate places - which takes a lot of practice. It gave me a valuable 6th sense in where to place breakpoints in more recent debuggers: Several times, people looking over my shoulder asked 'Why do you put the breakpoint there?' I answered honestly: 'Dunno. It may be a good place for looking around' - and it was. I didn't see a decent debugger until around 1980. Some of the features of that one, I still miss: You could single step by function call rather than by line. And you could set the range for single stepping (by call or line), e.g. to a single function or module - or set in a large unit and reset in subrange within that module, leaving step breakpoints only in the interesting parts. There may be other debuggers with these features, but none of those I have been using over the years. Of course it was missing a lot that we take for granted today, and it obviously was CLI and not GUI oriented, so I wouldn't want it back in its original form. I still wish we could pick some features from that old software and add them to today's debuggers!
Religious freedom is the freedom to say that two plus two make five.
trønderen wrote:
The standard debugging method was adding console output statements in the appropriate places
This is my life now. And it has similarly honed my abilities.
trønderen wrote:
I still wish we could pick some features from that old software and add them to today's debuggers!
Absolutely.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
One of my university professors was talkin about 'debugging by cranial massage' :-) That was in 1977. The standard debugging method was adding console output statements in the appropriate places - which takes a lot of practice. It gave me a valuable 6th sense in where to place breakpoints in more recent debuggers: Several times, people looking over my shoulder asked 'Why do you put the breakpoint there?' I answered honestly: 'Dunno. It may be a good place for looking around' - and it was. I didn't see a decent debugger until around 1980. Some of the features of that one, I still miss: You could single step by function call rather than by line. And you could set the range for single stepping (by call or line), e.g. to a single function or module - or set in a large unit and reset in subrange within that module, leaving step breakpoints only in the interesting parts. There may be other debuggers with these features, but none of those I have been using over the years. Of course it was missing a lot that we take for granted today, and it obviously was CLI and not GUI oriented, so I wouldn't want it back in its original form. I still wish we could pick some features from that old software and add them to today's debuggers!
Religious freedom is the freedom to say that two plus two make five.
Now we have "Time Travel" debuggers which I have attempted on several occasions and always failed.
-
Now we have "Time Travel" debuggers which I have attempted on several occasions and always failed.
BernardIE5317 wrote:
"Time Travel" debuggers
TARDIS and sonic screwdriver not included. :)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
BernardIE5317 wrote:
"Time Travel" debuggers
TARDIS and sonic screwdriver not included. :)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Maybe that is why I failed.
-
I found a bug in my UIX library having to do with DMA and multiple transfer buffers. It only reproduces on one platform. I've narrowed it to a specific process, but I still don't know why it halts. It doesn't do it right away, so it's an intermittent problem. The best kind. *cracks knuckles* Edit: Fixed the bug. Prior to working on lil embedded widgets I was spoiled. I had numerous ways to do forensics on my running code, not the least of which was a debugger. I don't typically have a debugger anymore, and while it's possible to use debug probes with embedded gear they're usually so slow that I want to get out and push. Now since I don't have one, I've been forced to think more clearly about how my code runs and what it's doing at runtime at any given point. One day a guy told me GFX was failing after a couple of days when writing text. I immediately narrowed it mentally to three places within a labyrinth of code, with a most likely culprit that turned out to be the thing. I knew it because it smelled like heap frag and I was right. That's just one example. The opener of this post is another, assuming I'm right about it (I am) A few years ago I wouldn't have been able to do that. I'm super glad for these new abilities. It feels a bit like a superpower.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
This is an interesting perspective. I agree that debuggers (and profilers) tend to influence the result often to the point of being unable to reproduce the issue. I still use debuggers and profilers, but I try to detect issues more proactively. I generally instrument code and send live updates to a web page hosted by the application. It's more than a live logger; it monitors performance, exceptions, memory, and resources. Those items are visual and time-tagged, so I can often pinpoint the guilty party of misbehavior while it's happening and before the system goes sideways. So, I agree that debuggers aren't always the approprate debugging tool. Our problem-solving toolboxes should be a little deeper than just a debugger.
Keith Rule
-
I found a bug in my UIX library having to do with DMA and multiple transfer buffers. It only reproduces on one platform. I've narrowed it to a specific process, but I still don't know why it halts. It doesn't do it right away, so it's an intermittent problem. The best kind. *cracks knuckles* Edit: Fixed the bug. Prior to working on lil embedded widgets I was spoiled. I had numerous ways to do forensics on my running code, not the least of which was a debugger. I don't typically have a debugger anymore, and while it's possible to use debug probes with embedded gear they're usually so slow that I want to get out and push. Now since I don't have one, I've been forced to think more clearly about how my code runs and what it's doing at runtime at any given point. One day a guy told me GFX was failing after a couple of days when writing text. I immediately narrowed it mentally to three places within a labyrinth of code, with a most likely culprit that turned out to be the thing. I knew it because it smelled like heap frag and I was right. That's just one example. The opener of this post is another, assuming I'm right about it (I am) A few years ago I wouldn't have been able to do that. I'm super glad for these new abilities. It feels a bit like a superpower.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I had been programming for 5 years before I even heard of a debugger. Early debugging was reading core dumps (can you think how many pages they would take now), and stepping through the code by putting the processor in single-step mode and reading the lights on the console in binary to see what was happening. The only input devices were punched cards and console switches. The outputs were lights on the console, punched cards, and a line printer.
-
I had been programming for 5 years before I even heard of a debugger. Early debugging was reading core dumps (can you think how many pages they would take now), and stepping through the code by putting the processor in single-step mode and reading the lights on the console in binary to see what was happening. The only input devices were punched cards and console switches. The outputs were lights on the console, punched cards, and a line printer.
Yeah, I started coding without debuggers too. The difference is my code. In 1986 I was writing little, relatively simple applications. A checkbook balancer. Some stick figure animations. A few games. Stuff like that. I didn't really need a debugger. My code and data typically had to fit in 64KB. That's not the case now, even on embedded. It's far more difficult to conjure a working mental model of my modern code at runtime, even if it is written better, and more properly organized. The reason is simple complexity. Getting good at building and then traipsing through my mental model of my modern code at runtime is what I'm getting at.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I found a bug in my UIX library having to do with DMA and multiple transfer buffers. It only reproduces on one platform. I've narrowed it to a specific process, but I still don't know why it halts. It doesn't do it right away, so it's an intermittent problem. The best kind. *cracks knuckles* Edit: Fixed the bug. Prior to working on lil embedded widgets I was spoiled. I had numerous ways to do forensics on my running code, not the least of which was a debugger. I don't typically have a debugger anymore, and while it's possible to use debug probes with embedded gear they're usually so slow that I want to get out and push. Now since I don't have one, I've been forced to think more clearly about how my code runs and what it's doing at runtime at any given point. One day a guy told me GFX was failing after a couple of days when writing text. I immediately narrowed it mentally to three places within a labyrinth of code, with a most likely culprit that turned out to be the thing. I knew it because it smelled like heap frag and I was right. That's just one example. The opener of this post is another, assuming I'm right about it (I am) A few years ago I wouldn't have been able to do that. I'm super glad for these new abilities. It feels a bit like a superpower.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I would hate this. It would probably be good for me. I lean heavy on the whole fast build and see if it goes and correct what doesn't. I'm sure some could watch a recording and think it spaghetti chucking. Intellisense has gotten progressively worse with the verbosity of its descriptions because of the brigade against all code comments (maybe especially the XML ones). So you get method definitions from nugets where even if it's clear how you should call something, exactly what's going to happen when you do is a scientific endeavor of experimentation. Maybe it's exactly spaghetti chucking, but what other way is there to decode these black boxes?