strange problem in CompiledMethod>>=

Hi,

One of the Moose test runs a visualization that manipulates CompiledMethods, and it runs into an error when trying to find an entry inside a dictionary that has compiled methods as keys. In the end, I managed to isolate the problem that can be reproduced by:

1. Download the moose image:
https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/artifact/moose-latest-dev-4.8.zip

2. Execute:
(MooseIncomingQueryResult>>#selectDependencies:) = (MooseOutgoingInvocationQueryResult>>#selectDependencies:).


It seems it is a Pharo problem, or something related to these particular methods. Would anyone be interested in looking into this?

Cheers,
Doru


--
www.tudorgirba.com

"Obvious things are difficult to teach."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi,

I have put together a little analysis and got to 684 problematic pairs in the Moose image:

allCompiledMethods := Object withAllSubclasses flatCollect: #methods.
problematicCases := OrderedCollection new.
allCompiledMethods allPairsDo: [ :a :b |
        [a = b] on: Error do: [ problematicCases add: a->b ] ].
FileSystem disk workingDirectory / 'problematicCompiledMethodsEquality.txt' writeStreamDo: [ :stream |
        problematicCases associationsDo: [ :each |
                stream nextPutAll: '(', each key printString, ') = (', each value printString, ')'; cr ] ]

It takes a while to run this, so I put the result in the attachment. There are quite a number of problematic comparisons that can be reproduced in the original Pharo image, too, so I think we found a bug.

Cheers,
Doru




On Mar 28, 2013, at 6:59 AM, Tudor Girba <[hidden email]> wrote:
--
www.tudorgirba.com

"Don't give to get. Just give."






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Mar 28, 2013, at 6:59 AM, Tudor Girba <[hidden email]> wrote:
Yes, equality just check that the byte code is the same. Historically this is the behavior as methods did not know
their class nor their selector, at some point they where then including this information for #=, but the latest does
not.

We should change it, Methods now contain the information in which class they are installed in and it should be
taken into account for =

There is already a case:

        https://pharo.fogbugz.com/f/cases/7222

        Marcus


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Mar 28, 2013, at 8:05 AM, Marcus Denker <[hidden email]> wrote:

Hmm… I think I was completely wrong. The problem is that the methods are from a Trait and something goes wrong because of
that. I think the problem is the #traitSource annotation, it seems that the code for = has problems when properties are defined
on methods.

        Marcus


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev