question on traits

Hi All,

Apparently, the way a conflict may be triggered is slightly different  
from what is described in the toplas paper.
in the paper, it is said that a compiled method that is inherited from  
more than one path does not trigger a conflict. With the current  
implementation this trigger a conflict.

For example:
T1 defines foo
T2 uses T1
T3 uses T1
T23 uses T2 + T3
C uses T23

C new foo => conflict error.

One would expect no conflict since there is only one definition of foo
Just wondering...

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Yes, this should not be a conflict. I think I had implemented it that  
way. Probably it was broken in the recent refactoring that I did for  
method sharing...

Adrian

On Apr 10, 2009, at 13:47 , Alexandre Bergel wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Copying methods is probably the right way to do regarding literals and  
properties. A comparison of the bytecodes may solve this issue although.
I added an issue, #725. I will fix it soon.

Cheers,
Alexandre


On 10 Apr 2009, at 14:32, Adrian Lienhard wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Great. I think the simplest thing to do is to check whether the two  
methods have the same origin (CompiledMethod>>#origin). If they have,  
they must be the same. So you don't need to compare their bytecode.

Adrian

On Apr 10, 2009, at 14:48 , Alexandre Bergel wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/4/10 Adrian Lienhard <[hidden email]>:
> Great. I think the simplest thing to do is to check whether the two
> methods have the same origin (CompiledMethod>>#origin). If they have,
> they must be the same. So you don't need to compare their bytecode.
>
yeah, comparing bytecode is not solution, because
^ 'foo'
and
^ 'bar'

having same bytecode, but different literals.



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Although this would be such a big problem, thanks for pointing this out.

Cheers,
Alexandre


On 10 Apr 2009, at 17:35, Igor Stasenko wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Adrian and all traits friends,

The test TraitTest>>testLocalMethodWithSameCodeInTrait is yellow. I  
guess this is because there is no sharing of compiled methods. This  
test is therefore not irrelevant right? Can be safely removed?

Something slightly more technical. What providedLocatedMethod should  
return? What a LocatedMethod should refer to? A location of a method  
in a trait, or where the method is defined for the first time?
An example. Let's assume I have:

        tr1 := self createTraitNamed: #T1 uses: {}.
        tr2 := self createTraitNamed: #T2 uses: {tr1}.
        tr3 := self createTraitNamed: #T3 uses: {tr1}.
        tr23 := self createTraitNamed: #T23 uses: {tr3 + tr2}.
        tr1 compile: 'foo ^ 4'.

        aMethodDescription := tr23 traitComposition  
methodDescriptionForSelector: #foo.
        self assert: (aMethodDescription locatedMethods size = 2).
        self assert: (aMethodDescription locatedMethods
                                                includes: (LocatedMethod location: tr2 selector: #foo)).
        self assert: (aMethodDescription locatedMethods
                                                includes: (LocatedMethod location: tr3 selector: #foo)).

The last two assertion pass. However, is it that intended? I would  
have expected only one locatedMethod, which is (LocatedMethod  
location: tr1 selector: #foo), however I am not sure.
locatedMethods is tested nowhere and there is no documentation.

Cheers,
Alexandre


On 10 Apr 2009, at 14:32, Adrian Lienhard wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I saved this code in www.squeakSource.com/Traits

Cheers,
Alexandre


On 14 Apr 2009, at 15:14, Alexandre Bergel wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Alex,

On Apr 14, 2009, at 15:14 , Alexandre Bergel wrote:

> Hi Adrian and all traits friends,
>
> The test TraitTest>>testLocalMethodWithSameCodeInTrait is yellow. I
> guess this is because there is no sharing of compiled methods. This
> test is therefore not irrelevant right? Can be safely removed?

No. This test finds methods that are implemented in a class (or trait)  
that are equal to a method that could be obtained from a trait. This  
can happen if you accidentally recompile a method in a class instead  
of in the trait. In 102077, btw, this test seems green. (But  
strangely, #testFileOutCategory fails now.)


> Something slightly more technical. What providedLocatedMethod should
> return? What a LocatedMethod should refer to? A location of a method
> in a trait, or where the method is defined for the first time?

The former. LocatedMethod a simple (internal) class that encapsulates  
a method and the behavior in which the method is implemented.  
Nowadays, we could probably even avoid this since methods know the  
behavior they are implemented in (this was not the case before).

Looks good. Both traits tr2 and tr3 provide a method #foo. At the time  
when LocatedMethod instances are created, no conflicts are resolved  
(or methods merged) yet. The interesting logic is in  
TraitMethodDescription (see class comment). If you are at fixing the  
conflict of methods from the same origin, I think the right place is  
TraitMethodDescription>>providedLocatedMethod. This method fails  
(returns nil) if it finds more than one provided method. It should not  
fail, though, if those methods have the same #origin.

> locatedMethods is tested nowhere and there is no documentation.

Well, it has a class comment and there are unit tests in the class  
LocatedMethodTest. (According to the test runner's "Run Coverage", the  
class even is completely covered.)

HTH,
Adrian



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> In 102077, btw, this test seems green. (But
> strangely, #testFileOutCategory fails now.)

Exact, but it failed in a 10259.

> The former. LocatedMethod a simple (internal) class that encapsulates
> a method and the behavior in which the method is implemented.
> Nowadays, we could probably even avoid this since methods know the
> behavior they are implemented in (this was not the case before).

Ok. It is clearer now.

> Looks good. Both traits tr2 and tr3 provide a method #foo. At the time
> when LocatedMethod instances are created, no conflicts are resolved
> (or methods merged) yet. The interesting logic is in
> TraitMethodDescription (see class comment). If you are at fixing the
> conflict of methods from the same origin, I think the right place is
> TraitMethodDescription>>providedLocatedMethod. This method fails
> (returns nil) if it finds more than one provided method. It should not
> fail, though, if those methods have the same #origin.

I extended few methods:
TraitMethodDescription>>providedLocatedMethod
        | locatedMethod aLocatedMethod refOrigin |
        locatedMethod := nil.
        self locatedMethods ifEmpty: [ ^ nil].

        self locatedMethods size > 1
                ifTrue: [ aLocatedMethod := self locatedMethods anyOne.
                                                refOrigin := (aLocatedMethod location >> aLocatedMethod  
selector) origin.
                                                (self locatedMethods
                                                        allSatisfy: [:each | each method origin == refOrigin])
                                                ifTrue: [ ^ aLocatedMethod ]].
       
        self locatedMethods do: [:each |
                each method isProvided ifTrue: [
                        locatedMethod isNil ifFalse: [^nil].
                        locatedMethod := each]].
        ^locatedMethod


TraitMethodDescription>>isConflict
        | count originMethodReferenciel |
        count := 0.

        self locatedMethods size > 1
                ifTrue:
                        ["If they are more than 1 located method, then check whether these  
methods have the same origin"
                        originMethodReferenciel := self locatedMethods anyOne method origin.
                        ((self locatedMethods collect: [:lm | lm method]) allSatisfy:  
[:each | each method origin == originMethodReferenciel])
                                ifTrue: [ ^ false ]].

        self methodsDo: [:each |
                each isProvided ifTrue: [
                        count := count + 1.
                        count > 1 ifTrue: [^true]]].
        ^false

In providedLocatedMethod, I am not sure about the "^ aLocatedMethod".  
This does not seem to be a big deal, since the result is checked for  
nullity only.

These two enhanced methods makes testOrigin green.  testOrigin is a  
new test that create a diamond made of 4 traits. The code is available  
in Traits@SqueakSource.

Does this code looks okay? If yes, then I will put it in PharoInbox.

Sorry for the long code excerpts.

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project