On Thu, Dec 8, 2011 at 5:44 PM, Levente Uzonyi <leves@elte.hu> wrote:

On Thu, 8 Dec 2011, Martin Dias wrote:

On Thu, Dec 8, 2011 at 2:50 PM, Sven Van Caekenberghe <sven@beta9.be> 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