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



> 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

>