Also, would be nice to filter out StrongPointerExplorerWrapper instances.
On Tue, Sep 2, 2014 at 5:09 PM, Mariano Martinez Peck <marianop...@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 <
> marianop...@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.tymc...@me.com>
>> wrote:
>>
>>> Oh yes, this is essential part of “working with objects”. No?
>>>
>>>
>>> On 02 Sep 2014, at 21:37, Max Leske <maxle...@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 <b...@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
