- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] problem with CompiledMethod equality

by Henrik Johansen

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.... Cheers, Henry

May 18, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by StÃ©phane Ducasse

I was planning to have a look just after a couple of integrations... but you save my time :) On May 18, 2010, at 4:00 PM, Lukas Renggli wrote: >>> So...any hints? is this the expected behavior ? or it is a bug ? >> >> certainly a bug > > I would not say that this is a bug, it depends of course what you > consider equal. > > The current definition of #= in compiled method is has same bytecode, > same literals (except the class and selector) and same annotations. > > In your case you probably should use an IdentitySet or IdentityDictionary. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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 Lukas Renggli

>> So...any hints? is this the expected behavior ? Â or it is a bug ? > > certainly a bug I would not say that this is a bug, it depends of course what you consider equal. The current definition of #= in compiled method is has same bytecode, same literals (except the class and selector) and same annotations. In your case you probably should use an IdentitySet or IdentityDictionary. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 18, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by StÃ©phane Ducasse

On May 18, 2010, at 3:35 PM, Mariano Martinez Peck wrote: > Hi folks. I was debugging a problem with Moose and I realized that 2 different methods can have the same CompiledMethod. This was weird for me. I don't know if this is correct or not. > > For example, evaluate: > > (InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup) -> true > > If you look at > > CompiledMethod = aCompiledMethod > "Answer whether the receiver implements the same code as aCompiledMethod." > > | numLits | > self == aCompiledMethod > ifTrue: [ ^ true ]. > self class = aCompiledMethod class > ifFalse: [ ^ false ]. > self size = aCompiledMethod size > ifFalse: [ ^ false ]. > self header = aCompiledMethod header > ifFalse: [ ^ false ]. > self initialPC to: self endPC do: [ :i | > (self at: i) = (aCompiledMethod at: i) > ifFalse: [ ^ false ] ]. > (self sameLiteralsAs: aCompiledMethod) > ifFalse: [ ^ false ]. > self halt. > ^ true > > > It is returning in the last ^ true. > > What was weird for me is that (self sameLiteralsAs: aCompiledMethod) returns true also. But if I print both literals: > > self literals -> {#methodReturnTop. (#InstructionClient->InstructionClient)} > > aCompiledMethod literals -> {#doDup. (#InstructionClient->InstructionClient)} > > So...for me they are differnt, but sameLiteralsAs: is returning true. Debugging that, it seems that in that method it is returning in the last ^ true. > > So...any hints? is this the expected behavior ? or it is a bug ? certainly a bug > > Thanks > > Mariano > > > _______________________________________________ > 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 Mariano Martinez Peck

Sorry...I forgot a detail: the problem is that they were storing CompiledMethods in a Dictionary, keys. I guess in Pharo 1.0 it works perfect, but in 1.1 since keys return a Set (that was the changed?), you miss some methods ;) Just do InstructionClient methods size -> 27 InstructionClient methods asSet size -> 21 so...it is not fun :( solution ? ideas? help ? Thanks :) On Tue, May 18, 2010 at 3:35 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi folks. I was debugging a problem with Moose and I realized that 2 > different methods can have the same CompiledMethod. This was weird for me. I > don't know if this is correct or not. > > For example, evaluate: > > (InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup) -> > true > > If you look at > > CompiledMethod = aCompiledMethod > "Answer whether the receiver implements the same code as > aCompiledMethod." > > | numLits | > self == aCompiledMethod > ifTrue: [ ^ true ]. > self class = aCompiledMethod class > ifFalse: [ ^ false ]. > self size = aCompiledMethod size > ifFalse: [ ^ false ]. > self header = aCompiledMethod header > ifFalse: [ ^ false ]. > self initialPC to: self endPC do: [ :i | > (self at: i) = (aCompiledMethod at: i) > ifFalse: [ ^ false ] ]. > (self sameLiteralsAs: aCompiledMethod) > ifFalse: [ ^ false ]. > self halt. > ^ true > > > It is returning in the last ^ true. > > What was weird for me is that (self sameLiteralsAs: aCompiledMethod) > returns true also. But if I print both literals: > > self literals -> {#methodReturnTop. > (#InstructionClient->InstructionClient)} > > aCompiledMethod literals -> {#doDup. > (#InstructionClient->InstructionClient)} > > So...for me they are differnt, but sameLiteralsAs: is returning true. > Debugging that, it seems that in that method it is returning in the last ^ > true. > > So...any hints? is this the expected behavior ? or it is a bug ? > > Thanks > > Mariano > > >

May 18, 2010

[Pharo-project] problem with CompiledMethod equality

by Mariano Martinez Peck

Hi folks. I was debugging a problem with Moose and I realized that 2 different methods can have the same CompiledMethod. This was weird for me. I don't know if this is correct or not. For example, evaluate: (InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup) -> true If you look at CompiledMethod = aCompiledMethod "Answer whether the receiver implements the same code as aCompiledMethod." | numLits | self == aCompiledMethod ifTrue: [ ^ true ]. self class = aCompiledMethod class ifFalse: [ ^ false ]. self size = aCompiledMethod size ifFalse: [ ^ false ]. self header = aCompiledMethod header ifFalse: [ ^ false ]. self initialPC to: self endPC do: [ :i | (self at: i) = (aCompiledMethod at: i) ifFalse: [ ^ false ] ]. (self sameLiteralsAs: aCompiledMethod) ifFalse: [ ^ false ]. self halt. ^ true It is returning in the last ^ true. What was weird for me is that (self sameLiteralsAs: aCompiledMethod) returns true also. But if I print both literals: self literals -> {#methodReturnTop. (#InstructionClient->InstructionClient)} aCompiledMethod literals -> {#doDup. (#InstructionClient->InstructionClient)} So...for me they are differnt, but sameLiteralsAs: is returning true. Debugging that, it seems that in that method it is returning in the last ^ true. So...any hints? is this the expected behavior ? or it is a bug ? Thanks Mariano

May 18, 2010

Re: [Pharo-project] TORCH: supporting source-code change integration

by Veronica Isabel Uquillas Gomez

Hi Tudor, thank you :D sure!!! cheers, Veronica On 18 May 2010, at 11:39, Tudor Girba wrote: > Hi Veronica, > > It is pretty impressive :). > > Would it be Ok if I added this on the Moose page? > > Cheers, > Doru > > > On 18 May 2010, at 11:21, StÃ©phane Ducasse wrote: > >> Thanks veronica. >> lukas said that he was impressed this is a complement :) >> >> On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote: >> >>> Dear all, >>> >>> I would like to announce Torch, a tool for supporting source-code change integration. For now, it offers visualizations of the changes and enhanced change lists. >>> Torch can be accessed through Monticello (in the main MC browser, in the repository browser or in the history browser). Selecting a version or slice, you can view the changes with Torch using the contextual menu. >>> Once you open the Torch dashboard, you can access the enhanced change list or a detailed visualization via the contextual menu as well. >>> >>> Torch is available on SqueakSource, the repository is named Torch, and you need to load the ConfigurationOfTorch package. >>> It runs in a dev or core image. >>> >>> For a dev image. >>> - ConfigurationOfTorch loadVersion10 >>> >>> For a core image. >>> 1) Set fonts - described in the attached file. >>> 2) ConfigurationOfTorch loadDefault >>> >>> I would appreciate comments and feedback! >>> >>> Best Regards, >>> VerÃ³nica Uquillas GÃ³mez >>> Vrije University Brussel - SOFT Lab >>> University of Lille - RMOD Team >>> >>> <torchFontsScript.st> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > _______________________________________________ > 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