Hi guys,
Having a graph of objects that doesn't want to go away even after GC but we think they should have, is a common scenario. At least, in my case. When I have this kind of issue, I spend hours, doing a "Strong Pointers" view from the explorer. And this is a pain and hard.
So I wonder...has anyone build a visualization tool to help this task?
thanks,
Mariano Martinez Peck wrote:
Hi guys,
Having a graph of objects that doesn't want to go away even after GC but we think they should have, is a common scenario. At least, in my case. When I have this kind of issue, I spend hours, doing a "Strong Pointers" view from the explorer. And this is a pain and hard.
So I wonder...has anyone build a visualization tool to help this task?
thanks,
-- Mariano http://marianopeck.wordpress.com
I also find it hard to work backwards from Pointer Explorer. I wanted to use Roassal to examine a graph, but had trouble loading it from the Configuration Browser into an existing Image. So last week I started rolling a Morphic tool for this. I borrowed RTForceBasedLayout from Roassal, but it performed a bit slow (perhaps my misunderstanding on its use) so for now its ended up with a naive layout of my own. I'll try to package it up tonight, hopefully with a demo.
cheers -ben
greetings all,
I had an itch to scratch... I find it difficult using the tree list of the standard Pointer Explorer to track down why objects aren't garbage collected. I always fear I'm not going to notice getting caught in a reference loop. So I created a tool presenting an alternative view as a directed graph. The graph incrementally builds out from the target object as you explore it. Nodes are colourised to help manage complexity.
The attached snapshot is produced from evaluating the following Workspace script... testObject := 'END5'. ref1 := { testObject. nil }. ref2 := { ref1 }. ref3 := PDTestResource new heldObject: ref2. ref1 at: 2 put: ref3. "note the reference loop this creates" PointerDetective openOn: testObject.
Now I expect I'm duplicating something done before, but I couldn't find anything quickly and it was an opportunity for some goal direct learning of Morphic. Thanks to Roassal an option for a spring-force layout is provided. That code was copied rather than create a dependency, and might need to be rationalized later.
The code is a bit rough from hacking around learning how to make things work, but its functional, so its time to get it out in the open.
For more information please refer to the repository home page... http://smalltalkhub.com/#!/~BenComan/PointerDetective
cheers -ben
The image hangs when I double click on the green circle in your example. By the way, is there a reason why you are not using Roassal? I am just wondering whether something obvious is missing in Roassal to prevent you from doing this? By using Roassal, you would have anti-aliasing, the free integration in GTInspector, many layouts to arrange your nodes, bezier curves, and all the good stuff Athens is providing.
Good idea anyway!
Cheers, Alexandre
On Sep 2, 2014, at 1:40 PM, Ben Coman btc@openInWorld.com wrote:
greetings all,
I had an itch to scratch... I find it difficult using the tree list of the standard Pointer Explorer to track down why objects aren't garbage collected. I always fear I'm not going to notice getting caught in a reference loop. So I created a tool presenting an alternative view as a directed graph. The graph incrementally builds out from the target object as you explore it. Nodes are colourised to help manage complexity.
The attached snapshot is produced from evaluating the following Workspace script... testObject := 'END5'. ref1 := { testObject. nil }. ref2 := { ref1 }. ref3 := PDTestResource new heldObject: ref2. ref1 at: 2 put: ref3. "note the reference loop this creates" PointerDetective openOn: testObject.
Now I expect I'm duplicating something done before, but I couldn't find anything quickly and it was an opportunity for some goal direct learning of Morphic. Thanks to Roassal an option for a spring-force layout is provided. That code was copied rather than create a dependency, and might need to be rationalized later. The code is a bit rough from hacking around learning how to make things work, but its functional, so its time to get it out in the open.
For more information please refer to the repository home page... http://smalltalkhub.com/#!/~BenComan/PointerDetective
cheers -ben <PointerDetectiveExample1.png>_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Ben Coman -
Mariano Martinez Peck