Hi guys. In that thread in the mailing lists, you can see the problem I had in Pharo 1.1 as keys of a Dictionary answers a Set. I used CompiledMethod as properties, and the equality of CompiledMethod answers true for methods even with different selectors. So I my case I have problems because elementsAndPropertyValue keys answer me less thing that I put.
The solution, was to change elementsAndPropertyValue to a IdentityDictionary instead of Dictionary. So, I have to subclass DistributionMap, and override initializeInstanceVariables so that:
initializeInstanceVariables
partsAndElements := Dictionary new. elementsAndPropertyValue := IdentityDictionary new. colorMap := Dictionary new. colors := Color strongColors
Do you think this is good ? do you have a better solution ?
Thanks!
Mariano
---------- Forwarded message ---------- From: Mariano Martinez Peck marianopeck@gmail.com Date: Tue, May 18, 2010 at 3:35 PM Subject: problem with CompiledMethod equality To: Pharo Development pharo-project@lists.gforge.inria.fr
Hi folks. I was debugging a problem with Moose and I realized that 2 different methods can have the same CompiledMethod. This was weird for me. I don't know if this is correct or not.
For example, evaluate:
(InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup) -> true
If you look at
CompiledMethod = aCompiledMethod "Answer whether the receiver implements the same code as aCompiledMethod."
| numLits | self == aCompiledMethod ifTrue: [ ^ true ]. self class = aCompiledMethod class ifFalse: [ ^ false ]. self size = aCompiledMethod size ifFalse: [ ^ false ]. self header = aCompiledMethod header ifFalse: [ ^ false ]. self initialPC to: self endPC do: [ :i | (self at: i) = (aCompiledMethod at: i) ifFalse: [ ^ false ] ]. (self sameLiteralsAs: aCompiledMethod) ifFalse: [ ^ false ]. self halt. ^ true
It is returning in the last ^ true.
What was weird for me is that (self sameLiteralsAs: aCompiledMethod) returns true also. But if I print both literals:
self literals -> {#methodReturnTop. (#InstructionClient->InstructionClient)}
aCompiledMethod literals -> {#doDup. (#InstructionClient->InstructionClient)}
So...for me they are differnt, but sameLiteralsAs: is returning true. Debugging that, it seems that in that method it is returning in the last ^ true.
So...any hints? is this the expected behavior ? or it is a bug ?
Thanks
Mariano
Sorry...I forgot to say that the problem with this solution is that not in all the distribution maps of I want IdentityDictionary, but only in some :(
On Thu, May 20, 2010 at 12:39 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi guys. In that thread in the mailing lists, you can see the problem I had in Pharo 1.1 as keys of a Dictionary answers a Set. I used CompiledMethod as properties, and the equality of CompiledMethod answers true for methods even with different selectors. So I my case I have problems because elementsAndPropertyValue keys answer me less thing that I put.
The solution, was to change elementsAndPropertyValue to a IdentityDictionary instead of Dictionary. So, I have to subclass DistributionMap, and override initializeInstanceVariables so that:
initializeInstanceVariables
partsAndElements := Dictionary new. elementsAndPropertyValue := IdentityDictionary new. colorMap := Dictionary new. colors := Color strongColors
Do you think this is good ? do you have a better solution ?
Thanks!
Mariano
---------- Forwarded message ---------- From: Mariano Martinez Peck marianopeck@gmail.com Date: Tue, May 18, 2010 at 3:35 PM Subject: problem with CompiledMethod equality To: Pharo Development pharo-project@lists.gforge.inria.fr
Hi folks. I was debugging a problem with Moose and I realized that 2 different methods can have the same CompiledMethod. This was weird for me. I don't know if this is correct or not.
For example, evaluate:
(InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup) -> true
If you look at
CompiledMethod = aCompiledMethod "Answer whether the receiver implements the same code as aCompiledMethod."
| numLits | self == aCompiledMethod ifTrue: [ ^ true ]. self class = aCompiledMethod class ifFalse: [ ^ false ]. self size = aCompiledMethod size ifFalse: [ ^ false ]. self header = aCompiledMethod header ifFalse: [ ^ false ]. self initialPC to: self endPC do: [ :i | (self at: i) = (aCompiledMethod at: i) ifFalse: [ ^ false ] ]. (self sameLiteralsAs: aCompiledMethod) ifFalse: [ ^ false ]. self halt. ^ true
It is returning in the last ^ true.
What was weird for me is that (self sameLiteralsAs: aCompiledMethod) returns true also. But if I print both literals:
self literals -> {#methodReturnTop. (#InstructionClient->InstructionClient)}
aCompiledMethod literals -> {#doDup. (#InstructionClient->InstructionClient)}
So...for me they are differnt, but sameLiteralsAs: is returning true. Debugging that, it seems that in that method it is returning in the last ^ true.
So...any hints? is this the expected behavior ? or it is a bug ?
Thanks
Mariano
On 20 mai 2010, at 12:39, Mariano Martinez Peck wrote:
Hi guys. In that thread in the mailing lists, you can see the problem I had in Pharo 1.1 as keys of a Dictionary answers a Set. I used CompiledMethod as properties, and the equality of CompiledMethod answers true for methods even with different selectors. So I my case I have problems because elementsAndPropertyValue keys answer me less thing that I put.
The solution, was to change elementsAndPropertyValue to a IdentityDictionary instead of Dictionary. So, I have to subclass DistributionMap, and override initializeInstanceVariables so that:
initializeInstanceVariables
partsAndElements := Dictionary new. elementsAndPropertyValue := IdentityDictionary new. colorMap := Dictionary new. colors := Color strongColors
Do you think this is good ? do you have a better solution ?
Well you could call super initializeInstanceVariables and override only the initializer for elementsAndPropertyValue. At least you will have less copy-paste code. But it sure does not look good (but again, if it works).
Could you produce a perfect hash key for each CompiledMethod and use that instead of relying directly on CompiledMethod>>= ?
Thanks!
Mariano
---------- Forwarded message ---------- From: Mariano Martinez Peck marianopeck@gmail.com Date: Tue, May 18, 2010 at 3:35 PM Subject: problem with CompiledMethod equality To: Pharo Development pharo-project@lists.gforge.inria.fr
Hi folks. I was debugging a problem with Moose and I realized that 2 different methods can have the same CompiledMethod. This was weird for me. I don't know if this is correct or not.
For example, evaluate:
(InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup) -> true
If you look at
CompiledMethod = aCompiledMethod "Answer whether the receiver implements the same code as aCompiledMethod."
| numLits | self == aCompiledMethod ifTrue: [ ^ true ]. self class = aCompiledMethod class ifFalse: [ ^ false ]. self size = aCompiledMethod size ifFalse: [ ^ false ]. self header = aCompiledMethod header ifFalse: [ ^ false ]. self initialPC to: self endPC do: [ :i | (self at: i) = (aCompiledMethod at: i) ifFalse: [ ^ false ] ]. (self sameLiteralsAs: aCompiledMethod) ifFalse: [ ^ false ]. self halt. ^ true
It is returning in the last ^ true.
What was weird for me is that (self sameLiteralsAs: aCompiledMethod) returns true also. But if I print both literals:
self literals -> {#methodReturnTop. (#InstructionClient->InstructionClient)}
aCompiledMethod literals -> {#doDup. (#InstructionClient->InstructionClient)}
So...for me they are differnt, but sameLiteralsAs: is returning true. Debugging that, it seems that in that method it is returning in the last ^ true.
So...any hints? is this the expected behavior ? or it is a bug ?
Thanks
Mariano
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon