On Dec 29, 2011, at 11:02 PM, Mariano Martinez Peck wrote: > Hi guys. #pointersTo is broken and that's why some tests of PointerFinderTest > are yellow. Few weeks ago, I changed #pointsTo: so that it does not perform > primitive 142 but it delegates to a new method #instVarsInclude: which has > the primitive 132 now. > > Before this change, if I open a workspace and execute the following: > > | aDate | > aDate := Date new. > aDate pointersTo > > if you execute that several times, it is ALWAYS empty. After the change, in > different executions answer not only empty but some MethodContext instances > whose method is (ProtoObject>>#pointsTo: "a CompiledMethod(220463104)"). Most > of the times, in these MethodContext instances, the receiver are the instance > variables of aDate > So #pointersTo answer, for example, an > Array(CompiledMethod(ProtoObject)>>pointsTo: Time(ProtoObject)>>pointsTo: > Duration(ProtoObject)>>pointsTo:)
I saw that too and I was confused. Thanks for taking the time to look at it. We often had a debugger open so I thought it was the reason. > > This causes #pointersToExcept: to have a different behavior. If in > #pointersToExcept: I replace #pointsTo: with #instVarsInclude: it works > perfect. The only difference is that one includes the class and the other one > doesn't. BUT, in this example, the receiver is aDate, hence, there shouldn't > be any object which class is #aDate. In fact, if I put a "(anObj class == > self) ifTrue: [ self halt. ]" it NEVER HALT. That makes sense. But I don't > understand then why with #pointsTo: it doesnt work and with #instVarsInclude: > it works perfect. > > Any idea? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com >
