[Modules] Braindump!

Hannes Hirzel hirzel at spw.unizh.ch
Sat Feb 16 09:07:42 UTC 2002


Hi Göran


On Thu, 14 Feb 2002, you wrote:
 
> (I have also felt a bit guilty for not helping out Henrik with the modules. :-))
Don't do that. You are contributing as a volunteer. Time is not so
important, but quality of the contributions.

I considered the brief intro to Modules and DeltaModules you recently sent
to the list very helpful. I put it on
http://minnow.cc.gatech.edu/squeak/2247

Perhaps you could elaborate on that. And check and enhance the other
Modules related pages Henrik is doing.

I think Squeakers would be interested to know what the Modules solution
chosen consists of, what is implemented and what's not implemented.

Many of them don't mind not having a GUI do deal with Modules, but it is
then necessary to have a 'text interface', i.e. examples of sequences of
commands which explain how to use it.
 
Classes that need additional comments are
- DeltaClass
- Module (elaboration)
- ModuleExplorer
- ModuleParameter
- TransitionalSmalltalkModule

If you have knowledge about the responsibilites and interaction of the
objecs under 'Language-Modules' you could "brain-dump" that would be
great.



> The package system of Debian is quite advanced and proven (as some of us have stated before on
> this list) and should be able to provide us with some hints to what we should do with our Modules
> system in Squeak.
[snip]
> 
> Dependencies
> ============
> 
> Debian: Each package (specific version) explicitly names what packages it is dependent on
> (specific versions).
> 
> Squeak: This is the same as the list of "external modules" of a module. It is important to note
> that whenever we talk about a module we mean "a specific version" of that module. And the
> references to external modules are thus also references to "specific versions".
> 
> 
> Streams/releases
> ================
> 
> Debian: Debian has three "fronts" similar to our alpha, gamma and "offical". They are called
> "stable", "testing" and "unstable". Just to make life a little bit more fun the specific versions
> of these fronts are given names. The current "stable" is called Potato (after Mr Potatohead in a
> certain film...). "testing" is called Woody and is going to become the official "stable" soon (or
> something). "unstable" is called "Sid". It goes something like this: Everything is happening in
> "unstable" and it can surely go boom. When stuff seems to be working those new versions of
> packages are released into "testing". This means that "testing" is pretty up to date but not rock
> solid. Then after a proven time in "testing" without any bugs reported it goes into "stable".
> 
> Squeak: Well, currently we have something similar - but we lack the "module" granularity which has
> made it problematic to maintain the gamma and the offical relase ("stable" and "testing").
> Eventuall we all end up in the alpha stream! :-) This is not so good, but I think it would be much
> simpler if we where dealing with new versions of modules instead of with small changesets.
> 
> 
> Conflicts
> =========
> 
> Debian: Each package (specific version) can name explicitly other packages (specific versions)
> that it is known to not be able to coexist with.
> 
> Squeak: ?
> 
> 
> Basic metainfo
> ==============
> 
> Debian: I don't have it in my head, but each package has a set of basic meta information like
> author, homepage, short description, long description etc. Take a look at
> http://packages.debian.org/stable for examples.
> 
> Squeak: ?. We should also define such a minimal set of metainfo that each module should have. 
> 
> 
> Cache of packages
> =================
> 
> Debian: All packages are downloaded and cached on the machine.
> 
> Squeak: Henrik talks about a local cache of modules so I think this is accounted for. I am not
> sure though.
> 
> 
> Cached database of package info
> ===============================
> 
> Debian: "Apt-get update" fetches compressed indices (if they are not up to date) of all available
> packages from each one of a set of "sources" that you list in a "sources" file. This way you have
> locally a database of all "known" packages to your machine given the set of source locations
> (ftp/http/cdrom etc).
> 
> Squeak: Hmmm. There have been thoughts about it:
> http://minnow.cc.gatech.edu/squeak/2049
> We need something like this I think. And, to be concrete:
> We should define an offical list of "top servers" (but you could add your own of course, compare
> to Debian's "sources.list") that together form the top of the complete virtual Squeak module
> hierarchy. But since we still want anyone to be able to setup an ftp-server for their own modules
> I think we could introduce some form of "forwarder" file in order to make the virtual hierarchy
> distributed.
> 
> An example: Let's say I have a module #(People gh sqcvs). One way would be to store my stuff on
> one of the top servers (probably at SqF). But I would also like to just stick a "forwarder" there
> at "gh" which says that, "Hey, gh is not here. He has his modules over there:
> ftp://ftp.bluefish.se/gh/". Then if someone tries to load #(People gh sqcvs) Squeak would:
> 
> 1. If no cached info is available at all: Visit the "top servers" one by one and load their
> index-files (just like "apt-get update" does in Debian) and store this in a local database
> structure.
> 
> 2. Check the database for the module #(People gh sqcvs). If not found, back one step up and look
> for #(People gh). This would resolve to an url, say: "ftp://modules.sqf.org/People/gh". Then we
> load "ftp://modules.sqf.org/People/gh" and voilá! We find a forwarder to
> "ftp://ftp.bluefish.se/gh/". We go there instead and since it is a new location we load the
> index-file (this could of course be done differently, but perhaps it would be good to demand that
> there always is an up-to-date index-file available on each "location"). Then we can finally, given
> the new index-file with info on all modules available there, resolve sqcvs to
> "ftp://ftp.bluefish.se/gh/sqcvs" and off we go to download the actual module.
> 
> The scheme above would mean that we can, by placing a forwarder at a "parent" server - make a link
> to another ftp/http server on another machine and still maintain the virtual hierarchy of modules.
> 
> Ok, braindump ends here. Hit me.
>
Well why?

I consider it a good idea to rely on a working, working concept ;-). 
For the meta-information on Modules: that's OK, but I would include
'current maintainer'. The problem is that one want's to give credit to the
original author but avoid that other people feel discouraged to maintain a
Module. In Squeak many enhancements and goodies are broken and sometimes
it would need just minor fixes, but people feel reluctant to do it because
it seems to be the original author's job. An alternative would be to 
have a field of historical notes.


I understand that at this time two subsystems VMConstruction and Ballon3D
are unloadable
ModuleInstaller unload: Module @  #(Squeak VMConstruction)
ModuleInstaller unload: Module @  #(Squeak Media Balloon3D)

This is described on
http://minnow.cc.gatech.edu/squeak/2257
A guide for refactoring the image

But that page does not yet give enough information on how to refactor
the image so that more modules are unloadable. I imagine that this 
is an area where more people could contribute - refactoring the 
Squeak image. If you or anybody else could give more information that
would be great! Actually Henrik Gedenryd wrote a remark recently that
he had hoped that the communitiy contributes more to the Modules 
implementation. I consider part of this problem is the fact that 
people do not actually know how to contribute. So a rewrite of the 
analysis documents produced last autumn (at various places)
into design documents and the description of what is already 
implemented would help considerably.
This sounds like a big task and it probably is. 
However even small steps are still steps forward.

Regards
Hannes Hirzel  





More information about the Squeak-dev mailing list