On Wed, May 2, 2012 at 8:21 PM, Eliot Miranda <[email protected]>wrote:

> Hi Mariano,
>
> On Wed, May 2, 2012 at 1:27 AM, Mariano Martinez Peck <
> [email protected]> wrote:
>
>>
>>
>> On Tue, May 1, 2012 at 10:17 PM, Mariano Martinez Peck <
>> [email protected]> wrote:
>>
>>>
>>>
>>> On Tue, May 1, 2012 at 10:05 PM, Igor Stasenko <[email protected]>wrote:
>>>
>>>> On 1 May 2012 21:45, Mariano Martinez Peck <[email protected]>
>>>> wrote:
>>>> >
>>>> >
>>>> > On Tue, May 1, 2012 at 9:22 PM, Francisco Garau <
>>>> [email protected]>
>>>> > 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.
>>>
>>>
>>
>>  Ok, I wrote an ugly test and I noticed that the ONLY method with this
>> problem in the image is
>>
>>
>> | behaviorAssociations broken |
>> behaviorAssociations := Smalltalk globals associations select: [:each |
>> each value isBehavior or: [each value isTrait]].
>> broken := OrderedCollection new.
>> (CompiledMethod allInstances select: [:each | each isInstalled])
>>     do: [:aMethod | aMethod literals
>>                     do: [:aLiteral |  aLiteral isVariableBinding
>>                                         ifTrue: [  ((behaviorAssociations
>> includes: aLiteral)
>>                                                     and:
>> [(behaviorAssociations identityIncludes: aLiteral) not])
>>                                                         ifTrue: [broken
>> add: (aMethod -> aLiteral)]
>>                                         ]
>>                     ]
>>     ].
>> broken inspect
>>
>
> This doesn't look for unbound class variables.
>

Indeed.


>  I just wrote something that handles this in Squeak trunk:
>
> methodsWithUnboundGlobals
> "Get all methods that use undeclared global objects that are not listed in
> Undeclared. For a clean image the result should be empty."
>
> "SystemNavigation new methodsWithUnboundGlobals"
>
> ^self allSelect:
>  [:m|
> m literals anySatisfy:
> [:l|
>  l isVariableBinding
> and: [l key isSymbol "avoid class-side methodClass literals"
>  and: [(m methodClass bindingOf: l key) isNil
> and: [(Undeclared associationAt: l key ifAbsent: []) ~~ l]]]]]
>
> so the test would be
>     self assert: SystemNavigation new methodsWithUnboundGlobals isEmpty
>
>
>>
Ok. If I understand this correctly, this is yet ANOTHER thing to test,
right?  I mean, it does not cover my original problem but another one
possible ;)
right?

Thanks Eliot.




> And I have 6 methods from the classes SmalltalkImage and ScriptLoader and
>> all the 6 literals are pointing to ScriptLoader. So something weird
>> happened with this class.
>> Any idea?
>>
>> For the moment I will update the test and do a Compiler recompileAll.
>>
>>
>>
>>
>>>
>>>> > 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 <[email protected]>
>>>> 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
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>
>
> --
> best,
> Eliot
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Reply via email to