<div dir="ltr"><div>One problem with this <span style="font-family:arial,sans-serif;font-size:13px">Help-Squeak-Project-kfr.18 </span>mcz:</div>The massive postscript<span style="font-family:arial,sans-serif;font-size:13px"> is trunkated</span><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">4294967295 4294967295 42...etc...!</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br>
</font></div><div><font face="arial, sans-serif">Karl</font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 13, 2014 at 3:55 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">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">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">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">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>
</div></div>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>
Dave<br>
<br>
<br>
</blockquote></div><br></div>