[squeak-dev] Re: [Vm-dev] Bug in writing compressed stream when
saving an mcz (was: New Cog VMs available...)
nicolas.cellier.aka.nice at gmail.com
Sun Jul 6 08:34:15 UTC 2014
2014-07-04 0:47 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:
> 2014-07-04 0:09 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>> On Thu, Jul 3, 2014 at 12:33 PM, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>> The bug is repeatable, i simply have to execute this snippet with my
>>> test file:
>>> (FileStream fileNamed: 'snapshot.bin') binary contentsOfEntireFile
>>> asString zipped.
>>> The file is too big for an attachment here - 7.3 Mbytes - or 1.7 Mbytes
>>> gzipped by external tool.
>>> If someone can suggest an upload site, or want it by mail, just ask.
>> You're welcome to put it on ftp.mirandanamda.org, cogftpuser, pw cogging
>> with 0's & 1's.
> done, pollution of your site engaged...
> Thanks Eliot!
I inquired a bit more about this bug.
An important clue is that it does not happen in Pharo3.0!
But Pharo3.0 did not fundamentally change compression
(except some FileSystem related changes, separation of CRC stuff in another
package, some other cosmetic changes like replacing some self assert: ...
by [...] assert and a potential bug in
DeflateStream>>nextPutAll:startingAt: introduced by CamilleTeruel).
Squeak behavior is presumably not due to a Compression change.
Neither is it a VM problem, the bugs still shows up when running the Squeak
image with Pharo VM.
So the difference lies somewhere else: in our beloved Stream.
I remembered a recent change of Eliot related to handling of Stream created
with on:from:to: (Collections-eem.567).
Reverting those changes just make the snippet pass!
Ah ah! At the time, i found the change of Eliot quite minimal and nice.
But I wish I had time to analyze this small innocent change deeper.
Indeed, I remembered I previously broke my teeth on this one 2 years or so
ago, and preferred to adopt another strategy: avoid using on:from:to: and
ReadWriteStream as much as possible.
Why? because when analyzing the usage of inst.var. in Stream hierarchy, it
gave me headaches, some subclass are just ignoring superclass variables, or
worse are bending the semantics of superclass variables.
I came to the conclusion that I could not decently master a change of
Now we can have a new pass on how fragile the Stream hierarchy has become
along the years... (In French I would resume current status as: a bout de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev