Right, so to correct the details

 - start from an 18299 image
 - set update url to trunk
 - condenseSources
 - update to 19355
 - condenseChanges

... for both a 32 bit and 64 bit image.

64bit
image -> 46.6MB, down from 49.6
changes -> 3.3MB, down from 14.4MB
sources -> 47.4MB, up from 35.2MB

32bit
image -> 38.1MB, down from 41.3MB
changes -> 3.3MB, down from 14.4MB
sources 47.4MB, up from 35.2MB

However, life is a touch more complicated because I notice that the file sizes are not identical
changes 
64 bit (3302430) 32bit (3307752)
sources
64bit (47374222) 32bit (47375119)

It is clear that the files differ significantly, though mostly in the order that methods get written out. The different sizes are a puzzle but without the methods in the same order it is a bit difficult to work out exactly what is really different. I'm going to guess right now that it has something to do with the hashing differing slightly when building the list of methods in, for example, ClassDescription>>#moveChangesTo: and the classes/traits in SmalltalkImage>>#allClassesAndTraitsDo: .... and yes, that seems to be the case. 

If we eval - 
`String streamContents:[:s|
		Smalltalk
		allClassesAndTraitsDo: [:classOrTrait | s nextPutAll: classOrTrait name; cr]]`
in a 32bit image we get a quite different list to in a 64bit image. Changing to -
`String streamContents: [:s|
(Smalltalk allClassesAndTraits sorted: [:a :b | a name < b name]) do:[:nm| s nextPutAll: nm name; cr] ]`
provides us with the identical results we need. At last!

If I edit the condenseChanges method to do this sorting, then we almost get identical changes files.  THe differences are a bit strange:

 - in the 32bit file, we have two copies of EFontBDFFontReaderForRanges>>#readCharactersInRanges2:storeInto: one after the other and then two copies of EFontBDFFontReaderForRanges>>#readRangesForSimplifiedChinese:overrideWith:otherRanges:additionalOverrideRange: - this despite there only being one copy of each in the image?

 - we have different versions of SMSqueakMap>>#loadFullFrom: - in the 32bit system we have a newer version than in the 64bit (my 1/18/2019 15:55  version as opposed to goran's 5/5/2006 02:07). Both 'original' 18229 images have the older method. Looks like for some reason my SMBase-tpr.141.mcz exists only in the squeak52 repository and never made it to the trunk repository! So sometihng faintly odd must have happened somewhere. NO idea...

This is my solution so far - 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SourceCodeCondensing.1.cs
Type: application/octet-stream
Size: 3989 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200206/7c702918/attachment.obj>
-------------- next part --------------


And just to make life a bit more fun, attempting to catch the moving of #readCharactersInRanges2:storeInto: by sticking a halt in provides a very, very, broken debugger stack. Rather like the problems recently discussed. Basically bad enough that we really can't make this a release.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
If at first you don't succeed, destroy all evidence that you tried.