How to generate identically image file after snapshots

John M McIntosh johnmci at smalltalkconsulting.com
Tue Jul 31 07:19:47 UTC 2007


mmm, I wonder how well this would work since when you load an image  
we first figure out how big it is then allocate memory for it, load it,
then swizzle all the memory references by +/- an offset which is  
calculated base on the offset used when the image was saved, versus
the offset given by the memory location allocated.

Now some operating system might give you the same virtual memory  
address when you use the same VM on the same operating system.
In this case we don't have to swizzle the references.  Currrent (I  
believe), certainly past versions of OSX would do this.

However in cases where the operating system does not give the same  
memory address, and I'll note the operating system might give you
a random address each time on purpose for security reasons, why all  
the memory references become different at swizzle tie.  Of course if  
this is the case, then on your next save,
all your memory reference values will be different than the last  
save.  Needless to say this would greatly affect how xdelta thinks  
your images are the save/different.

On Jul 30, 2007, at 9:49 PM, subbukk wrote:

> On Tuesday 31 July 2007 7:32 am, John M McIntosh wrote:
>> If you have some desire to make duplicate images look at
>>
>> primitiveSnapshot
>>
>> and consider cloning that to perform the writeImageFile() twice using
>> different image names.
> It would be simpler to copy image files after they are written. But  
> I don't
> this the issue was to copy image files locally. The original poster  
> wanted to
> update third-party images by shipping fileIns to a reference image  
> instead of
> the whole image itself. The poser, then, is how to verify that the  
> resulting
> image is same as intended.
>
> I would simply use xdelta (see xdelta.org) for situations like  
> this. E.g.
>
>  xdelta delta ref.image thirdparty.image thirdparty.xd
> and ship thirdparty.xd
>  xdelta patch thirdparty.xd ref.image thirdparty.image
>
> The downside is xdelta is a memory hungry utility. How big is the  
> image?
> Regards .. Subbu
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===





More information about the Squeak-dev mailing list