On Tue, May 1, 2012 at 10:05 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 1 May 2012 21:45, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Tue, May 1, 2012 at 9:22 PM, Francisco Garau <
francisco.garau@gmail.com>
wrote:
Your code snippet is comparing the associations. The below one evaluates to true:
(Smalltalk globals associationAt: #ScriptLoader) value == ((SmalltalkImage >> #shrinkToCore) literalAt: 4) value
Yes, but the literals of CompiledMethod that refer to classes should have the SAME association as Smalltalk globals. In fact, that's the reason why we have:
indeed. The question is what leads to creation of multiple associations pointing to same global?
Exactly. I can easily fix it with a Compiler recompileAll. But the main question is if we have a bug or something that could let us in that state.
Association >> #literalEqual: otherLiteral "Answer true if the receiver and otherLiteral represent the same literal. Variable bindings are literally equals only if identical. This is how variable sharing works, by preserving identity and changing only the value." ^self == otherLiteral
instead of the Object implementation.
On 1 May 2012 17:52, Mariano Martinez Peck <marianopeck@gmail.com>
wrote:
(Smalltalk globals associationAt: #ScriptLoader) == ((SmalltalkImage >> #shrinkToCore) literalAt: 4) gives false when it should be true. If I do a Compiler recompileAll it gets fixed. So, my question is, is that normal? how could that happen? is there any real problem behind?
anyway, can we do a recompileAll for the moment?
thanks!
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
-- Mariano http://marianopeck.wordpress.com