[squeak-dev] Re: [Vm-dev] Bug in writing compressed stream when saving an mcz (was: New Cog VMs available...)

David T. Lewis lewis at mail.msen.com
Mon Jul 21 12:18:34 UTC 2014

On Mon, Jul 21, 2014 at 11:32:42AM +0200, Bert Freudenberg wrote:
> On 19.07.2014, at 02:15, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > On Fri, Jul 18, 2014 at 4:20 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > On Fri, Jul 18, 2014 at 02:06:18PM -0700, Eliot Miranda wrote:
> > >
> > > I think we have to accept that the fix to on:from:to: means that exsting
> > > VMs are broken.  Certainly the ZipPlugin (InflatePlugin & DeflatePlugin)'s
> > > dependency on WriteStream and ReadStream inst size is restrictive.  I'd
> > > rather lift the restriction and use new VMs than live with the restriction
> > > long-term.
> > 
> > Is this fix is of sufficient urgency to justify asking all Squeak trunk users
> > to replace their VMs? Is there any less disruptive way to address the issue?
> > I don't know the answers, just asking.
> > 
> > Well, I've fixed the VM (commit to appear shortly) and much prefer having a fixed plugin.  The alternatives are
> > a) having some horrible hack in the image to store initialPositionOrNil out of streams
> > b) living with on:from:to: being broken
> > 
> > Since VMs can be fixed it seems to me that the best solution is to build new VMs.  That's the solution I'm following anyway.
> But ... breaking old images is *not* a good idea.

Right. That was the point of my original question. Maybe this belongs on squeak-dev
rather than vm-dev, but what I meant to ask was:

1) In Collections-eem.567 we have a fix for ([Read|Write]Stream on:...from:...to:...)
contents. Is there any other way to address that problem that does *not* add
an instance variable that affects the plugins? (probably the answer is no, but
it's worth asking)

2) Given that the fix in Collections-eem.567 causes problems both in the
image and in the plugins, does that change carry it's weight? What practical
problem does it solve, and is solving that problem worth the various side effects?

> IMHO we should name the fixed plugin ZipPlugin2. The new image with changed
> ivar offsets will use that plugin. Old images with the original object layout
> will use the original.

The plugin changes are backward compatible, so it is not necessary to rename
the plugin.


More information about the Vm-dev mailing list