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

Re: [Pharo-project] Explicit return in []

by Eliot Miranda

On Wed, Sep 14, 2011 at 11:01 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi > > this is early (at least to me) and I was asking myself a probably stupid > question. But I would like to get your smart answers :) > > does a smalltalk like language really need explicit return in []? > As Lukas says, not if one has exceptions. But Smalltalk-80 V2 didn't have exceptions, and so needed ^-return. Personally I find ^-return elegant and a vital part of the language's simplicity. If ^-return is not allowed in blocks then blocks are special-cases, must be explained, and avoided in certain cases, etc. Getting rid of it pushes the language in a more traditional convenient-for-the-language-implementor direction that I think is a serious mistake. Language should serve the author/reader, *not* the implementor. > Q1 When are they absolutely required? > Q2 What replacing mechanisms would be needed? > Q3 What would we gain from an implementation stand point? > Some simplicity, certainly. But (IMO) ^-return isn't as complex as method lookup and message cacheing so you're not reducing complexity overall. > It seems that in resilience lars removed them and more. > Yes, IIRC he got rid of first-class blocks. They can only be downward funargs (passed as parameters), not upward funargs (stored in inst vars, returned as results and hence used after their enclosing activation has returned). > Stef > > for Q1 I see > > foo > x isZero ifTrue: [^ 33]. > self continue > -- best, Eliot

Sept. 15, 2011

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

by Eliot Miranda

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: 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

Sept. 15, 2011

Re: [Pharo-project] How can I get smart characters in Pharo 1.4?

by Alain Plantec

But it works for me in 1.4 Alain On 15/09/2011 16:48, Mariano Martinez Peck wrote: > Hi guys. I cannot live without smart characters or whatever they are > called. What I mean is when you select/surround something (a piece of > text) and when you press '(' or '[', or whatever opening symbol, it adds > both, the opening and the closing one to what you have selected. > > So...how can I have that in Pharo 1.4 ? > > Thanks > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 15, 2011

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

by Henrik Johansen

On 15. sep. 2011, at 18:45, 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. Sure they are. > 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. > 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. They do: SomeUnusedClass foo ^nil cm := SomeUnusedClass >> #foo. Smalltalk at: #SomeUnusedClass put: nil. cm class = nil should be true. Cheers, Henry

Sept. 15, 2011

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

by Lukas Renggli

> 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. No, they need to be identical unless you want to break class/global creation, deletion, renaming, obsoletion, and possibly more ... The design decision behind using unique associations is that you can replace the value cheaply without having to find and modify any of its users. Lukas -- Lukas Renggli www.lukas-renggli.ch

Sept. 15, 2011

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

by Mariano Martinez Peck

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. >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

Sept. 15, 2011

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

by Henrik Sperre Johansen

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

Sept. 15, 2011

[Pharo-project] Issue 4538 and CompiledMethod equality

by Mariano Martinez Peck

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

Sept. 15, 2011

[Pharo-project] How can I get smart characters in Pharo 1.4?

by Mariano Martinez Peck

Hi guys. I cannot live without smart characters or whatever they are called. What I mean is when you select/surround something (a piece of text) and when you press '(' or '[', or whatever opening symbol, it adds both, the opening and the closing one to what you have selected. So...how can I have that in Pharo 1.4 ? Thanks -- Mariano http://marianopeck.wordpress.com

Sept. 15, 2011

Re: [Pharo-project] [update 1.4] #14141

by Marcus Denker

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

Sept. 15, 2011