A gameplan embryo! (was Re: Squeak Starter)

squeak-dev at lists.squeakfoundation.org squeak-dev at lists.squeakfoundation.org
Fri Oct 18 12:10:06 UTC 2002


(Note: I started digging in 3.3a yesterday and was aiming at looking at
that DM problem you mentioned, but I never got that far, we will see...)

danielv at netvision.net.il wrote:
> goran.hultgren at bluefish.se wrote:
> > Anyway, I agree - "the CODE is NOT as simple as can be". I have also
> > seen parts of it that easily could be refactored - but that is to be
> > expected I think, this is kindof hard stuff. What I think I wrote about
> > is the model with Modules/DeltaModules.
> 
> The main point is not that the code could be made simpler - it is that
> it is very complex. If I toss a fridge from the second floor for you to
> catch, the point is not that it has food in it that could emptied first.
> The point is you're dead! That's where Squeak 3.3 is - wearing a fridge
> for a hat and going nowhere.

Very colorful metaphor. And currently you seem to be right. But what do
we do?

> > > 2. Many of the things explained are not implemented, so the theories
> > > given about what the semantics of various parts should be can't be
> > > tested. In short, it's incomplete. 
> > 
> > True again. But we all know that, right?
> Again, the point is not that it's not quite done and could be. What I
> wanted to say is - don't sell me something that doesn't exist.
> DeltaModules cannot be used in the ways described now, and when I did
> use them, it didn't look like it's just around the corner, either.

You reacted against me describing DMs as capable of these things when in
reality they are not?
I thought I had sprinkled enough of those (not implemented yet) around
my explanations of the DMs.
It all started with me trying to explain how it is *meant* to work
(because AFAICT Stephane didn't understand it) - not how it works today.

> > True. We do have a problem. But what should we do?
> > I think we should dig in and try to work through it. Do you instead
> > propose to dump it all and start from fresh?
> 
> I propose to be honest to ourselves. Nobody is saying he has a vision
> for 3.3a as a viable development version. So why are we sitting here
> stewing in our juices? is it a kind of sport?

He, well, the thread started with explanations about how it is meant to
work and has now progressed into "what should we do".
I want us as a community to decide on a course. And we need to discuss
it in order to do that.

So let's keep that focus - "What should we do?".

> [What are you saying -]
> > b) The code is a "bad start" and should be dumped?
> 
> The modules code (as well as other sources) should be studied carefully
> by people interested in small, simple projects, that incrementally and
> completely add to 3.2 a single, factored piece of what modules promised.

Ok, so we sort of stop the 3.3a branch and start moving selected stuff
from there onto the current 3.2 instead?

> 1. You're doing the "project namespace" more usefully than module paths
> did them. 

Well, I am not sure. But perhaps. SqueakMap simply demands a unique
package name. Period. :-)
The hierarchy is instead present in the category tree which (when I
think of it) perhaps functions as the Module namespace hierarchy for
finding stuff by "category".

> 2. Avi is doing the "manage large chunks of code" in a simpler, more
> usable way than modules and DMs did (I have actually released the RB
> both ways. Modules took a few days work, using ModuleFiler took about 2
> hours - though I admit to having learned between them). 

Yes, DVS is definitely a good step for Squeak (haven't tried it but I
have read the tutorial etc).

> 3. I have a project on hold to allow detecting cyclic dependencies.
> Right now it is less complete than henrik's (not a subset - it does
> something else), but it won't require you to fileout in an incompatible
> format, and it is easier to retarget to different definitions of
> modules. 

What problem does it solve? (Excuse me for being ignorant) Is it the
"split up the current image problem"?

> I wouldn't have done my own work before studying Henrik's, and Joseph's,
> and other people can benefit the same way.
> 
> Anyway, I think we're already en route to get most of the benefits that
> people will actually use as it is. We just need unmoor ourselves from
> this rut, and go back to sailing the seas free.

:-) There are perhaps 2 things we should do:

1. An inventory of the Modules code. What good stuff is in there and
could we break it out?
2. An inventory of what we have/are missing in 3.2 land to solve the
similar problems.

Avi's first post had a little list on #2, it would be interesting to
think a bit about what more we would need.
Off the top of my head:

1. Some form of dependencies and some model for resolving conflicts etc.
The info could easily be added to SqueakMap but the tricky part is how
to resolve conflicts etc.
2. Uninstallation of packages might be less important, but upgrade of
them is important and DVS has "smarts" for that I think.
3. Image reduction. Breaking out pieces into packages.

Lets for a second play with the thought of going the lightweight route
and "dumping" Modules. I am just rambling now and I am not sure this is
the way to go, but lets go anyway:

1. Push SqueakMap into 3.2. We are soon there.
2. Evolve SqueakMap further and add dependencies between packages
(specific versions pointed out as prereqs). This would also require
other changes in SqueakMap - for example, currently it only holds
information on the newest released version of a package.
3. Start cutting out stuff from the image perhaps using Daniel's tools
or whatever and publishing them on squeakfoundation ftp server as .cs.gz
files. Celeste, Scamper and other apps go first. Complement this with
some equivalence to "configuration maps" - descriptions of what packages
to install into an image. Perhaps these are simply "pseudo packages"
like Daniel has demonstrated already with SqueakMap - in effect a
.cs/.st that when filed in simply uses SqueakMap to download/install
other packages.
4. Add smarts like in DVS for ChangeSets so that we at least can upgrade
safely using ChangeSets. Uninstallation is still ignored because it
might not be that important if we instead make rebuilding images easy!
5. Add "update streams" to SqueakMap packages - a queue of .cs.gzs, but
"per package". Very important for distributed development.
6. Add some conflict detection between ChangeSets/.st files. That
couldn't be too hard. Let ChangeSets "act as the DMs".

Ok, given the above we can continue with:

1. Breaking down the image.
2. Easily finding and installing packages.
3. Build images instead of stripping them.
4. Easily upgrade a package to a new version.
5. Distribute the harvesting/maintainer role onto the packages.

Ok, what is missing then?

- No namespaces. But again, the usefulness of namespaces in itself is
questionable. And it couldn't be too hard to break out from Modules and
add separately (at least it feels that way).
- No uninstall of packages. But since we have image building and
"configurations" of images then you would just build a new one.
- Not as sophisticated storage format (I think) but perhaps unimportant.

More? Not sure. Some obvious advantages:

- Backwards compatible. It's easy to "comply" as a developer - you can
still publish code as simple downloads of .st/.cs files using your good
old tools. The ChangeSet is still the "engine" in all this.
- It should be easy to add all this to the current 3.2 - not as updates,
but as a simple package to load from within 3.2 (when we have stuffed
SqueakMap in there).

> > regards, Göran
> 
> friend, not foe  :-)

Definitely friend here too.

> Daniel Vainsencher

regards, Göran



More information about the Squeak-dev mailing list