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/artif...
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."
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 tudor@tudorgirba.com wrote:
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:
- Download the moose image:
https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/artif...
- 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."
-- www.tudorgirba.com
"Don't give to get. Just give."
On Mar 28, 2013, at 6:59 AM, Tudor Girba tudor@tudorgirba.com wrote:
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:
- Download the moose image:
https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/artif...
- 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?
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
On Mar 28, 2013, at 8:05 AM, Marcus Denker marcus.denker@inria.fr wrote:
On Mar 28, 2013, at 6:59 AM, Tudor Girba tudor@tudorgirba.com wrote:
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:
- Download the moose image:
https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/artif...
- Execute:
(MooseIncomingQueryResult>>#selectDependencies:) = (MooseOutgoingInvocationQueryResult>>#selectDependencies:).
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
-
Marcus Denker -
Tudor Girba