[squeak-dev] Condensing sources for a new release

Eliot Miranda eliot.miranda at gmail.com
Mon Feb 10 16:48:49 UTC 2020


Hi David, Hi Release Manager, Hi All,

On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <lewis at mail.msen.com> wrote:

> On Thu, Feb 06, 2020 at 05:02:36PM -0800, Eliot Miranda wrote:
> > Hi Tim,
> >
> > > On Feb 6, 2020, at 1:05 PM, tim Rowledge <tim at rowledge.org> wrote:
> > >
> > > ???At yesterday's board meeting we discussed the possibility of
> condensing the sources file for the new release; we don't do this often,
> and usually for major releases but it after all five years since the last
> time and the changes file has got quite large.
> > >
> > > So as an experiment we thought of
> > > - take a 5.2-19299 image (ie just the start of post-5.2)
> > > - condense the sources
> > > - update to latest (19335)
> > > ... hopefully resulting in a small changes file of everything changed
> from 5.2 to now.
> > >
> > > Happily this process worked without any hitches on my iMac and I now
> have:
> > > image -> 44.4MB
> > > changes -> 144KB
> > > sources -> 50MB
> > >
> > > The sources file has grown rather a lot from 35.2 to 50MB. I had
> thought that might be due to adding the EToys stuff but that was there in
> the 5.0 release anyway. The image has also grown from 5.0 (35.6MB) to 44.4.
> That's quite a lot.
> > >
> > > Now an interesting question is the most effective way to make a 32bit
> image release to use the same source file. Let's see if condensing sources
> & updating a 18229-32bit image results in an image that can use the same
> sources file...
> >
> > The ???right??? way, until we have written a 64-bit to 32-bit image
> converter, is to do the release in a 32-bit image and then run it through
> the 32-bit yo 64-bit converter yo derive the 64-bit pre-release image,
> which should be started up and snapshotted before being used as a release
> image.
> >
>
> Yes that is the right way to do it. And if it is a lot of work and/or
> confusion, then the best thing for 5.3 is don't worry about condensing
> the sources for this release. It's definitely a "nice to have" and not
> a requirement for Squeak 5.3.
>
> > Another way is to do a release on the 32-bit image and then just slam in
> the right source pointers.  Dumping the source pointers from the 64-bit
> image is a trivial undertaking.  Reading in the dumped source pointers and
> applying them should be only slightly less trivial.
> >
> > But given that soon macs that run 32-bit images (on spur vms) won???t be
> available I guess I really should try and write the converter 64-bit to
> 32-bit converter.
> >
>
> A 64-bit to 32-bit image converter would be a very good thing to have
> in our toolkit :-)
>

I got this working this morning.  See Cog-eem.398.  So to use,
- clone or update an opensmalltalk-vm repository
- cd to the image directory and create a VMMaker image via either
buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh
- run a converter, e.g.
    Spur32to64BitImageConverter new bootstrapImage: 'trunk6'.
 (produces trunk6-64.image & trunk6-64.changes)
    Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'.
(produces trunk6-64-32.image & trunk6-64-32.changes)

Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on
my 2.9GHz Core i9 MacBook Pro


So let's try releasing by converting the 64-bit image into a 32-bit one.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200210/63f8ead0/attachment.html>


More information about the Squeak-dev mailing list