December 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] A possible bug in GZip streams

by Sven Van Caekenberghe

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] but I have no time to analyze the consequences/implications. Sven

Dec. 8, 2011

Re: [Pharo-project] A possible bug in GZip streams

by Martin Dias

Hi! > I guess you could add a guard for the #nextInto: message send in > GZipReadStream>>#nextString when the length is 0. But I haven't tried. > > Sven > > I think the problem is that this method supposes n >= 1: InflateStream>> next: n into: buffer startingAt: startIndex "Read n objects into the given collection. Return aCollection or a partial copy if less than n elements have been read." | c numRead count | numRead := 0. ["Force decompression if necessary" (c := self next) == nil ifTrue:[^buffer copyFrom: 1 to: startIndex+numRead-1]. "Store the first value which provoked decompression" buffer at: startIndex + numRead put: c. numRead := numRead + 1. "After collection has been filled copy as many objects as possible" count := (readLimit - position) min: (n - numRead). buffer replaceFrom: startIndex + numRead to: startIndex + numRead + count - 1 with: collection startingAt: position+1. position := position + count. numRead := numRead + count. numRead = n] whileFalse. ^buffer Martin

Dec. 8, 2011

Re: [Pharo-project] The tools are dreadfully slow in 1.4

by Igor Stasenko

On 8 December 2011 18:14, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > It feels worse than pre-cog ;-) > details, where the details... > -- > View this message in context: http://forum.world.st/The-tools-are-dreadfully-slow-in-1-4-tp4173491p417349… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Dec. 8, 2011

[Pharo-project] The tools are dreadfully slow in 1.4

by Sean P. DeNigris

It feels worse than pre-cog ;-) -- View this message in context: http://forum.world.st/The-tools-are-dreadfully-slow-in-1-4-tp4173491p417349… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 8, 2011

Re: [Pharo-project] A possible bug in GZip streams

by Levente Uzonyi

On Thu, 8 Dec 2011, Mariano Martinez Peck wrote: > no one? :( This case has at least 3 different bugs (in Squeak). One of them is a heisenbug. :) Levente > > On Tue, Dec 6, 2011 at 7:32 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > >> I forgot to say that I am working on a recent Pharo 1.3. >> >> And it is not only GZipWriteStream but also ZipWriteStream >> and ZLibWriteStream . >> >> MartÃn >> >> On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias(a)gmail.com> wrote: >> >>> Hi, >>> >>> I get a SubscriptOutOfBounds error when I evaluate: >>> >>> | aStream zipStream | >>> >>> aStream := ByteArray new writeStream binary. >>> zipStream := GZipWriteStream on: aStream. >>> zipStream nextStringPut: ''. >>> zipStream nextStringPut: ''. >>> zipStream close. >>> aStream close. >>> aStream := aStream contents readStream binary. >>> zipStream := GZipReadStream on: aStream. >>> zipStream nextString. >>> zipStream nextString. >>> zipStream close. >>> aStream close. >>> >>> The error doesn't happen when I put just one string (instead of two). >>> >>> Do you see something wrong in the code? Should I report a bug? >>> >>> Thanks, >>> MartÃn >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 8, 2011

Re: [Pharo-project] A possible bug in GZip streams

by Mariano Martinez Peck

On Thu, Dec 8, 2011 at 5:09 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > It is certainly a bug ;-) > > Strangely, non-empty strings work: > > Yes, in fact, we found that gzip was not working in some "random" cases and Martin could come to the gulty! > | aStream zipStream | > > aStream := ByteArray new writeStream binary. > zipStream := GZipWriteStream on: aStream. > zipStream nextStringPut: '123'. > zipStream nextStringPut: 'ABC'. > zipStream close. > aStream close. > > aStream := aStream contents readStream binary. > zipStream := GZipReadStream on: aStream. > zipStream nextString. > zipStream nextString. > zipStream close. > aStream close. > > I guess you could add a guard for the #nextInto: message send in > GZipReadStream>>#nextString when the length is 0. But I haven't tried. > > Ok, we will try. Thanks, we wanted to know whether we were doing something wrong or not. Don't you use this stream for Zinc as well ? > Sven > > On 08 Dec 2011, at 16:53, Mariano Martinez Peck wrote: > > > no one? :( > > > > On Tue, Dec 6, 2011 at 7:32 AM, Martin Dias <tinchodias(a)gmail.com> > wrote: > > I forgot to say that I am working on a recent Pharo 1.3. > > > > And it is not only GZipWriteStream but also ZipWriteStream and > ZLibWriteStream . > > > > MartÃn > > > > On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias(a)gmail.com> > wrote: > > Hi, > > > > I get a SubscriptOutOfBounds error when I evaluate: > > > > | aStream zipStream | > > > > aStream := ByteArray new writeStream binary. > > zipStream := GZipWriteStream on: aStream. > > zipStream nextStringPut: ''. > > zipStream nextStringPut: ''. > > zipStream close. > > aStream close. > > > > aStream := aStream contents readStream binary. > > zipStream := GZipReadStream on: aStream. > > zipStream nextString. > > zipStream nextString. > > zipStream close. > > aStream close. > > > > The error doesn't happen when I put just one string (instead of two). > > > > Do you see something wrong in the code? Should I report a bug? > > > > Thanks, > > MartÃn > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 8, 2011

Re: [Pharo-project] A possible bug in GZip streams

by Sven Van Caekenberghe

It is certainly a bug ;-) Strangely, non-empty strings work: | aStream zipStream | aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextStringPut: '123'. zipStream nextStringPut: 'ABC'. zipStream close. aStream close. aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. zipStream nextString. zipStream nextString. zipStream close. aStream close. I guess you could add a guard for the #nextInto: message send in GZipReadStream>>#nextString when the length is 0. But I haven't tried. Sven On 08 Dec 2011, at 16:53, Mariano Martinez Peck wrote: > no one? :( > > On Tue, Dec 6, 2011 at 7:32 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > I forgot to say that I am working on a recent Pharo 1.3. > > And it is not only GZipWriteStream but also ZipWriteStream and ZLibWriteStream . > > MartÃn > > On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi, > > I get a SubscriptOutOfBounds error when I evaluate: > > | aStream zipStream | > > aStream := ByteArray new writeStream binary. > zipStream := GZipWriteStream on: aStream. > zipStream nextStringPut: ''. > zipStream nextStringPut: ''. > zipStream close. > aStream close. > > aStream := aStream contents readStream binary. > zipStream := GZipReadStream on: aStream. > zipStream nextString. > zipStream nextString. > zipStream close. > aStream close. > > The error doesn't happen when I put just one string (instead of two). > > Do you see something wrong in the code? Should I report a bug? > > Thanks, > MartÃn > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 8, 2011

Re: [Pharo-project] A possible bug in GZip streams

by Mariano Martinez Peck

no one? :( On Tue, Dec 6, 2011 at 7:32 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > I forgot to say that I am working on a recent Pharo 1.3. > > And it is not only GZipWriteStream but also ZipWriteStream > and ZLibWriteStream . > > MartÃn > > On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > >> Hi, >> >> I get a SubscriptOutOfBounds error when I evaluate: >> >> | aStream zipStream | >> >> aStream := ByteArray new writeStream binary. >> zipStream := GZipWriteStream on: aStream. >> zipStream nextStringPut: ''. >> zipStream nextStringPut: ''. >> zipStream close. >> aStream close. >> aStream := aStream contents readStream binary. >> zipStream := GZipReadStream on: aStream. >> zipStream nextString. >> zipStream nextString. >> zipStream close. >> aStream close. >> >> The error doesn't happen when I put just one string (instead of two). >> >> Do you see something wrong in the code? Should I report a bug? >> >> Thanks, >> MartÃn >> > > -- Mariano http://marianopeck.wordpress.com

Dec. 8, 2011

Re: [Pharo-project] Debugger Not Feeling Well

by Sean P. DeNigris

Sean P. DeNigris wrote > > It's working again Um, I meant feeling better, but not exactly working ;-) The contextual info is not lined up with the selected code as you step through. For example, while stepping through the following: | candidates | candidates := self eligibleClasses select: [ :e | e category beginsWith: package ]. ^ candidates atRandom. When "atRandom" is selected, the block is displayed for "stack top". It's only when I press "Over" again that the candidates collection is "stack top", but by that point, the return is selected. I have to press "Over" three more times to return to the calling method. I'm also getting an intermittent "SubscriptOutOfBounds" error while working with the debugger, which sounds very familiar... Sean -- View this message in context: http://forum.world.st/Debugger-Not-Feeling-Well-tp4171698p4173033.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 8, 2011

Re: [Pharo-project] GUI Testing Library

by Sean P. DeNigris

Tudor Girba-2 wrote > > Would it be possible to simulate keys with modifiers without Keymapping > present? > I think I only used Keymapping for the modifier key syntax, but looking at its repository, the shortcuts are packaged separately. So you could try only loading Keymapping-Shortcuts, which does not hook into the system (so shouldn't break anything) and will add #command, $shift, etc. Let me know if that works for you. Sean -- View this message in context: http://forum.world.st/GUI-Testing-Library-tp4097866p4172952.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 8, 2011