<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-13 16:22 GMT+02:00 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Sun, Jul 13, 2014 at 09:55:41AM -0400, David T. Lewis wrote:<br>
> On Sun, Jul 06, 2014 at 12:47:25PM -0400, David T. Lewis wrote:<br>
> > On Sun, Jul 06, 2014 at 12:23:11PM -0400, David T. Lewis wrote:<br>
> > > On Sun, Jul 06, 2014 at 10:34:15AM +0200, Nicolas Cellier wrote:<br>
> > > > 2014-07-04 0:47 GMT+02:00 Nicolas Cellier <<br>
> > > > <a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:<br>
> > > ><br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > 2014-07-04 0:09 GMT+02:00 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>>:<br>
> > > > ><br>
> > > > ><br>
> > > > >><br>
> > > > >><br>
> > > > >> On Thu, Jul 3, 2014 at 12:33 PM, Nicolas Cellier <<br>
> > > > >> <a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
> > > > >><br>
> > > > >>> The bug is repeatable, i simply have to execute this snippet with my<br>
> > > > >>> test file:<br>
> > > > >>><br>
> > > > >>> (FileStream fileNamed: 'snapshot.bin') binary contentsOfEntireFile<br>
> > > > >>> asString zipped.<br>
> > > > >>><br>
> > > > >>> The file is too big for an attachment here - 7.3 Mbytes - or 1.7 Mbytes<br>
> > > > >>> gzipped by external tool.<br>
> > > > >>> If someone can suggest an upload site, or want it by mail, just ask.<br>
> > > > >>><br>
> > > > >><br>
> > > > >> You're welcome to put it on <a href="http://ftp.mirandanamda.org" target="_blank">ftp.mirandanamda.org</a>, cogftpuser, pw cogging<br>
> > > > >> with 0's & 1's.<br>
> > > > >><br>
> > > > >><br>
> > > > > done, pollution of your site engaged...<br>
> > > > > Thanks Eliot!<br>
> > > > ><br>
> > > > ><br>
> > > > >><br>
> > > > I inquired a bit more about this bug.<br>
> > > > An important clue is that it does not happen in Pharo3.0!<br>
> > > ><br>
> > > > But Pharo3.0 did not fundamentally change compression<br>
> > > > (except some FileSystem related changes, separation of CRC stuff in another<br>
> > > > package, some other cosmetic changes like replacing some self assert: ...<br>
> > > > by [...] assert and a potential bug in<br>
> > > > DeflateStream>>nextPutAll:startingAt: introduced by CamilleTeruel).<br>
> > > > Squeak behavior is presumably not due to a Compression change.<br>
> > > ><br>
> > > > Neither is it a VM problem, the bugs still shows up when running the Squeak<br>
> > > > image with Pharo VM.<br>
> > > ><br>
> > ><br>
> > > Yes, it is definite a problem in the Squeak trunk image.<br>
> > ><br>
> > ><br>
> > > > So the difference lies somewhere else: in our beloved Stream.<br>
> > > > I remembered a recent change of Eliot related to handling of Stream created<br>
> > > > with on:from:to: (Collections-eem.567).<br>
> > > > Reverting those changes just make the snippet pass!<br>
> > > ><br>
> > > > Ah ah! At the time, i found the change of Eliot quite minimal and nice.<br>
> > > > But I wish I had time to analyze this small innocent change deeper.<br>
> > > > Indeed, I remembered I previously broke my teeth on this one 2 years or so<br>
> > > > ago, and preferred to adopt another strategy: avoid using on:from:to: and<br>
> > > > ReadWriteStream as much as possible.<br>
> > > > Why? because when analyzing the usage of inst.var. in Stream hierarchy, it<br>
> > > > gave me headaches, some subclass are just ignoring superclass variables, or<br>
> > > > worse are bending the semantics of superclass variables.<br>
> > > > I came to the conclusion that I could not decently master a change of<br>
> > > > on:from:to:<br>
> > ><br>
> > > I can not confirm this. I have an image in which I can reliably reproduce the<br>
> > > failure in writing the MCZ to a file. I tried reverting the methods that were<br>
> > > introduced in Collections-eem.567 and I am still getting the same failure.<br>
> > ><br>
> > > Dave<br>
> ><br>
> > Oops, I spoke too soon. Indeed the problem appears as of Collections-eem.567,<br>
> > and does not appear in Collections-nice.566.<br>
> ><br>
> > So I am confirming Nicolas' observations ... now to find the bug :)<br>
> ><br>
> > Dave<br>
> ><br>
><br>
> This seems to be a rather tricky bug, and I don't think any of us knows the<br>
> cause right now. In case anyone else wants to have a look at it, here is a<br>
> recipe for reproducing the bug in a clean 4.5 image:<br>
><br>
> - Start with a clean Squeak 4.5 image in and empty working directory.<br>
> <a href="ftp://ftp.squeak.org/4.5/Squeak4.5-13680.zip" target="_blank">ftp://ftp.squeak.org/4.5/Squeak4.5-13680.zip</a><br>
><br>
> - Open the image, do not update it.<br>
><br>
> - Open an MC browser and add the <a href="http://source.squeak.org/trunk" target="_blank">http://source.squeak.org/trunk</a> repository for the Help-Squeak-Project package and Collections package.<br>
><br>
> - Load Help-Squeak-Project-kfr.18 from trunk.<br>
><br>
> - Load Collections-eem.567 from trunk.<br>
><br>
> - Open a browser on class SqueakToolsDebuggerHelp, and delete the class side method #showDebuggerMenuForm.<br>
><br>
> - Remove the <a href="http://source.squeak.org/trunk" target="_blank">http://source.squeak.org/trunk</a> repository form the Help-Squeak-Project package in the MC browser.<br>
><br>
> - Highlight your package-cache repository and try to save Help-Squeak-project to the package-cache repository.<br>
><br>
> - Enter author initials 'dtl'.<br>
><br>
> - For the package comment, enter 'Remove unreferenced method'.<br>
><br>
> - Package save will fail part way through saving the MCZ.<br>
><br>
> - To reproduce the failure in this image, do the following in a workspace:<br>
><br>
> mcv := MCVersion allInstances detect: [:e | e name = 'a MCVersion(Help-Squeak-Project-dtl.19)'].<br>
> [f := FileStream fileNamed: 'junk.mcz'.<br>
> mcv fileOutOn: f]<br>
> ensure: [f close].<br>
><br>
<br>
</div></div>In addition to the above recipe, here are some other observations:<br>
<br>
- Reverting from Collections-eem.567 to Collections-nice.566 makes the<br>
problem go away, but ONLY if the DeflatePlugin is active.<br>
<br>
- The failure appears while executing the fallback code for #primitiveDeflateBlock<br>
in ZipWriteStream>>deflateBlock:chainLength:goodMatch:<br>
<br>
- If this primitive is deactivate by commenting out the<br>
<primitive: 'primitiveDeflateBlock' module: 'ZipPlugin'> in<br>
ZipWriteStream>>deflateBlock:chainLength:goodMatch: then the problem will<br>
occur regardless of which version of Collections is loaded.<br>
<br>
- When Collections-eem.567 is loaded, the primitive will fail on the 22nd<br>
call to #deflateBlock:chainLength:goodMatch: and a debugger appears during<br>
execution of the fallback code.<br>
<br>
- When Collections-nice.566 is loaded, the primitive does not fail on the 22nd<br>
call to #deflateBlock:chainLength:goodMatch:, the fallback code is never run,<br>
and no error appears.<br>
<br>
- When Collections-nice.566 is loaded and the primitive is disabled to force<br>
use of the fallback code, the error appears on on the 22nd call to<br>
#deflateBlock:chainLength:goodMatch: in exactlly the same place as when<br>
Collections-eem.567 is loaded.<br>
<br>
- If I inspect the ZipWriteStream at the failure point (when the debugger pops<br>
up after the problem), I see no obvious difference in the state of the stream<br>
between the Collections-eem.567 case versus the Collections-nice.566 with<br>
primitive disabled case.<br>
<br>
Dave<br>
<br>
<br></blockquote><div>Very good mining work!<br></div><div>When I hear Stream, I think fluid...<br></div><div>But these snags make it so viscous, it's like our Stream is going to freeze soon.<br></div><div>Or is it more than frozen? The vein you're after sounds as hard as diamond, we gonna need a sharp peak pickaxe.<br>
</div></div><br></div></div>