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

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

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

by Henrik Johansen

In particular, this prereq in ConfigurationOfGlamour caused it: baseline20beta4: spec spec for: #common do: [ *snip* spec package: 'Morphic-MorphTreeWidget' with: [ spec repository: 'http://squeaksource.com/Momo10']; *snip* ] As I said, since MorphTreeWidget is already part of 1.1Core, this caused an older version of the widget to load. Since Settings Browser uses methods found in the newer version in Core, loading Glamour caused it to DNU when I tried opening a Settings Browser. Cheers, Henry On May 18, 2010, at 2:41 15PM, Henrik Johansen wrote: > Yes, that is where it broke.... > > > On May 18, 2010, at 2:32 30PM, StÃ©phane Ducasse wrote: > >> henrik >> >> did you try on 1.1? >> >> Stef >> >> On May 18, 2010, at 1:00 PM, Henrik Johansen wrote: >> >>> >>> >>> Den 18.05.2010 12:12, skrev Mariano Martinez Peck: >>>> Hola VerÃ³nica! >>>> >>>> I love it!!! nice, very nice :) >>>> >>>> I will give you more feedback as far as I start to use it. >>>> The only thing I would add is a button in the MC. Look the attached >>>> screenshot. It would be cool not only to have it in the context menu, >>>> but in the MC broser...for example, next to "changes" button a "torch" >>>> button or something like that. >>>> >>>> I really like it. Moose and all it tools seems to be working in Pharo >>>> 1.1 so....maybe if people agree we can include this cool tool together >>>> with Mondrian and Glamour ? They have 460 green tests :) >>> Strange, for me it lead to errors in 1.1 because: >>> - It depends on Momo10 (MorphTreeMorph) >>> - This has been integrated into Morphic in 1.1 >>> - Loading Torch overrode the code in Morphic with code from Momo rep. >>> - The "old" tree was missing methods (rowInset:) used by the settings >>> browser, so that broke. >>> >>> Soooo, Metacello tags with version info as well coming soon? >>> I really haven't followed that discussion :) >>> >>> Cheers, >>> Henry >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > 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] TORCH: supporting source-code change integration

by Henrik Johansen

Yes, that is where it broke.... On May 18, 2010, at 2:32 30PM, StÃ©phane Ducasse wrote: > henrik > > did you try on 1.1? > > Stef > > On May 18, 2010, at 1:00 PM, Henrik Johansen wrote: > >> >> >> Den 18.05.2010 12:12, skrev Mariano Martinez Peck: >>> Hola VerÃ³nica! >>> >>> I love it!!! nice, very nice :) >>> >>> I will give you more feedback as far as I start to use it. >>> The only thing I would add is a button in the MC. Look the attached >>> screenshot. It would be cool not only to have it in the context menu, >>> but in the MC broser...for example, next to "changes" button a "torch" >>> button or something like that. >>> >>> I really like it. Moose and all it tools seems to be working in Pharo >>> 1.1 so....maybe if people agree we can include this cool tool together >>> with Mondrian and Glamour ? They have 460 green tests :) >> Strange, for me it lead to errors in 1.1 because: >> - It depends on Momo10 (MorphTreeMorph) >> - This has been integrated into Morphic in 1.1 >> - Loading Torch overrode the code in Morphic with code from Momo rep. >> - The "old" tree was missing methods (rowInset:) used by the settings >> browser, so that broke. >> >> Soooo, Metacello tags with version info as well coming soon? >> I really haven't followed that discussion :) >> >> Cheers, >> Henry >> >> _______________________________________________ >> 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 >

May 18, 2010

Re: [Pharo-project] [squeak-dev] Re: [Esug-list] Re: Talking to Steve Jobs about Scratch.

by Lawson English

On 5/17/10 6:08 PM, John M McIntosh wrote: > Radoslav asked yesterday about progress on the issue of Scratch on the iPad, so it's timely to give everyone an update. > > I did ask Apple today for an update on the situation and was told: "We're still pondering the issue" > > So I remain positive and wait. > Since APple owns part of the copyright to Squeak, perhaps you could just point out to them that it doesn't create an exception to their rule. Lawson

May 18, 2010