Packaging the programming tools

stéphane ducasse ducasse at
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 (!):

sounds exciting....
> [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
> [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:
> [300k]

Ok so you already did it ;). So I would suggest that we only use this  
one. :)

> 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:
> [32MB]
> and contains a few more (already unloaded) packages and fixes going  
> back to the original 3.8 versions from
> Cheers,
>   - Andreas

More information about the Packages mailing list