<div dir="ltr"><div><div class="gmail_extra"><br><div class="gmail_quote">2014-07-04 0:47 GMT+02:00 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-04 0:09 GMT+02:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<div class="">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Thu, Jul 3, 2014 at 12:33 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>The bug is repeatable, i simply have to execute this snippet with my test file:<br>
<br>(FileStream fileNamed: 'snapshot.bin') binary contentsOfEntireFile asString zipped.<br><br></div>The file is too big for an attachment here - 7.3 Mbytes - or 1.7 Mbytes gzipped by external tool.<br>
</div>If someone can suggest an upload site, or want it by mail, just ask.<br></div></blockquote><div><br></div></div><div>You're welcome to put it on <a href="http://ftp.mirandanamda.org" target="_blank">ftp.mirandanamda.org</a>, cogftpuser, pw cogging with 0's & 1's. </div>
<div><br></div></div></div></div></blockquote><div><br></div></div><div>done, pollution of your site engaged...<br></div><div>Thanks Eliot!<br></div><div class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div></div></div></blockquote><div><br></div><div>I inquired a bit more about this bug.<br></div><div>An important clue is that it does not happen in Pharo3.0!<br><br></div><div>But Pharo3.0 did not fundamentally change compression<br>
(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).<br>
</div><div>Squeak behavior is presumably not due to a Compression change.<br></div><div><br>Neither is it a VM problem, the bugs still shows up when running the Squeak image with Pharo VM.<br></div><div><br></div><div>So the difference lies somewhere else: in our beloved Stream.<br>
</div><div>I remembered a recent change of Eliot related to handling of Stream created with on:from:to: (Collections-eem.567).<br></div><div>Reverting those changes just make the snippet pass!<br><br></div><div>Ah ah! At the time, i found the change of Eliot quite minimal and nice.<br>
</div><div>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 ago, and preferred to adopt another strategy: avoid using on:from:to: and ReadWriteStream as much as possible.<br>
</div><div>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.<br>
</div><div>I came to the conclusion that I could not decently master a change of on:from:to:<br></div><div>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)<br>
</div><div><br></div><div>Nicolas</div></div></div></div></div>