Debugging
I pointed to a Python debugger post from Ted Leung this morning (here). In the comments, I was asked to post an image of a Smalltalk debugger in the middle of a sort. So, I slapped this code down in a workspace:
| items |
items := RSSFeedManager default getAllMyFeeds first items.
items asSortedCollection: [:a :b | a title <= b title].
Then I hit the "debug it" menu option, and got the following debugger:
Now, what does that stuff mean? Well, the top pane is the stack - the reason you see "UndefinedObject>>unboundMethod in there is that I executed the code out of a workspace - in other words, the code is not attached to any particular class. Incidentally, the VW Web Toolkit uses this feature to execute SSP code on a web page. Moving on, the code pane is below the context stack, and there's a toolbar at the top (with tooltips). Below the code pane are basic inspectors - for instance variables on the left, temps and method arguments on the right. Double clicking on any of them will yield a full inspector. You can move up and down the stack, inspecting things, executing code (possibly into new debuggers), and re-compile arbitrary methods - rewinding the stack to that point. Very cool stuff - and it's why you don't tend to see Smalltalkers getting excited about "modern" debuggers in other languages with (subsets) of this capability...
Comments
Actually...
[Avi Bryant] June 19, 2004 1:55:31.122
The debugger Ted is pointing to, and the Java debugger it's based on, *is* worth getting excited about. They're debuggers with "step backwards" buttons: they record the entire program state as it's executing (presumably much slower than usual) and then let you go forward and back in time at will. That's actually quite cool. I can imagine a Smalltalk tool that let you capture and replay this info during the execution of a particular block you were interested in (like the profilers we have today), but there isn't one yet.
Right...
[Ian Bicking] June 20, 2004 3:10:27.041
This kind of debugger is common in many languages -- though maybe first in Smalltalk, and still very nicely implemented there. But it only captures the stack at the time of exception -- not all stacks that have existed, or all historical states of the objects in the system.
A common issue I have is when I find "corrupt" data somewhere. Maybe that's a None (or nil) in a list where I wasn't expecting it. How did it get there? That debugger won't show me -- but the omnicient debugger Ted was talking about would be able to show me.
Re: Debugging
[David Buck] June 20, 2004 8:12:27.566
Comment on Debugging by David Buck
I've used Method Wrappers to find out why some data becomes corrupt more easily than with a debugger that can back up.
Method Wrappers allow me to execute code on entry and exit of any methods I choose. In my case, I tell it to do this on all methods in my application. The entry and exit methods run a boolean block and capture the stack the first time the block returns false. For the block, you provide one that says something like: [MyObject someValue ~= 5]]. Then, the first time this condition fails, I get a stack trace.