May 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Feature: SystemOrganizer class>>default returns SystemOrganization

by StÃ©phane Ducasse

Sean Thanks for submitting this change. this is fun that this changes was accepted in Squeak because people were constantly mad that we introduce singleton instead (SystemNavigation default... SmalltalkImage current of global variables :). Time is changing. Good! Now can we do it better :) what I would love it if we can have SystemOrganization be an instance variable of the SystemDictionary and may be returned by the categorizer message sent to Smalltalk globals. This way each instance of SystemDictionary would have its own SystemOrganizer instance. This will make sure that people can experiment with alternate semantics and that we do not have one monolitic system :) Stef > In Pharo inbox: System-Support-SeanDeNigris.291 > > Motivation: I was trying to delete a category, and found SystemOrganizer via > Method Names. It wasn't immediately obvious how to use it, so I had to whip > out SBE to remind me of SystemOrganization. > > In SystemOrganizer: > * Added (overrides Categorizer class>>default): > SystemOrganizer class>>default > ^ SystemOrganization > * updated class comment > > Sean > > p.s. also submitted to Squeak inbox > -- > View this message in context: http://forum.world.st/Feature-SystemOrganizer-class-default-returns-SystemO… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by StÃ©phane Ducasse

Please send me that and I will integrate it. Stef On May 18, 2010, at 4:46 PM, Henrik Johansen wrote: > > On May 18, 2010, at 4:15 33PM, Henrik Johansen wrote: > >> On May 18, 2010, at 3:39 33PM, Mariano Martinez Peck wrote: >> >>> (InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup) >> >> methodReturnTop startPC -> 13 >> methodReturnTop endPC -> 12. >> >> I have a slight feeling that is one of the reasons :) >> Seems to be related to method trailers size assumptions not holding. >> >> >> Also, sameLiteralsAs: is a mess. >> There are no comments really revealing the intention of the 8 ifTrue/False branches, no refactoring to use revealing method names... >> Can anyone explain to me why numLits -1 = index is checked? >> >> At least for methodReturnTop, which has 2 literals, it certainly does not seem like numLits -1 contains properties.... > > Oh, ok, numLit -1 contains the selector. > > So that would be the "except selector" Lukas mentioned. > Same method in different classes do not equal eachother though, if I've not made a mistake in: > > |mrtCp| > mrtCp := (InstructionClient>>#methodReturnTop) copy. > mrtCp literalAt: 2 put: #ContextPart->ContextPart. > (InstructionClient>>#methodReturnTop) = mrtCp > > At the very least, the branches of > index = 1 and: [ #(117 120) includes: self primitive ]) > ifTrue: [ > > REALLY deserve some comments... > > Cheers, > Henry > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by Henrik Johansen

On May 18, 2010, at 4:41 41PM, Lukas Renggli wrote: >>> (InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup) >> >> methodReturnTop startPC -> 13 >> methodReturnTop endPC -> 12. >> >> I have a slight feeling that is one of the reasons :) >> Seems to be related to method trailers size assumptions not holding. > > That's fine, the method has no bytecode. It is a quick-return self. Ah yes, inspecting it I saw bytes 13 -16 which were diferent, didn't realize those were the trailer itself :) Doh! Cheers, Henry

May 18, 2010

[Pharo-project] [update 1.1] #11365

by StÃ©phane Ducasse

11365 ----- - Issue 2375: Editor shortcuts in New Editors. Thanks fernando - Issue 2434: Debugger full stack enh from Squeak - UIThemeWatery2 beCurrent. Thanks alain - Issue 2433: Better class comment for CharacterBlock from squeak - Issue 2437: Bypassing the modal dialog when sending Class>>rename: Thanks fernando next one: network rollback next next one: condensechanges

May 18, 2010

Re: [Pharo-project] Feature: SystemOrganizer class>>default returns SystemOrganization

by Lukas Renggli

Please no, we need to get rid of this global and move it to an instance variable of SystemDictionary. Like this (and with a few patches to class builder) we have working namespaces. Lukas On 18 May 2010 16:44, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > In Pharo inbox: System-Support-SeanDeNigris.291 > > Motivation: I was trying to delete a category, and found SystemOrganizer via > Method Names. It wasn't immediately obvious how to use it, so I had to whip > out SBE to remind me of SystemOrganization. > > In SystemOrganizer: > * Added (overrides Categorizer class>>default): > SystemOrganizer class>>default > Â ^ SystemOrganization > * updated class comment > > Sean > > p.s. also submitted to Squeak inbox > -- > View this message in context: http://forum.world.st/Feature-SystemOrganizer-class-default-returns-SystemO… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

May 18, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by Henrik Johansen

On May 18, 2010, at 4:15 33PM, Henrik Johansen wrote: > On May 18, 2010, at 3:39 33PM, Mariano Martinez Peck wrote: > >> (InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup) > > methodReturnTop startPC -> 13 > methodReturnTop endPC -> 12. > > I have a slight feeling that is one of the reasons :) > Seems to be related to method trailers size assumptions not holding. > > > Also, sameLiteralsAs: is a mess. > There are no comments really revealing the intention of the 8 ifTrue/False branches, no refactoring to use revealing method names... > Can anyone explain to me why numLits -1 = index is checked? > > At least for methodReturnTop, which has 2 literals, it certainly does not seem like numLits -1 contains properties.... Oh, ok, numLit -1 contains the selector. So that would be the "except selector" Lukas mentioned. Same method in different classes do not equal eachother though, if I've not made a mistake in: |mrtCp| mrtCp := (InstructionClient>>#methodReturnTop) copy. mrtCp literalAt: 2 put: #ContextPart->ContextPart. (InstructionClient>>#methodReturnTop) = mrtCp At the very least, the branches of index = 1 and: [ #(117 120) includes: self primitive ]) ifTrue: [ REALLY deserve some comments... Cheers, Henry

May 18, 2010

[Pharo-project] Feature: SystemOrganizer class>>default returns SystemOrganization

by Sean P. DeNigris

In Pharo inbox: System-Support-SeanDeNigris.291 Motivation: I was trying to delete a category, and found SystemOrganizer via Method Names. It wasn't immediately obvious how to use it, so I had to whip out SBE to remind me of SystemOrganization. In SystemOrganizer: * Added (overrides Categorizer class>>default): SystemOrganizer class>>default ^ SystemOrganization * updated class comment Sean p.s. also submitted to Squeak inbox -- View this message in context: http://forum.world.st/Feature-SystemOrganizer-class-default-returns-SystemO… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 18, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by Lukas Renggli

>> (InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup) > > methodReturnTop startPC -> 13 > methodReturnTop endPC -> 12. > > I have a slight feeling that is one of the reasons :) > Seems to be related to method trailers size assumptions not holding. That's fine, the method has no bytecode. It is a quick-return self. > Also, sameLiteralsAs: is a mess. > There are no comments really revealing the intention of the 8 ifTrue/False branches, no refactoring to use revealing method names... > Can anyone explain to me why numLits Â -1 = index is checked? Check the VM source/compiler on the different special literal slots and how different kind of primitives are encoded. > At least for methodReturnTop, which has 2 literals, it certainly does not seem like numLits -1 Â contains properties.... The two literals are the selector and the class-binding, as the method comment says these literals are not considered for equality. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 18, 2010

[Pharo-project] Fwd: Pharo1.1 and Pharo1.0 difference when pressing CMD-Q

by Fernando olivero

The DNU is reported in ISSUE 1876. Begin forwarded message: > From: Fernando olivero <oliverof(a)lu.unisi.ch> > Date: May 18, 2010 4:22:43 PM GMT+02:00 > To: "Pharo-project(a)lists.gforge.inria.fr Development" <Pharo-project(a)lists.gforge.inria.fr> > Subject: [Pharo-project] Pharo1.1 and Pharo1.0 difference when pressing CMD-Q > Reply-To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> > > Hi, using the MAC OS X VM and pressing CMD-Q in Pharo1.1 sends InputEventSensor>>processEvent: evt > where the evt received is of type 4, a menu event. (just put a Transcript show: evt in the processEvent: evt and you'll see). > > Since EventSensorConstants defines: > > "Types of events" > EventTypeKeyboard := 2. > EventTypeMenu := 4. > > But in Pharo1.0 it generates an event of type 2, a keyboard event. > > I assume that this changed because In Mac-OSX the CMD-Q is binded to a particular action , > and in Pharo1.1 we are using HostSystemMenus. > > But how can i override this behavior? To handle the CMD-Q as any other Keyboard event? > > By the way there's also a DNU, when pressing CMD-Q. > > Thanks, > Fernando > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

[Pharo-project] Pharo1.1 and Pharo1.0 difference when pressing CMD-Q

by Fernando olivero

Hi, using the MAC OS X VM and pressing CMD-Q in Pharo1.1 sends InputEventSensor>>processEvent: evt where the evt received is of type 4, a menu event. (just put a Transcript show: evt in the processEvent: evt and you'll see). Since EventSensorConstants defines: "Types of events" EventTypeKeyboard := 2. EventTypeMenu := 4. But in Pharo1.0 it generates an event of type 2, a keyboard event. I assume that this changed because In Mac-OSX the CMD-Q is binded to a particular action , and in Pharo1.1 we are using HostSystemMenus. But how can i override this behavior? To handle the CMD-Q as any other Keyboard event? By the way there's also a DNU, when pressing CMD-Q. Thanks, Fernando

May 18, 2010