Hi Mariano,
just a tangent for now...
On Thu, Dec 29, 2011 at 2:02 PM, Mariano Martinez Peck <
[email protected]> 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
