2.5 image/changes problem

agree at carltonfields.com agree at carltonfields.com
Wed Oct 13 17:51:38 UTC 1999


I note once more, with interest, that this problem seems to recur with cloying frequency.

Why don't we simply compress the changes file (and sources), and store the compressed data in the IMAGE with code for decompression and deletion of the image information when Squeak first starts up on that image?  Squeak would then restore the files in the proper format always, and we don't need to repeat the instructions about setting compression and decompression parameters of applications.

[It has also been suggested that the changes and sources files might be "easily" restructured to begin with some binary data "magic words," stored perhaps transparently in a Squeak comment or the like, so that it would not appear to a simple-minded program to be a "mere" text file.]

The present gzip stream decompression code is IMHO, probably too slow to make practical its use for decompressing the megafiles that Sources and changes have become, but I see two reasonable ways to go:  (1) perhaps adequate compression of the text can be accomplished with the usual "simple" tricks or, (2) we might pluginize (or make into numbered primitives) the guts of the gzip stream code and incorporate the compiled plugin code into each interpreter, as we presently do with the sound stuff.  

Although this second approach may seem annoyingly like what was done with Java, placing a compression technology into the "system" qua system, it might well be useful to have cross-platform, readily accessible and relatively fast compression/decompression facilities built-in?  Perhaps this might make some information, such as the ImageSegments, tighter and less disk-intensive?  Or perhaps an optional slow-load, low-disk-space version of same?  Again, we would need to make the decompression very fast, but hey, that's what primitives are for.

I was messing with code to do this last time we had discussed an "auto-install" facility, but abandoned that work when the majority seemed more interested in approaching this with a combined image/interpreter system.  I still like the idea of a machine-independent cross-platform auto-install of the text files, which system would not require platform-specific tricks, and see that there may be room for both approaches in the long haul.

Anyway, there's my 2 cents, for what its worth.

> -----Original Message-----
> From: MIME :kbrown at tnc.com > Sent: Wednesday, October 13, 1999 1:04 PM
> To: squeak at cs.uiuc.edu
> Subject: Re: 2.5 image/changes problem
> > > On my Mac I recently started having intermittent problems > with decoding Stuffit .hqx files where it reported a corrupt > .sit file after the .hqx file was successfully decoded. It > turned out that upgrading to Stuffit Expander 5.1.3 made the > problems go away (Expander cross platform preference is set > to 'Never convert text files to Mac format'). Anarchie seems > to do a good job of downloading the files in binary mode, > however make sure that the Internet Config file mapping entry > for .hqx files is correct (type TEXT, creator SITx) so the > file opens with Stuffit Expander after Anarchie downloads.
>     Ken G. Brown
> > > >I have never had this problem before. I download the > self-extracting
> > >archive for the Mac so I don't have to do anything but let it run.
> > >Everything is just perfect except...
> > > > 





More information about the Squeak-dev mailing list