I found it... Adrian
From: Adrian Lienhard <[EMAIL PROTECTED]> Date: October 13, 2006 3:10:18 PM GMT+02:00 To: tim Rowledge <[EMAIL PROTECTED]> Cc: Marcus Denker <[EMAIL PROTECTED]> Subject: Re: sq 3.9 compiledmethod #sourceClass and #methodClassHi 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 compileAllThe 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 ] ] ]
TraitsSharingCM.cs
Description: Binary data
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.226All 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 [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
