Hi Mariano, just a tangent for now... On Thu, Dec 29, 2011 at 2:02 PM, Mariano Martinez Peck < marianopeck@gmail.com> 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.
primitiveObjectPointsTo is primitive number 132. primitiveVMPath is primitive 142 primitive numbers 146 & 147 are AFAICT unused.
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:)
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?
Write a test case and I'll take a look.
Thanks in advance,
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot