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
|