- Pharo-dev - lists.pharo.org

[Pharo-project] A possible bug in GZip streams

by Martin Dias

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

Dec. 5, 2011

Re: [Pharo-project] Keymapping & OB conflict (was Re: Chasing Browsers)

by Lukas Renggli

Ok, then it must be something else. I don't know why this Keymapping thing, but it is unlikely to work with OB if it was not written for OB. As I said, OB managed its keybindings itself. Lukas On 5 December 2011 03:51, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Lukas Renggli wrote >> >> OB. This means, if you select the method and press Cmd+n it should >> > > Bummer, Cmd-n with a method name selected in OB system browser still brings > up the non-chasing senders browser. > > -- > View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4159064.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Lukas Renggli www.lukas-renggli.ch

Dec. 5, 2011

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

by Martin Dias

(I am working on Pharo 1.3) On Mon, Dec 5, 2011 at 2:16 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 >

Dec. 5, 2011

Re: [Pharo-project] Keymapping & OB conflict (was Re: Chasing Browsers)

by Sean P. DeNigris

Lukas Renggli wrote > > OB. This means, if you select the method and press Cmd+n it should > Bummer, Cmd-n with a method name selected in OB system browser still brings up the non-chasing senders browser. -- View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4159064.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 5, 2011

Re: [Pharo-project] startup errors

by Igor Stasenko

On 4 December 2011 20:46, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Igor Stasenko wrote >> >> We invented a way to hack an image with Camillo. Instead of hacking VM :) >> THis is easy and fast. >> > Cool! What does it mean to "hack an image"? > > When you wrote: > > Igor Stasenko wrote >> >> look at settings, there's already an option to save a new version of >> image before quit. >> if you turn this option on, then any unhandled error will open a >> debugger if you open an image saved in such state. >> > it sounded like this would only work for experiments where you were > expecting you might cause an error during startup. What I'm suggesting (and > I thought the OP was requesting) is a way to recover after accidentally > causing an error at startup. Now there is no way to go back in and set the > setting, so the image is lost, unless you hack the VM. Or is there currently > another way? > yes. what we do with Camillo is to hack the image file by replacing bytecode of unwanted method with ^ self bytecode, in that way image avoiding entering code which leads to failure. To identify specific method, you can search image file for unique sequence of bytecodes :) > -- > View this message in context: http://forum.world.st/startup-errors-tp3736966p4157667.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Dec. 5, 2011

Re: [Pharo-project] startup errors

by Schwab,Wilhelm K

+1 on the option being too late. Given my dislike of silent failures, I can't object to some means of drawing attention to the problem, and failure to start certainly does that. However, there should be a way to allow the image to start in the (likely?) event that it can assist in its repair or replacement. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Sunday, December 04, 2011 1:46 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] startup errors Igor Stasenko wrote > > We invented a way to hack an image with Camillo. Instead of hacking VM :) > THis is easy and fast. > Cool! What does it mean to "hack an image"? When you wrote: Igor Stasenko wrote > > look at settings, there's already an option to save a new version of > image before quit. > if you turn this option on, then any unhandled error will open a > debugger if you open an image saved in such state. > it sounded like this would only work for experiments where you were expecting you might cause an error during startup. What I'm suggesting (and I thought the OP was requesting) is a way to recover after accidentally causing an error at startup. Now there is no way to go back in and set the setting, so the image is lost, unless you hack the VM. Or is there currently another way? -- View this message in context: http://forum.world.st/startup-errors-tp3736966p4157667.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 4, 2011

Re: [Pharo-project] startup errors

by Sean P. DeNigris

Igor Stasenko wrote > > We invented a way to hack an image with Camillo. Instead of hacking VM :) > THis is easy and fast. > Cool! What does it mean to "hack an image"? When you wrote: Igor Stasenko wrote > > look at settings, there's already an option to save a new version of > image before quit. > if you turn this option on, then any unhandled error will open a > debugger if you open an image saved in such state. > it sounded like this would only work for experiments where you were expecting you might cause an error during startup. What I'm suggesting (and I thought the OP was requesting) is a way to recover after accidentally causing an error at startup. Now there is no way to go back in and set the setting, so the image is lost, unless you hack the VM. Or is there currently another way? -- View this message in context: http://forum.world.st/startup-errors-tp3736966p4157667.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 4, 2011

Re: [Pharo-project] Keymapping & OB conflict (was Re: Chasing Browsers)

by Lukas Renggli

>> Maybe you use the wrong browser? AFAIK, only OB implements it. > > Ahh, thank you Lukas. It seems like a bug in Keymapping. What do you think, > Guillermo? Keymapping? I don't think that would work with OB that has its own keymapping. The problem you observe is a long standing bug: if you don't have a text selection key presses are handled by Pharo not by OB. This means, if you select the method and press Cmd+n it should work. Lukas > > The situation: > Â In 1.2.2, I get anOBSendersBrowser. > > Â However in 1.3 rc, from a method definition in OB: > Â Â - if I choose "Senders" from the menu I get anOBSendersBrowser > Â Â - but if I hit Cmd-n, I get a FlatMessageListBrowser. > > The call stack: > - without key mapping: > > >> OBTextMorph>>keyStroke: >> OBTextMorph(TextMorph)>>handleKeystroke: >> KeyboardEvent>>sentTo: >> OBTextMorph(Morph)>>handleEvent: >> OBTextMorph(Morph)>>handleFocusEvent: >> [ActiveHand := self. >> Â Â Â ActiveEvent := anEvent. >> Â Â Â result := focusHolder >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â handleFocusEvent: (anEvent >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â transformedBy: (focusHolder transformedFrom: self))] in >> HandMorph>>sendFocusEvent:to:clear: >> > > - with Keymapping: > > >> SmalltalkEditor>>sendersOfIt >> SmalltalkEditor>>sendersOfIt: >> [editor sendersOfIt: event] in [:editor :morph :event | morph >> Â Â Â Â Â Â Â handleKeymappingInteraction: [editor sendersOfIt: event] >> Â Â Â Â Â Â Â fromKeyboardEvent: event] in KMEditorsDefaultSettings >> class>>buildSmalltalkEditorKeymappingsOn: >> SmalltalkEditor(TextEditor)>>handleKeystrokeAction: >> SmalltalkEditor(TextEditor)>>handleEditionAction:fromKeyboardEvent: >> [self editor handleEditionAction: aBlockInteraction fromKeyboardEvent: >> anEvent] in >> OBTextMorph(TextMorph)>>handleKeymappingInteraction:fromKeyboardEvent: >> OBTextMorph(TextMorph)>>handleInteraction: >> OBTextMorph(TextMorphForEditView)>>handleInteraction: >> OBTextMorph(TextMorph)>>handleKeymappingInteraction:fromKeyboardEvent: >> [:editor :morph :event | morph >> Â Â Â Â Â Â Â handleKeymappingInteraction: [editor sendersOfIt: event] >> Â Â Â Â Â Â Â fromKeyboardEvent: event] in KMEditorsDefaultSettings >> class>>buildSmalltalkEditorKeymappingsOn: >> > > -- > View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4157598.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Lukas Renggli www.lukas-renggli.ch

Dec. 4, 2011

[Pharo-project] Keymapping & OB conflict (was Re: Chasing Browsers)

by Sean P. DeNigris

Lukas Renggli wrote > > Maybe you use the wrong browser? AFAIK, only OB implements it. > Ahh, thank you Lukas. It seems like a bug in Keymapping. What do you think, Guillermo? The situation: In 1.2.2, I get anOBSendersBrowser. However in 1.3 rc, from a method definition in OB: - if I choose "Senders" from the menu I get anOBSendersBrowser - but if I hit Cmd-n, I get a FlatMessageListBrowser. The call stack: - without key mapping: > OBTextMorph>>keyStroke: > OBTextMorph(TextMorph)>>handleKeystroke: > KeyboardEvent>>sentTo: > OBTextMorph(Morph)>>handleEvent: > OBTextMorph(Morph)>>handleFocusEvent: > [ActiveHand := self. > ActiveEvent := anEvent. > result := focusHolder > handleFocusEvent: (anEvent > transformedBy: (focusHolder transformedFrom: self))] in > HandMorph>>sendFocusEvent:to:clear: > - with Keymapping: > SmalltalkEditor>>sendersOfIt > SmalltalkEditor>>sendersOfIt: > [editor sendersOfIt: event] in [:editor :morph :event | morph > handleKeymappingInteraction: [editor sendersOfIt: event] > fromKeyboardEvent: event] in KMEditorsDefaultSettings > class>>buildSmalltalkEditorKeymappingsOn: > SmalltalkEditor(TextEditor)>>handleKeystrokeAction: > SmalltalkEditor(TextEditor)>>handleEditionAction:fromKeyboardEvent: > [self editor handleEditionAction: aBlockInteraction fromKeyboardEvent: > anEvent] in > OBTextMorph(TextMorph)>>handleKeymappingInteraction:fromKeyboardEvent: > OBTextMorph(TextMorph)>>handleInteraction: > OBTextMorph(TextMorphForEditView)>>handleInteraction: > OBTextMorph(TextMorph)>>handleKeymappingInteraction:fromKeyboardEvent: > [:editor :morph :event | morph > handleKeymappingInteraction: [editor sendersOfIt: event] > fromKeyboardEvent: event] in KMEditorsDefaultSettings > class>>buildSmalltalkEditorKeymappingsOn: > -- View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4157598.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 4, 2011

Re: [Pharo-project] Chasing Browsers

by Lukas Renggli

Maybe you use the wrong browser? AFAIK, only OB implements it. Lukas On 4 December 2011 18:08, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Bump. Anyone? Bueller? > > -- > View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4157383.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Lukas Renggli www.lukas-renggli.ch

Dec. 4, 2011