Dependencies, Squeak Code Control

Avi Bryant avi at beta4.com
Tue Nov 18 23:24:48 UTC 2003


On Nov 18, 2003, at 1:57 PM, Colin Putney wrote:

> 1) Package dependencies. If I'm loading a package that depends on 
> another package, I want SqueakMap to notice this and load that package 
> for me as well. There are lots of ways to do this, of course, but I 
> think Göran's plan is excellent. The only thing missing is code.

That works well for SqueakMap, but what about when you're loading 
development code from a repository?  Should there be some 
bundling/dependency system there?  If I'm branching a bunch of packages 
at once, how do I mark that a certain set of versions goes together, in 
the version control system?
Or should every development team be running a SqueakMap server, and all 
the tagging/dependency information goes there?  Colin, should our 
"development stream" server be an SM instance?

> 2) Version history queries. Monticello needs better facilities for 
> answering questions like "what is the history of this method?", 
> "What's the latest version of this package?", "What are the senders of 
> this message, now and in the past?" Avi and I are working on this now.

At least, we're working on the middle question.  The first and last 
question would require (I think) repositories that stored versions in 
some better indexed form than .mcz files.  A GOODS-based repository may 
be in order, or maybe a PostgresRepository, but I don't know of anyone 
working on this (volunteers welcomed).

> 3) More explicit packaging in the image. We need to make the 
> development tools - browsers, message lists, change sorters and so on 
> - package aware. We also need to refactor parts of the kernel, 
> compiler etc, to make it easier to make it easier to load and unload 
> packages safely. The guys at SCG are probably the experts here, since 
> Roel's Notifications work is key to this, and they've already 
> discovered the hard way where the issues are in hacking on the 
> SystemBrowser. Ned and Daniel have also done some useful work in this 
> area. Nevertheless, this is probably the area that's the least "sorted 
> out" in terms of how to proceed.

I've been thinking about this some, and before we make the tools 
package-aware, I think we need to come up with a protocol by which the 
entities (classes, methods, and so on) can be made package-aware - or, 
more precisely, context-aware.  As well as #methods and #subclasses, I 
want to have something along the lines of #methodsInContext: and 
#subclassesInContext:, where the context may be Smalltalk (ie, the 
entire image), may be a particular package, may be some group of 
packages (or bundle, or whatever), and so on.  And I want this same 
protocol to be implemented both by Monticello's "dead" declarations and 
by the live objects in the image.  Or maybe these shouldn't be methods 
on Class, but on some external Mirror, I don't know.

Once we figure out this model, the tools themselves should be easy.

Avi



More information about the Squeak-dev mailing list