Packaging the programming tools
ducasse at iam.unibe.ch
Mon Jul 18 17:49:11 UTC 2005
On 18 juil. 05, at 4:17, Andreas Raab wrote:
> Folks -
> I've been working on detangling the current tool set from the rest
> of the system since I wanted to be able to replace the current tool
> set with something more appropriate for Tweak. It turns out that
> with a little restructuring of responsibilities this isn't all that
> hard and so I'm happy to announce the probably only Squeak image in
> the world which has no programming tools whatsoever (!):
> http://www.impara.de/~andreas/iSqueak/3.8/NoTools.zip [6.3MB]
> If you grab this image you will find that you won't be able to open
> a browser, a change sorter, workspace etc. not even a debugger[*1]
> simply because none of these tools are present.
> [*1] Try browsing the sender of some message or a class - you will
> very quickly notice why I don't like the usage of "AppRegistry
> default" since it raises completely needless errors when for
> example trying to browse a class -- compare this with the notifier
> you get when trying to browse a selector which uses ToolSet's
> interpretation of "proper" AppRegistry behavior.
So we will have to fix that.
I'm back in town and I will sync with the guys here to have a
roadmap. I would like to see how we can push your ToolBuilder changes.
> However, since this is not very interesting, you can just load the
> standard tools package from
> http://www.impara.de/~andreas/iSqueak/3.8/Tools-ar.17.mcz [450k]
> install and use it. And when you're tired of it, simply unload it
> from Monticello[*]. Needless to say, the tools package does not
> leave any obsolete classes or undeclared references behind, it
> comes and goes cleanly.
This is cool.
> [*] After unloading execute the code in the left hand panel - it
> turns out that #unload is not executed when unloading packages from
> Monticello (we *really* need to fix this!) probably because the
> #unload method is removed before the class.
> But wait, there is more! Since the current tools package is
> somewhat messy and depends directly on Morphic and MVC I decided to
> build an alternative which exclusively depends on ToolBuilder. It's
> called the "PlusTools" (all the names have a "Plus" in the name,
> e.g., FileListPlus, TestRunnerPlus, ClassBrowserPlus,
> DebuggerPlus...) and loadable from:
> http://www.impara.de/~andreas/iSqueak/3.8/PlusTools-ar.16.mcz [300k]
Ok so you already did it ;). So I would suggest that we only use this
> And of course, you can load and unload both tool sets at the same
> time if you'd like to. Note that the point of this exercise is not
> only to be able to replace the tools for Tweak - it is equally to
> show that a Squeak system can easily come without *any* specific
> tool support, squeakmap, even monticello (I only left MC in the
> image because you'd have to load it anyway to get to the tool sets)
> just as long as you have a way of loading code (e.g., compiler and
> change management). Therefore there is really no need whatsoever to
> put all of the programming tools into a "basic" Squeak image.
I thought that there was a version of MC UI was relying on ToolBuilder.
> And finally, the PlusTools should be helpful for further detangling
> work as they depend on ToolBuilder and not on Morphic or MVC (there
> might still be a few remnants but that's easily fixable).
> For those of you interested, here are the major changes that I did
> to make the above possible:
> * Refactoring of ChangeSet and ChangeSorter - all of the actual
> change set related stuff had to be moved out of ChangeSorter and
> ChangeSet itself had to be moved over to the System package and out
> of Tools.
I do not have the time right now to look at it but did you change the
notification mechanism? I'm curious to see how the decoupling offered
by the notification mechanism helps.
> * Moving of the breakpoint, tallying, file contents browser (diff
> etc) out of the Tools (right now all of these are in System)
> * Introduced FileServiceRegistry to avoid abuse of FileList
> * Introduced ToolSet AppRegistry to support various tool sets
> I also had to do some significant shuffling around between packages
> to get everything in order and (un-)loadable but most of these
> changes were non-invasive. If you are interested the full
> repository is also available at:
> and contains a few more (already unloaded) packages and fixes going
> back to the original 3.8 versions from SqF.org.
> - Andreas
More information about the Packages