Hi Levente, On Thu, Dec 8, 2011 at 5:44 PM, Levente Uzonyi <[email protected]> wrote:
> On Thu, 8 Dec 2011, Martin Dias wrote: > > On Thu, Dec 8, 2011 at 2:50 PM, Sven Van Caekenberghe <[email protected]> >> wrote: >> >> >>> On 08 Dec 2011, at 18:43, Martin Dias wrote: >>> >>> I think the problem is that this method supposes n >= 1: >>>> >>> >>> Yeah, that is why I propose a guard, maybe in this method >>> >>> n = 0 ifTrue: [ ^ buffer] >>> >>> >> thanks, it fixes the issue (inserted at the beginning of InflateStream>> >> next:into:startingAt:). >> >> The same issue should happen sending >> InflateStream>>readInto:**startingAt:count: >> >> I guess we should add some tests in CompressionTests package. I can do it >> on a couple of days. >> > > Yeah, that "fixes" the issue, but why didn't it fail before the "fix", > when there was only one string written and read? ;) > I don't understand what you mean. But I found something strange when debugging, maybe it's the heisenbug you mentioned before: | aStream zipStream | aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextPut: 5. zipStream close. aStream close. aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. self halt. zipStream next inspect. zipStream close. aStream close. When the #halt happens, I just press "Proceed". One hopes that #next answers 5 but not nil as it actually answers. Do you have a link to the mentioned heisenbug description? Martín > > > Levente > > > >> >> >> but I have no time to analyze the consequences/implications. >>> >>> Sven >>> >>> >>> >>> >>> >> >
