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
Thanks Ben, I think this will be very helpfull :) Could you add a ConfigurationOfPointerDetective in the meta repo to enable an easy access? Thierry Le 02/09/2014 19:40, Ben Coman a écrit :
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
Thierry Goubier wrote:
Thanks Ben,
I think this will be very helpfull :) Could you add a ConfigurationOfPointerDetective in the meta repo to enable an easy access?
I will soon, but its a single mcz with no dependencies, so don't let that hold you back from trying it :) cheers -ben
Thierry
Le 02/09/2014 19:40, Ben Coman a écrit :
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
You are my hero! I was just complaining about that to Doru at ESUG. This sort of tool should be part of the standard tool set so please keep on improving it and weâll try to convince someone to integrate it :) Max On 02.09.2014, at 19:40, 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>
Oh yes, this is essential part of âworking with objectsâ. No? On 02 Sep 2014, at 21:37, Max Leske <maxleske@gmail.com> wrote:
You are my hero! I was just complaining about that to Doru at ESUG. This sort of tool should be part of the standard tool set so please keep on improving it and weâll try to convince someone to integrate it :)
Max
On 02.09.2014, at 19:40, 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>
Hi Ben, Very nice tool! Thank you very much for it. Question....do you think it is possible to add a feature that it automatically builds the whole graph starting at target object until the GC root that is holding it? In Pharo, the GC root is the special object array (see #newSpecialObjectsArray). So the code should basically do a loop for #pointersTo and check if one of those pointers is directly one of the array. Or something like that like. Probably it will crash the VM hahaha. But it would be nice to track from a certain object up to the GC root and see all that path in graph :) On Tue, Sep 2, 2014 at 4:41 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Oh yes, this is essential part of âworking with objectsâ. No?
On 02 Sep 2014, at 21:37, Max Leske <maxleske@gmail.com> wrote:
You are my hero! I was just complaining about that to Doru at ESUG. This sort of tool should be part of the standard tool set so please keep on improving it and weâll try to convince someone to integrate it :)
Max
On 02.09.2014, at 19:40, 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>
-- Mariano http://marianopeck.wordpress.com
BTW , +1 to the ability of open an inspect on a node. On Tue, Sep 2, 2014 at 5:05 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
Hi Ben,
Very nice tool! Thank you very much for it.
Question....do you think it is possible to add a feature that it automatically builds the whole graph starting at target object until the GC root that is holding it? In Pharo, the GC root is the special object array (see #newSpecialObjectsArray). So the code should basically do a loop for #pointersTo and check if one of those pointers is directly one of the array. Or something like that like. Probably it will crash the VM hahaha. But it would be nice to track from a certain object up to the GC root and see all that path in graph :)
On Tue, Sep 2, 2014 at 4:41 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Oh yes, this is essential part of âworking with objectsâ. No?
On 02 Sep 2014, at 21:37, Max Leske <maxleske@gmail.com> wrote:
You are my hero! I was just complaining about that to Doru at ESUG. This sort of tool should be part of the standard tool set so please keep on improving it and weâll try to convince someone to integrate it :)
Max
On 02.09.2014, at 19:40, 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>
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
Also, would be nice to filter out StrongPointerExplorerWrapper instances. On Tue, Sep 2, 2014 at 5:09 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
BTW , +1 to the ability of open an inspect on a node.
On Tue, Sep 2, 2014 at 5:05 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi Ben,
Very nice tool! Thank you very much for it.
Question....do you think it is possible to add a feature that it automatically builds the whole graph starting at target object until the GC root that is holding it? In Pharo, the GC root is the special object array (see #newSpecialObjectsArray). So the code should basically do a loop for #pointersTo and check if one of those pointers is directly one of the array. Or something like that like. Probably it will crash the VM hahaha. But it would be nice to track from a certain object up to the GC root and see all that path in graph :)
On Tue, Sep 2, 2014 at 4:41 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Oh yes, this is essential part of âworking with objectsâ. No?
On 02 Sep 2014, at 21:37, Max Leske <maxleske@gmail.com> wrote:
You are my hero! I was just complaining about that to Doru at ESUG. This sort of tool should be part of the standard tool set so please keep on improving it and weâll try to convince someone to integrate it :)
Max
On 02.09.2014, at 19:40, 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>
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
Very nice. Now, I am wondering why some instances are where they are in my image :-) Thx for making this. Phil On Wed, Sep 3, 2014 at 4:14 AM, Ben Coman <btc@openinworld.com> wrote:
Mariano Martinez Peck wrote:
Also, would be nice to filter out StrongPointerExplorerWrapper instances.
I disagree with that being hard coded. Either StrongPointerExplorerWrapper weakly wraps the object it points to, and so is already handled, or it is a candidate for preventing object garbage collection. For example, if a UI element using StrongPointerExplorerWrapper is removed from visibility but fails to be fully deleted.
What might be good though is provision of a generic filtering mechanism. Pass the candidate from-object to a user supplied block which returns a boolean.
cheers -ben
On Tue, Sep 2, 2014 at 5:09 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
BTW , +1 to the ability of open an inspect on a node.
On Tue, Sep 2, 2014 at 5:05 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi Ben,
Very nice tool! Thank you very much for it.
Question....do you think it is possible to add a feature that it automatically builds the whole graph starting at target object until the GC root that is holding it? In Pharo, the GC root is the special object array (see #newSpecialObjectsArray). So the code should basically do a loop for #pointersTo and check if one of those pointers is directly one of the array. Or something like that like. Probably it will crash the VM hahaha. But it would be nice to track from a certain object up to the GC root and see all that path in graph :)
On Tue, Sep 2, 2014 at 4:41 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Oh yes, this is essential part of âworking with objectsâ. No?
On 02 Sep 2014, at 21:37, Max Leske <maxleske@gmail.com> wrote:
You are my hero! I was just complaining about that to Doru at ESUG. This sort of tool should be part of the standard tool set so please keep on improving it and weâll try to convince someone to integrate it :)
Max
On 02.09.2014, at 19:40, Ben Coman <btc@openInWorld.com> <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>
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
On 2 sept. 2014, at 21:37, Max Leske <maxleske@gmail.com> wrote:
You are my hero! I was just complaining about that to Doru at ESUG. This sort of tool should be part of the standard tool set so please keep on improving it and weâll try to convince someone to integrate it :)
+1
Max
On 02.09.2014, at 19:40, 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>
participants (7)
-
Ben Coman -
Camille Teruel -
Mariano Martinez Peck -
Max Leske -
phil＠highoctane.be -
Thierry Goubier -
Yuriy Tymchuk