Hi Martin,

there are a lot of objects (like, for example subinstances of ContextPart)  
allocated and deallocated on which you do not have much control.

One corner from which this could be started is to consider enumerating (in  
two sister .images) all the objects you want to deploy. If that fails to  
produce comparable objects (for any reason, for example if you cannot  
order/compare object identities other than by hash identity and the latter  
is assigned by the VM and not by you) then, hrm, it fails.

But if not then you could trace out all the objects you want (thereby  
disacrding all the unwanted) and the resulting (two sister) .image files  
then have the same contents byte by byte, because you fix the object's  
position in the files. I've done that with other images and non-Smalltalk  
interpreters.

Having said that, your project doesn't look to be easy.

/Klaus

On Mon, 30 Jul 2007 17:31:43 +0200, Martin wrote:

> Hi All,
>
> We have tried to produce the same (bit identically) image file after two
> consecutive snapshots. We start from a base image then, fileIn several
> files into it and finally, we just SmalltalkImage current snapshot: true
> andQuit: true. We need this to verify the image file generated by a
> third-party with a checksum by executing a script.
> After trying several ways to get it (even by scripting the fileIn process
> and the snapshot), we found that the image files have, beside the
> timestamp differences, thousands of other differences and sometimes the
> snapshots have also size differeces.
> We supose that this kind of issues may occur due to the GC activity.
> Are this issues from the way GC process is changing dynamically the  
> memory
> bytes? There is a way to inhibite this activity?
> Attached are the scripts we use to produce the image files.
>
> Many thanks in advance,
> Martin Troielli