> On Mar 9, 2017, at 12:50 PM, stepharong <[email protected]> wrote: > > The idea is that we want to see how we cn improve our debugging arsenal. > So it is important that your scenario give use some hints. > It is difficult to convey what we are really looking for :)
I think one of the biggest improvements for the debugger would be for it to know the difference between my code and the system code (or not my code). Almost always, I don’t want to step through any system code while debugging my code. I’m expert enough to generally know when I should use into, over, or through, but it is a real pain to keep moving the mouse from one button to another. Often I end up hitting the wrong button by accident and have to restart the debugging process. I want a step until you come back to my code button. I think such a change would help newbies too. I don’t know how much time I spent debugging though methods in OrderedCollection when I was learning Smalltalk. In over 25 years, I still haven’t found a bug while stepping through OrderedCollection>>do:. Another item that I’ve thought about but have never implemented is a learning debugger. Often the hard things to debug are inside loops where you have to continuously switch between over, into and through. For example, I may know that a method is a lazy accessor and not want to step into it. However, I may want to step into the next message. A learning debugger could keep track of what I did before and do it as default the next time. Or, maybe there could be a little switch on every message send that said if you wanted over, into or through. There could also be a keep going option for all expressions. For example, I generally don’t want to step through a bunch of literal assignments (e.g., “x := 4”). Such a change to the debugger would help eliminate pair debugging sessions whose conversations go like: “over, over, into, over, into…”. Such conversations don’t find bugs, but are necessary to get to the location where the bug may exist. One thing that you may want in your debugging arsenal is lightweight classes to implement per object breakpoints/watchpoints. For example, you may want to set a breakpoint in a text widget. However, since that text widget is used all over, it would crash the system if you just set a breakpoint in the text widget class. Instead you can create a lightweight class with the breakpoint and change the particular text widget to use the lightweight class. This way it can trigger the breakpoint without crashing the image. I don’t use lightweight classes often, but in certain cases they are really handy (and almost necessary). John Brant
