[squeak-dev] Procedure for condensing sources

Levente Uzonyi leves at elte.hu
Sat Feb 19 20:24:17 UTC 2011


On Sat, 19 Feb 2011, Chris Muller wrote:

>>> Well, will there be a very much code removed?  I'm hard-pressed to
>>> imagine we would save even 1MB of disk-space.  But yet at the cost of
>>> losing a continuity-of-record about Squeak; e.g., "what happened
>>> between 4.2 and 4.3".  Each release should be presented in terms of
>>> its delta to the prior release.  Isn't that a bad deal or am I missing
>>> something?
>>
>> I'm not sure about what your goal is with that delta. Condensing the sources
>> is not bad, but IMHO it's late. It can be done now, but it's better before
>> releasing the image (it's not specific to 4.3).
>
> My goal is elegance, continuity, and useful information (deltas).
>
> It's elegant, for Squeak 4.2, to consist of:  a V41 sources file +
> image + changes file.  This is the traditional essence of Smalltalk
> systems; sources+changes, and one which provides a "continuity" from
> one released image to the next.
>
> If we compress right before each release (instead of right after),
> then wouldn't we just be deploying a "snapshot" of the state of the
> system as of a particular moment in time.  There would be no

Okay, I see your point now. You want to keep all the intermediate versions 
in the changes file. In that case, condensing before release won't work.

> "connection" to the prior release at all in terms of what maturities
> the system made.  And only because we wanted to save a couple MB of
> disk space?

I didn't mention disk space in this thread so far, but here's what I 
think about it: Disk space is cheap. If someone is short on disk space 
(e.g. embedded systems), then s/he can use compressed source files or use 
the image with no source files at all.


Levente

>
> I guess I should ask you to clarify your question you posed to me too;
> what is your goal / reasoning.  You said, "it's late" and it's "better
> before releasing the image".  May I ask why?
>
> I don't think disk-space is a good answer because someone interested
> in a, as-small-as-possible is not going to use a stock Squeak release
> anyway; they're going to have to do a unloading / condensing /
> compression steps.
>
> Regards,
>  Chris
>


More information about the Squeak-dev mailing list