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





Levente


thanks


 Levente




  doesn't #instVarsInclude do exactly what you are doing there?



 Just partially. Since we have no information about which slots hold
the
reference to the argument, therefore this loop must be "repeated".



Ok, I see.





 Anyway, I have integrated your changes in Pharo, but still, I have the

same
problem :(
If I understand correctly, the following shouldn't fail, but it does.
Here
is the version of Squeak that fails.


 The assetion fails, because the indirection vector (the Array found
by
PointerFinder) holds a reference to the object after the first
assignment
to a. If you move the temporary inside the block or use an inlined loop
(e.g. #to:do: with literal block argument), then the assertion won't
fail.
So this is just a normal (maybe surprising) reference to the object.


 Excellent. Now I got it. Thank you very much for your help Levente.
Now

PointerFinderTest are green :)



 Levente


 | a |

10 timesRepeat: [
a := Date new.
Smalltalk garbageCollect.
self assert: (PointerFinder pointersTo: a) isEmpty
]

Thanks a lot,


On Mon, Jan 9, 2012 at 2:40 PM, Levente Uzonyi <[email protected]> wrote:

On Sun, 8 Jan 2012, Mariano Martinez Peck wrote:


  What I don't understand is why in Squeak it does work.




  Because #pointsTo: is not used in Squeak (yet). As usual I dug
deeper

 than
I should have, so I'll publish a few changes soon.


 Ok, you are right. Squeak #inboundPointersExcluding:  is using

 #instVarsInclude:  rather than #pointsTo. And that solves the

problem in
Pharo as well. But still, I would like to understand why we get
those
method contexts with #pointsTo.


 Because #pointsTo: is a normal message send, it even sends other

methods,
so it will create contexts.


 Thanks Levente for your help. If you find something let us know, I
want
to

 learn :)



 I pushed my changes to the Squeak Inbox, which fully works around

this
issue. The changes about weak references can simply be removed if you
don't
like them, the rest will just work without them.


Levente


 Thanks




 Levente



 Thanks in advance Levente!






 it will create at least one new MethodContext which is not
included
in

 that list.



Levente







 Levente



  Thanks again.




  Levente





 Do you mean what I understand :)? that some tools compiled
methods?
:)



 Stef






 --

 Mariano

 http://marianopeck.wordpress.****************com <

http://marianopeck.wordpress.
****
com <http://marianopeck.wordpress.************com<
http://marianopeck.****
wordpress.com <http://marianopeck.wordpress.********com<
http://marianopeck.****wordpress**.com <
http://wordpress.com><

http://marianopeck.**wordpress**.com <http://wordpress.com>
<http://marianopeck.**wordpress.com<http://marianopeck.wordpress.com>













  --


  Mariano

 http://marianopeck.wordpress.**************com <
http://marianopeck.wordpress.
****
com <http://marianopeck.wordpress.**********com<
http://marianopeck.****
wordpress.com <http://marianopeck.wordpress.******com<
http://marianopeck.**wordpress**.com <http://wordpress.com><
http://marianopeck.**wordpress.com<http://marianopeck.wordpress.com>











 --


 Mariano

http://marianopeck.wordpress.************com <
http://marianopeck.wordpress.
****
com <http://marianopeck.wordpress.********com<
http://marianopeck.****
wordpress.com <http://marianopeck.wordpress.****com<
http://marianopeck.**wordpress.com<http://marianopeck.wordpress.com>










 --


 Mariano
http://marianopeck.wordpress.**********com <
http://marianopeck.wordpress.
****
com <http://marianopeck.wordpress.******com<http://marianopeck.**
wordpress.com 
<http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com>








  --

Mariano
http://marianopeck.wordpress.********com <
http://marianopeck.wordpress.
****
com <http://marianopeck.wordpress.****com<http://marianopeck.**
wordpress.com <http://marianopeck.wordpress.com>>







 --
Mariano
http://marianopeck.wordpress.******com <http://marianopeck.wordpress.
****
com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com>






--
Mariano
http://marianopeck.wordpress.****com <http://marianopeck.wordpress.**
com <http://marianopeck.wordpress.com>>





--
Mariano
http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com>





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


Reply via email to