Squeak 4.2 released

By: on February 12, 2011

Squeak 4.2 has finally shipped!

It continues the improvements started in 4.0 and 4.1, with the trunk model revitalising the community: a small group of dedicated, frequent committers provide the main thrust of development, supported by a very simple and lightweight way of providing bugfixes, enhancements, and the like.

Squeak 4.2 also ships with the Cog VM, Eliot Miranda’s much speedier virtual machine – most people report a 2x to 10x speed increase over the older VM.

Unfortunately for me, there’s a well-known issue with Squeak’s UUID plugin on 64-bit Linux machines, so if you’re running one of those, do yourself a favour and delete the UUIDPlugin: rm coglinux/lib/squeak/3.9-7/UUIDPlugin.

I’ve submitted a number of bugfixes to Squeak 4.2, so this seems like a good point to reflect on how I fix bugs in Squeak.

Squeak has what’s called a trunk model: a small number of “blessed” committers apply bugfixes or enhancements to a central place, in the form of a Monticello repository.

Anyone may submit bugfixes, enhancements, or whatever they like to the Inbox, another Monticello repository. Commits are automatically announced to squeak-dev (as are commits to Trunk). The mails allow the community a handy feature-specific mail thread for comments, suggestions, and the like.

Squeak uses Monticello as its version control system. It needs lots more work before it’s as easy to use as git or Mercurial [1]. The most glaring missing feature is that I often want to commit some of my work. I’m working on one thing, maybe see a bug that’s trivial to fix, and I want to put that fix (and the test that exposes the original bug!) in a separate commit. There is currently no simple way to do that in Monticello. [2]

I don’t usually run into this problem when bugfixing trunk, but I frequently run into this issue when working on my own packages.

Most of the time, the bug’s reproducible, and I can write a test demonstrating the bug. Important, because then I know when I’ve fixed the bug! The core packages (those loaded by default in a Squeak image) usually have their tests in separate packages: Network, and Network-Test, for instance. That means that usually I submit two commits to the Inbox. (This is another thing I’d like to see in Monticello: those commits belong together and, in git, they’d form part of the same commit.)

Sometimes, it’s difficult to write a test for the bug, especially when it’s a user interface bug. In that case, I trigger the behaviour, and work from inside the debugger. If the bug’s something like a MessageNotUnderstood error – you tried to send an object a message that’s not in its protocol, or you have a nil reference, and you see “UndefinedObject>>messageNotUnderstood:” in the stack trace – then I work from inside the debugger – trawl around, find out what’s wrong, try fix it. Other times, I might have to insert “self halt” - Smalltalk’s version of a breakpoint is naturally enough a message send. Either way, I’ll end up fixing the bug from within the debugger. This is completely normal behaviour in Smalltalk by the way – everything’s an object, everything’s live, and you can freely edit even the debugger itself from within the debugger. [3]

I also sanity-check myself: I take my clean image, and load my changes. First, the changes must load cleanly. Second, they must pass their own tests. Lastly, they shouldn’t break any existing tests, which I check by running all loaded tests.

After that, it’s up to the community, and especially the hard-working committers, to review the fix and accept or reject it.

Happy hacking!

[1] Monticello’s otherwise pretty easy to use, and does most of what I need.

[2] But there could be: a new version’s made up of a collection of definitions. By default, saving a new version of a package collects all definitions in that package, but I don’t see why one couldn’t save a subset of those definitions, selectable through some kind of UI. Sounds like an interesting experiment to perform.

[3] Very, very carefully: if you make a mistake, you’re toast, because of course triggering an error in the debugger opens up a debugger which triggers the error which …


Post a comment

Your email address will not be published.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>