[Pharo-project] Bug in #pointsTo: ?

Levente Uzonyi leves at elte.hu
Mon Jan 9 15:50:03 EST 2012


On Mon, 9 Jan 2012, Henrik Johansen wrote:

>
> On Jan 9, 2012, at 8:46 06PM, Levente Uzonyi wrote:
>
>> On Mon, 9 Jan 2012, Mariano Martinez Peck wrote:
>>
>>>>
>>>>>>
>>>>>> So..I am puzzle again. I said "In which scenario can     (self
>>>>> instVarsInclude: anObject)  answer true, but the loop false? "
>>>>> you answered: "The scenario happens when the receiver has weak slots and
>>>>> the argument is referenced from one of those weak slots, but not from the
>>>>> other slots."
>>>>> Imagine the receiver has a weak slot XXX that points to anObject. So (self
>>>>> instVarsInclude: anObject) answers true.   How can the loop answer false
>>>>> without a GC?
>>>>> why would XXX stop pointing to anObject if there is not GC in the middle ?
>>>>>
>>>>
>>>> The loop doesn't iterate over the indexable slots, only named ones.
>>>>
>>>>
>>> grrr you are right!
>>>
>>> Ok, so I finally got it. So previously pointersTo: would answer true even
>>> if the slots were weak. Now it would answer false, and that's why you have
>>> changed the method comment.
>>> Now I am thinking if this should be the default behavior of #pointsTo:. If
>>> I just read the selector #pointsTo:  I would guess weak references are also
>>> taken into account.  So that's why I am not completely sure. Aren't there
>>> any other impact of the system because of this change?
>>> what about having #stronglyPointsTo: with this new version and have another
>>> one #pointsTo: which considers weak also?
>>> does it make sense?  or it is better to directly avoid weak by defualt in
>>> #pointsTo?
>>
>> I wasn't sure about this, that's why it's not in Squeak yet. Ignoring weak references is okay as long as these methods are only used for pointer tracing.
>>
>>
>> Levente
>
> Even with a good comment, the naming starts to make little sense, imho?

Since #pointsTo: doesn't use primitive 132 directly, it's only used from 
the pointer tracing tools, which shouldn't really follow weak references.

> Does an object having weak slots mean it no longer pointsTo: the objects in those slots?

If you mean "points to", then no. :)

>
> Sadly, I have no better succinct suggestions. :/
>
> Also, what happens when an object holds its (non-compact) class in a weak slot?
>
> In other words, is:
>
> wa := WeakArray new: 1.
> wa at: 1 put: WeakArray.
> self assert: (wa pointsTo: WeakArray).
>
> a valid test?

Yes, because its class pointer points to its class (this sounds funny :)).


Levente

>
> Cheers,
> Henry
>




More information about the Pharo-dev mailing list