> On 07.02.2020, at 03:03, 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 :-)

Or, you know, making the VMs understand both formats ;)

Best regards
	-Tobias