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

Re: [Pharo-project] [squeak-dev] Re: Issue 4538 and CompiledMethod equality

by Mariano Martinez Peck

I don't really know. I have implemented what Eliot say in the first option and it is working for me. Do you (Henry/Lukas/Nicolas/Eliot) agree to have this first solution and then improve it if necessary ? thanks On Fri, Sep 16, 2011 at 8:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Mariano > > So should we intgerate a fix? > > Stef > > On Sep 15, 2011, at 11:27 PM, Mariano Martinez Peck wrote: > > > > > > > > > BUT, it doesn't mean that Association is always used for globals. > CompiledMethod equality is failing because of the last literal, the one that > maps class name (symbol) and point to the real class. So...when I > materialize, both CMs have non-identical associations for the last literal, > but equal. > > > > As Henrik says the last literals are ideally #== to each other. However, > no Squeak dialect makes any attempt to keep the class0side associations > equal. Look at a class-side method and you'll see it's last literal is > nil->SomeClass class. Now since this association doesn't exist in Smalltalk > (unlike last literals on the instance side) the compiler merely creates > distinct ones for each class-side method. > > > > > > Thanks Eliot for that point. In fact, I have just checked and you are > right. The tests that are failing for me is those where class side methods > are involded. In this case, the last literal of the original CM and the > materialized, gives false in #literalEqual: hence, originalCM = > materializedCM is false :( > > > > > > > > Personally I don't think one can defend the position where method > equality is different for instance-side or class-side methods so there must > be some solutions: > > > > 1. special case comparison of the last literal (the methodClass literal), > comparing keys and insisting that the keys be #== and the values be #== > (can't just define it as keys #== since all similar class-side methods will > be equal irrespective of their actual class). > > > > > > This one seems the easier and fixes my problem :) > > > > sameLiteralsAs: method > > "Compare my literals to those of method. This is needed to compare > compiled methods." > > > > | numLits literal1 literal2 | > > (numLits := self numLiterals) ~= method numLiterals > > ifTrue: [ ^ false ]. > > "The last literal requires special checking instead of using > #literalEqual:" > > 1 to: numLits - 1 do: [ :index | > > literal1 := self literalAt: index. > > literal2 := method literalAt: index. > > (literal1 == literal2 or: [ literal1 literalEqual: literal2 ]) > > ifFalse: [ > > (index = 1 and: [ #(117 120) includes: self primitive ]) > > ifTrue: [ > > literal1 isArray > > ifTrue: [ > > (literal2 isArray and: [ literal1 > allButLast = literal2 allButLast ]) > > ifFalse: [ self halt. ^ false ] ] > > ifFalse: [ > > "ExternalLibraryFunction" > > (literal1 analogousCodeTo: literal2) > > ifFalse: [ self halt. ^ false ] ] ] > > ifFalse: [ > > index = (numLits - 1) > > ifTrue: [ > > "properties" > > (self properties analogousCodeTo: method > properties) > > ifFalse: [ self halt. ^ false ] ] > > ifFalse: [ self halt. ^ false ] ] ] ]. > > literal1 := self literalAt: numLits. > > literal2 := method literalAt: numLits. > > ^ ((literal1 key == literal2 key) and: [literal1 value == literal2 > value]). > > > > > > > > 2. special case comparison of the last literal (the methodClass literal), > insisting only that the class of the literal be the same if it > isVariableBinding. > > > > 3. make the compile unique class-side methodClass literals. i.e. if a > class already has a class-side method then the compiler or method dictionary > insertion code must find that existing association and reuse it > > > > Other ideas? > > > > >From my point of view, that literal, the last one does not need to be > identical to assume 2 CMs are equal. They just need to be equal. > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > > > -- > > best, > > Eliot > > > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 16, 2011

Re: [Pharo-project] Minimal buildable Pharo image with GUI?

by Pavel Krivanek

Hi, see http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg52168.ht… -- Pavel On Fri, Sep 16, 2011 at 4:45 PM, Dimitry Golubovsky <golubovsky(a)gmail.com> wrote: > Hi, > > I feel a need in as small as possible Pharo image (ideally > script-buildable from e. g. PharoKernel) to use on Android as a > setup/administration tool (I might just bundle it with CogDroid). I > need basic Morphic (maybe even w/o PolyMorph) and network, perhaps > that's it. > > Has anybody done anything similar? Any ideas? > > Thanks. > > -- > Dimitry Golubovsky > > Anywhere on the Web > >

Sept. 16, 2011

Re: [Pharo-project] [squeak-dev] Re: Issue 4538 and CompiledMethod equality

by StÃ©phane Ducasse

Mariano So should we intgerate a fix? Stef On Sep 15, 2011, at 11:27 PM, Mariano Martinez Peck wrote: > > > > BUT, it doesn't mean that Association is always used for globals. CompiledMethod equality is failing because of the last literal, the one that maps class name (symbol) and point to the real class. So...when I materialize, both CMs have non-identical associations for the last literal, but equal. > > As Henrik says the last literals are ideally #== to each other. However, no Squeak dialect makes any attempt to keep the class0side associations equal. Look at a class-side method and you'll see it's last literal is nil->SomeClass class. Now since this association doesn't exist in Smalltalk (unlike last literals on the instance side) the compiler merely creates distinct ones for each class-side method. > > > Thanks Eliot for that point. In fact, I have just checked and you are right. The tests that are failing for me is those where class side methods are involded. In this case, the last literal of the original CM and the materialized, gives false in #literalEqual: hence, originalCM = materializedCM is false :( > > > > Personally I don't think one can defend the position where method equality is different for instance-side or class-side methods so there must be some solutions: > > 1. special case comparison of the last literal (the methodClass literal), comparing keys and insisting that the keys be #== and the values be #== (can't just define it as keys #== since all similar class-side methods will be equal irrespective of their actual class). > > > This one seems the easier and fixes my problem :) > > sameLiteralsAs: method > "Compare my literals to those of method. This is needed to compare compiled methods." > > | numLits literal1 literal2 | > (numLits := self numLiterals) ~= method numLiterals > ifTrue: [ ^ false ]. > "The last literal requires special checking instead of using #literalEqual:" > 1 to: numLits - 1 do: [ :index | > literal1 := self literalAt: index. > literal2 := method literalAt: index. > (literal1 == literal2 or: [ literal1 literalEqual: literal2 ]) > ifFalse: [ > (index = 1 and: [ #(117 120) includes: self primitive ]) > ifTrue: [ > literal1 isArray > ifTrue: [ > (literal2 isArray and: [ literal1 allButLast = literal2 allButLast ]) > ifFalse: [ self halt. ^ false ] ] > ifFalse: [ > "ExternalLibraryFunction" > (literal1 analogousCodeTo: literal2) > ifFalse: [ self halt. ^ false ] ] ] > ifFalse: [ > index = (numLits - 1) > ifTrue: [ > "properties" > (self properties analogousCodeTo: method properties) > ifFalse: [ self halt. ^ false ] ] > ifFalse: [ self halt. ^ false ] ] ] ]. > literal1 := self literalAt: numLits. > literal2 := method literalAt: numLits. > ^ ((literal1 key == literal2 key) and: [literal1 value == literal2 value]). > > > > 2. special case comparison of the last literal (the methodClass literal), insisting only that the class of the literal be the same if it isVariableBinding. > > 3. make the compile unique class-side methodClass literals. i.e. if a class already has a class-side method then the compiler or method dictionary insertion code must find that existing association and reuse it > > Other ideas? > > >From my point of view, that literal, the last one does not need to be identical to assume 2 CMs are equal. They just need to be equal. > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > best, > Eliot > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 16, 2011

Re: [Pharo-project] Minimal buildable Pharo image with GUI?

by StÃ©phane Ducasse

On Sep 16, 2011, at 4:45 PM, Dimitry Golubovsky wrote: > Hi, > > I feel a need in as small as possible Pharo image (ideally > script-buildable from e. g. PharoKernel) to use on Android as a > setup/administration tool (I might just bundle it with CogDroid). I would love that too. Just no time to work on it :((((((((( Too many admin tasks. I will try to create more space for me. > I > need basic Morphic (maybe even w/o PolyMorph) and network, perhaps > that's it. > > Has anybody done anything similar? Any ideas? > > Thanks. > > -- > Dimitry Golubovsky > > Anywhere on the Web >

Sept. 16, 2011

Re: [Pharo-project] anyone have a more up-to-date MethodWrappers for Squeak than MethodWrappers3.9-pmm.10?

by StÃ©phane Ducasse

On Sep 16, 2011, at 12:18 AM, Eliot Miranda wrote: > Hi All, > > does this test look right to you? Isn't the line "self assert:wrapper wasActive" just bogus? > > MwMethodWrapperTest>>testWasActive > > | wrapper | > wrapper := self wrapperClass on: #methodOne inClass: MwClassA. > self deny: wrapper wasActive. > wrapper install. > self deny: wrapper wasActive. > wrapper uninstall. > self assert: wrapper wasActive. ^^^^^^^^^^^^^^ looks suspicious to me. I played a lot with the internals of MW on VW and I do not see this test as making sense. > self > should: [wrapper install] > raise: Error. Similarly (may be this is the squeak/phaor implementation) but normally installing/uninstalling should be revertable without this last test. > > On Tue, Sep 13, 2011 at 2:42 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > the most up-to-date MethodWrappers I can find is for Squeak 3.9, pre-closures. Anyone have anything compatible with Squeak 4.1/4.2/Pharo 1.1/1.2/1.3? > > -- > best, > Eliot > > > > > -- > best, > Eliot >

Sept. 16, 2011

[Pharo-project] [update 1.4] #14144

by Marcus Denker

14144 ----- Issue 4806: Do not do double package clean on #cleanUpForRelease http://code.google.com/p/pharo/issues/detail?id=4806 Issue 4799: AbstractTool fix http://code.google.com/p/pharo/issues/detail?id=4799 -- Marcus Denker -- http://marcusdenker.de

Sept. 16, 2011

[Pharo-project] Minimal buildable Pharo image with GUI?

by Dimitry Golubovsky

Hi, I feel a need in as small as possible Pharo image (ideally script-buildable from e. g. PharoKernel) to use on Android as a setup/administration tool (I might just bundle it with CogDroid). I need basic Morphic (maybe even w/o PolyMorph) and network, perhaps that's it. Has anybody done anything similar? Any ideas? Thanks. -- Dimitry Golubovsky Anywhere on the Web

Sept. 16, 2011

[Pharo-project] [update 1.4] #14143

by Marcus Denker

14143 ----- NewParagraph and MultiNewParagraph should be merged http://code.google.com/p/pharo/issues/detail?id=3370 -- Marcus Denker -- http://marcusdenker.de

Sept. 16, 2011

[Pharo-project] [update 1.4] #14142

by Marcus Denker

14142 ----- Issue 4798: Improved CompiledMethod>>isAbstract Issue 4798: Improved CompiledMethod>>isAbstract - do a #cleanUpForRelease -- Marcus Denker -- http://marcusdenker.de

Sept. 16, 2011

[Pharo-project] [update 1.4] #14141

by Marcus Denker

14141 ----- Issue 2986: DemoMode should not change Fonts only sizes http://code.google.com/p/pharo/issues/detail?id=2986 -- Marcus Denker -- http://marcusdenker.de

Sept. 16, 2011