Smalltalk › Squeak › Squeak - Dev

Procedure for condensing sources

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Chris Muller-3

Procedure for condensing sources

>> We should also condense the sources file and remove deprecated
>> methods. We're early in the cycle, this is a good time to "break"
>> code still using 3.9Deprecated methods.
>
> IMHO condensing should be done before the release. It's not possible to tell
> a 4.2 image to use a different sources file without changing it.
> For 4.3 it doesn't worth condensing now, because we will do further changes,
> which would generate cruft in the file (compared to condensing before the
> release).

Each release should be able to present it's deltas to the prior
release. That is not cruft.

Levente Uzonyi-2

Re: Procedure for condensing sources

On Sat, 12 Feb 2011, Chris Muller wrote:

>>> We should also condense the sources file and remove deprecated
>>> methods. We're early in the cycle, this is a good time to "break"
>>> code still using 3.9Deprecated methods.
>>
>> IMHO condensing should be done before the release. It's not possible to tell
>> a 4.2 image to use a different sources file without changing it.
>> For 4.3 it doesn't worth condensing now, because we will do further changes,
>> which would generate cruft in the file (compared to condensing before the
>> release).
>
> Each release should be able to present it's deltas to the prior
> release. That is not cruft.
>

The cruft would appear in the 4.3 release if we would condense the sources
now and ship 4.3 with these condensed sources. If we wait till the release
of 4.3, then the condensed sources will be smaller, because those won't
include the code removed during the developement of 4.3.

Levente

>

Chris Muller-3

Re: Procedure for condensing sources

>> Each release should be able to present it's deltas to the prior
>> release. That is not cruft.
>
> The cruft would appear in the 4.3 release if we would condense the sources
> now and ship 4.3 with these condensed sources. If we wait till the release
> of 4.3, then the condensed sources will be smaller, because those won't
> include the code removed during the developement of 4.3.

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?

Besides, if someone wanted to save that last MB of disk-space, a
simple "condensing" script could be included in 4.3 as a user-script,
along with other "slimming" things like unloading extra packages, for
those who care about sparing every last MB.

- Chris

David T. Lewis

Re: Procedure for condensing sources

On Wed, Feb 16, 2011 at 10:41:33AM -0600, Chris Muller wrote:

> >> Each release should be able to present it's deltas to the prior
> >> release. ??That is not cruft.
> >
> > The cruft would appear in the 4.3 release if we would condense the sources
> > now and ship 4.3 with these condensed sources. If we wait till the release
> > of 4.3, then the condensed sources will be smaller, because those won't
> > include the code removed during the developement of 4.3.
>
> 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?
>
> Besides, if someone wanted to save that last MB of disk-space, a
> simple "condensing" script could be included in 4.3 as a user-script,
> along with other "slimming" things like unloading extra packages, for
> those who care about sparing every last MB.

If disk space is the concern, then just ship with a compressed
sources file. It works fine and saves disk space.

Dave

Levente Uzonyi-2

Re: Procedure for condensing sources

In reply to this post by Chris Muller-3

On Wed, 16 Feb 2011, Chris Muller wrote:

>>> Each release should be able to present it's deltas to the prior
>>> release. That is not cruft.
>>
>> The cruft would appear in the 4.3 release if we would condense the sources
>> now and ship 4.3 with these condensed sources. If we wait till the release
>> of 4.3, then the condensed sources will be smaller, because those won't
>> include the code removed during the developement of 4.3.
>
> 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).
If you just want the changes, between 4.1 and 4.2, then the update process
in the image can produce changesets somehow. Though that won't be useful
to load them into the image, because Squeak's MC has a well defined load
order, while changesets don't.

Levente

>
> Besides, if someone wanted to save that last MB of disk-space, a
> simple "condensing" script could be included in 4.3 as a user-script,
> along with other "slimming" things like unloading extra packages, for
> those who care about sparing every last MB.
>
> - Chris
>

Chris Muller-4

Re: Procedure for condensing sources

>> 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
"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 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

Levente Uzonyi-2

Re: Procedure for condensing sources

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
>

Chris Muller-4

Re: Procedure for condensing sources

> 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.

We probably don't need _all_ intermediate versions including ones that
were discarded. I think just the current and the one that was in the
prior released image should be sufficient for each release.

I think this can be accomplished by, just before releasing, say, 4.3,
we take the 4.2 image, compress/fold its 4.1.changes into a new
V42.sources + empty changes file for 4.3. Then launch the 4.2 image
and "update squeak". It would be a big merge, but I think we would
end up with two entries in method-history for for the methods that
changed between 4.2 and 4.3, and just one in method-history for every
other (legacy) method that didn't change between 4.2 and 4.3.

> 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.

I totally agree.

- Chris

Eliot Miranda-2

Re: Procedure for condensing sources

In reply to this post by Chris Muller-4

On Sat, Feb 19, 2011 at 11:46 AM, Chris Muller <[hidden email]> 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).

Elegance pushes for an empty or absent changes file. Continuity and useful information push for a sources file that contains older versions. I have code that condenses the changes while eliminating intermediate versions that are not ancestors of the current version. See directAncestryOfVersions: in the attached changes. How about we adapt this code to function for generating a new sources file, and generate a SqueakV4.2.sources?

VisualWorks has always generated a new sources file for every release so that the changes file is absent (the empty file serves no purpose). But I also agree that old versions are great to have. These two are not antithetical.

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
"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 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

condenseChanges.st (12K) Download Attachment

Levente Uzonyi-2

Re: Procedure for condensing sources

On Sat, 19 Feb 2011, Eliot Miranda wrote:

> On Sat, Feb 19, 2011 at 11:46 AM, Chris Muller <[hidden email]> 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).
>>
>
> Elegance pushes for an empty or absent changes file. Continuity and useful
> information push for a sources file that contains older versions. I have
> code that condenses the changes while eliminating intermediate versions that
> are not ancestors of the current version. See directAncestryOfVersions: in
> the attached changes. How about we adapt this code to function for
> generating a new sources file, and generate a SqueakV4.2.sources?

Andreas added SmalltalkImage >> #appendChangesTo: during the developement
of 4.1 which can create a new sources file (or modify the existing one),
which will contain the contents of the original sources file + the latest
version of all changes from the changes file. The contents of the changes
file will be empty.

Levente

>
> VisualWorks has always generated a new sources file for every release so
> that the changes file is absent (the empty file serves no purpose). But I
> also agree that old versions are great to have. These two are not
> antithetical.
>
>
>>
>> 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
>> "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 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
>>
>>
>

Bert Freudenberg

Re: Procedure for condensing sources

On 19.02.2011, at 18:04, Levente Uzonyi wrote:

> On Sat, 19 Feb 2011, Eliot Miranda wrote:
>
>> On Sat, Feb 19, 2011 at 11:46 AM, Chris Muller <[hidden email]> wrote:
>>> My goal is elegance, continuity, and useful information (deltas).
>>>
>>
>> Elegance pushes for an empty or absent changes file. Continuity and useful
>> information push for a sources file that contains older versions. I have
>> code that condenses the changes while eliminating intermediate versions that
>> are not ancestors of the current version. See directAncestryOfVersions: in
>> the attached changes. How about we adapt this code to function for
>> generating a new sources file, and generate a SqueakV4.2.sources?
>
> Andreas added SmalltalkImage >> #appendChangesTo: during the developement of 4.1 which can create a new sources file (or modify the existing one), which will contain the contents of the original sources file + the latest version of all changes from the changes file. The contents of the changes file will be empty.
>
>
> Levente

Yep. That still is rather elegant, IMHO.

- Bert -