A gameplan embryo! (was Re: Squeak Starter)

danielv at netvision.net.il danielv at netvision.net.il
Fri Oct 18 12:50:17 UTC 2002


goran.hultgren at bluefish.se wrote:
> 
> > > > 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.

I know you are trying to explain how they should work. I'm just saying
that talking about complex, interacting, unimplemented, and incompletely
specified features is probably not useful, and acting as if they have
certain qualities or will soon is distracting us from reality. One
aspect of which is -

Nobody is using DMs, and nobody can, so they currently solve no
problems. 

> Ok, so we sort of stop the 3.3a branch and start moving selected stuff
> from there onto the current 3.2 instead?
Well, yes. And focus on letting people put out code based on an image
they understand.
 
> > 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"?
Something related. It's doesn't automatically split the image, but it
does let you answer some important questions about it.

"Can I unload this set of classes now? if not, why not?"
"What classes does Object currently depende on (even indirectly) and
how?"

When Object doesn't indirectly depend on Celeste, we can make Celeste
unload cleanly.

So it should let anyone pick a package in the image, and say "I want to
take over maintanance of that as free package that can be loaded or
unloaded. What do I need to do to cut it's ties to the Image?"

Is that description clear? 

[Game plan for going forward]
Yup. 

Maybe a good thing for SqueakMap to do would be to keep versions of all
of it's cards. This doesn't still give us versions of the packages,
because SM is a catalog, not a repository, but that would make it
*possible* for people to load specific versions of packages, if the
maintainer also keeps the files separate somehow. For example, I could
release versions of the RB as 
RB.1.st.gz
RB.2.st.gz
...

and increment the card versions accordingly, and then people could load
whatever version they want. This is important for configurations to
work, because otherwise, you can only use the development version, which
might not be stable enough.

Does this make any sense?

> regards, Göran

Daniel Vainsencher



More information about the Squeak-dev mailing list