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

Re: [Pharo-project] [squeak-dev] Re: Issue 4538 and CompiledMethod equality
by Eliot Miranda Sept. 15, 2011

Sept. 15, 2011

On Thu, Sep 15, 2011 at 1:00 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/9/15 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Thu, Sep 15, 2011 at 9:45 AM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> Ok, I understand. But > >> > >> On Thu, Sep 15, 2011 at 6:05 PM, Henrik Sperre Johansen > >> <henrik.s.johansen(a)veloxit.no> wrote: > >>> > >>> On 15.09.2011 17:27, Mariano Martinez Peck wrote: > >>> > >>> Hi guys. I am having a problem with the integration of issue 4538: > >>> http://code.google.com/p/pharo/issues/detail?id=4538 > >>> > >>> I am serializing CompiledMethods with Fuel and then I materialize them. > >>> To test they are correct, I use #= > >>> So far it was working correctly, but now for the materialized method it > >>> says they are not equal. The problem is that #= is failing in > >>> > >>> (self sameLiteralsAs: aCompiledMethod) > >>> > >>> And inside that method, it is failing because (literal1 == literal2 > >>> or: [ literal1 literalEqual: literal2 ]) > >>> answers false. > >>> > >>> So... why literal1 literalEqual: literal2 answers false? from what I > can > >>> say, having that selector: "literalEqual", then both MUST be equal, > because > >>> they are. > >>> The problem is that it was added: > >>> > >>> Association >> literalEqual: otherLiteral > >>> "Answer true if the receiver and otherLiteral represent the same > >>> literal. > >>> Variable bindings are literally equals only if identical. > >>> This is how variable sharing works, by preserving identity and > >>> changing only the value." > >>> ^self == otherLiteral > >>> > >>> > >>> So....I am not sure I agree with this change. > >>> > >>> Any idea how can we deal with this problem? > >>> > >>> Cheers > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> > >>> The change is correct, here's an example: > >>> > >>> Create a global: > >>> Global := 1 > >>> > >>> Create a method: > >>> foo > >>> ^Global > >>> > >>> Serialize method, deserialize > >>> > >>> Change value of global: > >>> Global := 5. > >>> > >>> foo should return 5, not 1. > >>> Unless it's actually the same association as in the SystemDictionary, > >>> this will not be true. > >>> > >> > >> I understand that. In fact, in Fuel we use exactly the same association > of > >> SystemDictionary for globals. Look this test example: > >> > >> testGlobalVariableMethod > >> > >> | materializedCompiledMethod | > >> Smalltalk globals at: #TestGlobalVariableMethod2 put: false. > >> (self class compileSilently: 'globalVariableForTestingMethod > >> Transcript name. > >> ^ GlobalVariableForTesting.'). > >> > >> materializedCompiledMethod := self materializedCompiledMethod: (self > >> class >> #globalVariableForTestingMethod). > >> Smalltalk globals at: #GlobalVariableForTesting put: true. > >> self assert: (materializedCompiledMethod valueWithReceiver: self > >> arguments: #()). > >> > >> > >> > >> 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. > > 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: > > Hmm, good catch. > A metaclass is never accessed by dictionary lookup, but only by > sending #class to a class, so there is no point in maintaining a > unique Association. > (otherwise, we could maintain such Association in inst. var. thisClass). > Having a nil key is a clear indication that lookup is pointless. > > The question is why having an association at all in the CompiledMethod ? > For handling super sends ? > Yes, but two reasons. One is super sends and the other is being able to answer the methodClass (e.g. for CompiledMethod>>printOn: and for the debugger). One doesn't need to use an association, but one can't change that without changing al the VMs /and/ changing the ClassBuilder so that when it becomes a class on class redefinition the methodsa are updated. Indeed VisualWorks does exactly this. In any case, the super send implementation in the VM means we can't change this overnight :) > I think a simple reference to the class would be enough. > IMHO, the purpose was to simplify implementation. > > And I don't think the example of Henrik is worth : > Lets just change it a bit: > > Object subclass: #SuperFoo.! > Object subclass: #Bar.! > SuperFoo subclass: #Foo.! > > SuperFoo compile: 'bar ^1'. > Foo compile: 'bar > ^super bar *2'. > foo := Foo new. > Smalltalk at: #Foo put: Bar. > ^foo bar > > Could you predict the result (will it try to invoke super Bar bar) ? > Yes, since the last association is shared, we just broke (foo > class>>bar) for no reason... > Right. But Rube Goldberg machines work like Rube Goldberg machines. Tis the nature of the beast. Doctors say "don't do that", and in Smalltalk we should say "what did you expect"? :) Being able to change the system is worth the cost of it behaving contrary to common-sense. Just like the physical world :) > Nicolas > > > 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). > > 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 > > > > > > > > > > -- best, Eliot

1 0

Re: [Pharo-project] [update 1.4] #14141
by Marcus Denker Sept. 15, 2011

Sept. 15, 2011

On Sep 15, 2011, at 2:48 PM, StÃ©phane Ducasse wrote: >> Proably, clearly some more work is required before it is ready >>> (maybe a StackLayout with the adornment in a spaceFill Panel with proportional layout would work) >>> >> >> Now doing the undo with yet another update would be a lot of work... >> >> Is is ok to just remove update 14141-1413 from the update stream? > > Yes Done and Jenkins build re-started. I will take some time off from integrating fixes.. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] [update 1.4] #14141
by Marcus Denker Sept. 15, 2011

Sept. 15, 2011

On Sep 15, 2011, at 2:21 PM, Gary Chambers wrote: > Proably, clearly some more work is required before it is ready > (maybe a StackLayout with the adornment in a spaceFill Panel with proportional layout would work) > Now doing the undo with yet another update would be a lot of work... Is is ok to just remove update 14141-1413 from the update stream? -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] [update 1.4] #14141
by Marcus Denker Sept. 15, 2011

Sept. 15, 2011

On Sep 15, 2011, at 1:40 PM, Gary Chambers wrote: > Somewhat... > The change in PluggableTextMorph>>initialize to a proportional layout > affects the minExtent calculation, hence splitters for text will not allow shrinkage any more... > Maybe we should just undo all the changes... -- Marcus Denker -- http://marcusdenker.de

3 2

[Pharo-project] Class>>asRingDescription
by Fernando Olivero Sept. 15, 2011

Sept. 15, 2011

Veronica, i've started to adopt Ring in Gaucho. Very nice work, excellent tests also! A question, why does the following is true? Collection asRingDefinition methods isEmpty = true If you look at the following method, they should be added here right?, on the ring definition creation. Class>>asRingDefinition | ring | ring := (RGFactory current createClassNamed: self name) category: self category; superclassName: self superclass name; traitCompositionSource: self traitCompositionString; addInstanceVariables: self instVarNames; addClassVariables: self classVarNames; addPoolDictionaries: self poolDictionaryNames; comment: self organization classComment; stamp: self organization commentStamp; definitionSource: self definition; withMetaclass. ring theMetaClass traitCompositionSource: self theMetaClass traitCompositionString; definitionSource: self theMetaClass definition; addInstanceVariables: self theMetaClass instVarNames. ^ring I'm using the latest Pharo1.4 from Jenkins. Fernando

1 0

[Pharo-project] What is an abstract method?
by Alexandre Bergel Sept. 15, 2011

Sept. 15, 2011

Hi! Apparently, the following method is abstract: ArrayedCollection>>add: newObject self shouldNotImplement If I evaluate: (ArrayedCollection>>#add:) isAbstract => true This is not quite right. A method that is cancelled is not abstract. I propose to change CompiledMethod>>abstractMarkers ^ #(subclassResponsibility shouldNotImplement) into CompiledMethod>>abstractMarker ^ #shouldNotImplement Does it make sense? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

6 11

Re: [Pharo-project] [update 1.4] #14141
by Marcus Denker Sept. 15, 2011

Sept. 15, 2011

On Sep 15, 2011, at 12:24 PM, Gary Chambers wrote: > Unfortunately major breakage when I update. > PluggableTextMorph initialize seems to indicate that AdorementMorph is nil > Hence MNU for UndefinedObject does not uunderstand #on: > (shouldn't it be named AdornmentMorph anyway...) > Aargh.. the class was in a system category that is not a Package, so it did not get saved... I will fix it by adding a changeset to the update stream... -- Marcus Denker -- http://marcusdenker.de

2 3

[Pharo-project] [update 1.4] #14141
by Marcus Denker Sept. 15, 2011

Sept. 15, 2011

14141 ----- Issue 3726: Turn the orange corner into a real Morph object http://code.google.com/p/pharo/issues/detail?id=3726 Issue 4791: Add a class to have a better holding of IconicList items http://code.google.com/p/pharo/issues/detail?id=4791 -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] Any like have a FunPharo1.4.image ? Re: Fuel or image segments (project files)
by Marcus Denker Sept. 15, 2011

Sept. 15, 2011

On Sep 15, 2011, at 10:04 AM, Edgar J. De Cleene wrote: > > > > On 9/15/11 3:58 AM, "Marcus Denker" <marcus.denker(a)inria.fr> wrote: > >> But Projects are not working in Pharo since 1.0. > Curious how you do this. I wrote *not working*. We removed Project (the class is there, some 4 methods need to be moved to UIManager). Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] Fuel or image segments (project files)
by Marcus Denker Sept. 15, 2011

Sept. 15, 2011

On Sep 15, 2011, at 8:53 AM, Martin Dias wrote: > Hi Dimitri, > > I think image segments are supported in same way in Pharo but I'm not sure. > ImageSegments are in 1.3, but we removed them in 1.4. But Projects are not working in Pharo since 1.0. > About Fuel, it is in active development. It currently works and has several release versions but it doesn't replace completely ImageSegment. Hopefully we might be capable of doing that in some months... at the moment you can find some limitations, especially if you were using DiskProxy (do you?). > > There is more info, including how to install and try it, here: http://rmod.lille.inria.fr/web/pier/software/Fuel > > Cheers, > MartÃn > > > On Wed, Sep 14, 2011 at 6:59 PM, Dimitry Golubovsky <golubovsky(a)gmail.com> wrote: > Hi, > > The application I am working on (which currently runs under Squeak VM > on Android) will be migrated to Pharo. The current version heavily > relies upon use of image segments (projects) which provides a simple > (though slow) way to save/restore the application data not touching > the image (the Squeak port is unable to save images anyway, Cog can do > this, but I'd rater not touch the image) with versioning. > > Are image segments supported in Pharo Core same way? I saw a message > about stopping the support of image segments in future versions of > Pharo in favor of Fuel. What is current status of Fuel development? Is > it usable? > > Thanks. > > -- > Dimitry Golubovsky > > Anywhere on the Web > > -- Marcus Denker -- http://marcusdenker.de

2 1