On Sun, Jul 06, 2014 at 12:23:11PM -0400, David T. Lewis wrote:
> On Sun, Jul 06, 2014 at 10:34:15AM +0200, Nicolas Cellier wrote:
> > 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.
> > 
> 
> Yes, it is definite a problem in the Squeak trunk image.
> 
> 
> > 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
> > on:from:to:
> 
> I can not confirm this. I have an image in which I can reliably reproduce the
> failure in writing the MCZ to a file. I tried reverting the methods that were
> introduced in Collections-eem.567 and I am still getting the same failure.
> 
> Dave

Oops, I spoke too soon. Indeed the problem appears as of Collections-eem.567,
and does not appear in Collections-nice.566.

So I am confirming Nicolas' observations ... now to find the bug :)

Dave



> 
> 
> 
> > 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
> > souffle)
> > 
> > Nicolas
> 
> > 
>