Alexandre Bergel wrote: 
The image hangs when I double click on the green circle in your example.

Can you provide me an image to download and investigate?

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?
Roassal really was my first choice. I tired, but after loading Roassal into my image from the Configuration Browser, I was getting the Red X of Death, seeminly due to fonts not being correct. I failed to rectify per cycling the FreeType-enabled setting, but in hindsight I think missed that the DejaVu fonts were still strikefonts.  In any case, it was not a smooth out-of-the box experience.  Per my suggestion [1] it would help if the user had some option after loading for this to occur automatically, to get a true working-out-of-box experience.    Or maybe Roassal needs a Pharo 3 compatibility package that includes AthensStrikeFontRenderer from Pharo 4.

[1] http://moose-dev.97923.n3.nabble.com/Roassal-Easel-Red-X-of-Death-td4032782.html#none

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.

All good stuff I would have liked to have, butcompared to the usefulness of the basic functionality its not critical.  Having now done it on top of Morphic, I consider it an advantage that its light weight. Its only three core classes** although maybe in need of some refactoring and has no external dependencies, so if the functional quality improves, PointerDetective might end up suitable for inclusion in Pharo.  I think that wouldn't be an option if it was based on Roassal.  It would be nice if I could refactor it to use Roassal when that is loaded, but its not an imperative at this time.

**excluding the nice force layout code I took from Roassal, which ended up a secondary alternative, so its not a requirement.

cheers -ben

P.S. I am still planning to get back into the Roassal swing of things by porting my LEKtrek application to newer Roassal, but there have been too many interesting distractions in Pharo land:).

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