[Pharo-project] Traits...
Hi! Marcus, Stef and I were wondering whether there is fix for copying compile methods instead of sharing when using traits. The idea is to prevent a shared compiled method to answer wrongly when asking for its properties, class belonging ... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
That shouldn't be hard. I even did it some time ago because Tim asked me as he was working on a new source management. As it goes, this code was never integrated but it should be around somewhere (I think I mailed it also to Marcus). Adrian On Aug 20, 2008, at 16:20 , Alexandre Bergel wrote:
Hi!
Marcus, Stef and I were wondering whether there is fix for copying compile methods instead of sharing when using traits. The idea is to prevent a shared compiled method to answer wrongly when asking for its properties, class belonging ...
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes we should do that and do not share the compile method for alias too, just share the source code This way if r is an alias to foo (A>>r) selector should return r and not foo Stef On Aug 20, 2008, at 4:20 PM, Alexandre Bergel wrote:
Hi!
Marcus, Stef and I were wondering whether there is fix for copying compile methods instead of sharing when using traits. The idea is to prevent a shared compiled method to answer wrongly when asking for its properties, class belonging ...
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
If you find it please send it ;) On Aug 20, 2008, at 4:32 PM, Adrian Lienhard wrote:
That shouldn't be hard.
I even did it some time ago because Tim asked me as he was working on a new source management. As it goes, this code was never integrated but it should be around somewhere (I think I mailed it also to Marcus).
Adrian
On Aug 20, 2008, at 16:20 , Alexandre Bergel wrote:
Hi!
Marcus, Stef and I were wondering whether there is fix for copying compile methods instead of sharing when using traits. The idea is to prevent a shared compiled method to answer wrongly when asking for its properties, class belonging ...
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I found it... Adrian
From: Adrian Lienhard <alienhard@netstyle.ch> Date: October 13, 2006 3:10:18 PM GMT+02:00 To: tim Rowledge <tim@rowledge.org> Cc: Marcus Denker <denker@iam.unibe.ch> Subject: Re: sq 3.9 compiledmethod #sourceClass and #methodClass
Hi Tim,
With respect to the sharing of methods between traits and its users, its a bit more complicated than what I thought yesterday evening... I had a closer look now. So, I changed how methods are propagated from traits to their users as follows. Compiled methods are not shared anymore. As a result the methodClass of a method is correct in all cases (that is, the class in which the method is installed rather in which it is defined). Before installing a method from a trait, it is copied (including copying of its method properties). This means, we do not need to recompile at all. As a consequence, the copied and the original method share its sources, i.e., they have the identical source pointer.
To install my changes in a recent 3.9 image I created a changeset (note, the order is done by hand to make it load...). Then, the following code should fix up all existing methods to comply with the new strategy:
TraitDescription allSubInstancesDo: [ :each | each notifyUsersOfChangedSelectors: each selectors ]. TPureBehavior compileAll
The last statement fixes wrong methodClass references in local methods of TPureBehavior (this is something else, but when we are at it, lets fix that too)
The following code tests whether all users of a trait have correct methodClass bindings.
behaviorsUsingTraits := (TraitDescription allSubInstances gather: [:each | each users]) asSet. behaviorsUsingTraits do: [ :each | each selectorsDo: [ :selector | (each >> selector) methodClass == each ifFalse: [ Transcript show: each name , '>>' , selector , ' ---methodClass: ' , (each >> selector) methodClass name ] ] ]
I've committed the code in the SqueakSource Trait repository, the one I work with before pushing stuff over to the 3.9 repository for inclusion. If you have changes you can commit directly into this repository.
MCHttpRepository location: 'http://squeaksource.com/Traits' user: 'squeak' password: 'squeak'
The versions corresponding with the changes loaded by the cs are: Kernel-al.149 Traits-al.226
All my traits-tests (68) run green, however, I've not further tested this.
There is one problem I can think of right now: when moving sources and condensing changes only those methods are processed which are defined locally (that is, which do not come from a trait) to make sure the same source is not moved twice (see for example #fileOutCategory:on:moveSource:toFile:). Now, in case of moving sources the source pointers are changed (see #printMethodChunk:withPreamble:on:moveSource:toFile:). Methods from traits in this case, since they are excluded, will still point to the old position!
Cheers, Adrian
On Aug 20, 2008, at 16:40 , Stéphane Ducasse wrote:
If you find it please send it ;)
On Aug 20, 2008, at 4:32 PM, Adrian Lienhard wrote:
That shouldn't be hard.
I even did it some time ago because Tim asked me as he was working on a new source management. As it goes, this code was never integrated but it should be around somewhere (I think I mailed it also to Marcus).
Adrian
On Aug 20, 2008, at 16:20 , Alexandre Bergel wrote:
Hi!
Marcus, Stef and I were wondering whether there is fix for copying compile methods instead of sharing when using traits. The idea is to prevent a shared compiled method to answer wrongly when asking for its properties, class belonging ...
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi adrian I think that I fixed the code and that now you can load it into pharo Then I did TraitDescription allSubInstancesDo: [ :each | each notifyUsersOfChangedSelectors: each selectors ]. TPureBehavior compileAll and I get no messages when I execute | behaviorsUsingTraits | behaviorsUsingTraits := (TraitDescription allSubInstances gather: [:each | each users]) asSet. behaviorsUsingTraits do: [ :each | each selectorsDo: [ :selector | (each >> selector) methodClass == each ifFalse: [ Transcript show: each name , '>>' , selector , ' ---methodClass: ' , (each >> selector) methodClass name ] ] ] I got one test not working.... in addition that the fileouttest. I should write some other tests. if r is an alias to foo (A>>r) selector should return r and not foo A>>r class A TB>>r class TB stef
adrian did you get a chance to have a look at my fixes? I did not touch the alias for now. Stef On Aug 22, 2008, at 4:18 PM, Stéphane Ducasse wrote:
Hi adrian
I think that I fixed the code and that now you can load it into pharo
<TraitsSharingCM 2.cs>
Then I did
TraitDescription allSubInstancesDo: [ :each | each notifyUsersOfChangedSelectors: each selectors ]. TPureBehavior compileAll
and I get no messages when I execute
| behaviorsUsingTraits |
behaviorsUsingTraits := (TraitDescription allSubInstances gather: [:each | each users]) asSet. behaviorsUsingTraits do: [ :each | each selectorsDo: [ :selector | (each >> selector) methodClass == each ifFalse: [ Transcript show: each name , '>>' , selector , ' ---methodClass: ' , (each >> selector) methodClass name ] ] ]
I got one test not working.... in addition that the fileouttest. I should write some other tests. if r is an alias to foo (A>>r) selector should return r and not foo
A>>r class A TB>>r class TB
stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Adrian Lienhard -
Alexandre Bergel -
Stéphane Ducasse