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 <[email protected]> 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 < > [email protected]> 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 < >> [email protected]> 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 <[email protected]> >>> wrote: >>> >>>> Oh yes, this is essential part of “working with objects”. No? >>>> >>>> >>>> On 02 Sep 2014, at 21:37, Max Leske <[email protected]> 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 <[email protected]> >>>> <[email protected]> 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 > > >
