Bug Fix

I think I may have submitted my first bug fix. Or I just added to the noise level.
In Pharo, the TestRunner tool allows for determining how much coverage your test suite has over some package. Basically, it records all the messages sent during execution of the tests, and compares this against all the messages implemented in that package. My personal goal is 100% test coverage, though that sometimes leads to a few seemingly meaningless tests.

Development on Pharo-2.0 is moving to restructure the basic tools and frameworks in the system, which has the unfortunate side effect of sometimes breaking the tools you are using. Something happened in the past week that broke the Run Coverage tool in TestRunner. I noticed that I could patch around it by undoing a few small changes that the developers made in the system dictionary (basically, the method for finding which tool handles which class of tasks). This worked for a few days, until the tool I moved it back to was removed from the system by another patch.

I spent a couple days working in Pharo-1.4 because of this, which is stable and unlikely to have more new problems. Today, I updated a clean 2.0 image and just let the debugger show me what was wrong. Four new methods later, I was able to get a coverage list running. The Smalltalk debugger is such a useful tool!

Rather than simply emitting a message, it gives you the entire call stack. Each stack frame is live, that is, you can look at all the passed arguments, change them, inspect them, send methods to them, etc. All of the errors I received were ultimately of the form X does not understand Y (trying to call a function on an object that doesn't implement it). Rewinding 2 stack frames showed me the call site in TestRunner's collectResultsFor method, and in the debugger, I could click on the does not understand error, click create, tell it which class in the hierarchy of X to implement the message in, choose a protocol, write the (very short) code to handle the method, and restart the stack frame where the call failed, and try over.

Honestly, as a very inexperienced programmer, to have a system so immediately supportive as to allow fixing a problem with the system tools in a few button clicks, test it, confirm that it's working, and move on with my life, is a huge relief. Having a system so understandable that it takes about 10 minutes and 10 lines of code to fix a problem in the IDE is exhilarating.

The next process involved feeding this back to the developer team. In Pharo, issues are tracked on google code, and if you've opened a ticket, you can automatically document your patch. In Nautilus, I clicked create a slice, which asked me for an issue number (mine was 5839), then automatically inserted the issue description in the slice. Submitting to PharoInbox was one more click away, and if what I did was useful, that's a bug fix!