David may be you should try to use Moose (still a bit shaky) we will start to work on making it useable by others. Porting the code from VW and changing the source code meta model took us some time. but we do all the code analysis and after you a meta model of the code (with access, invocation....) and you can script mondrian to try it: ScriptLoader loadOB MooseLoader (in Moose squeaksource repository) MooseLoader load Stef On Jul 16, 2009, at 11:44 PM, David Goehrig wrote:
On Thu, Jul 16, 2009 at 4:39 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: Hi david
Cool. BTW if you want to experiment with other visualization you also have mondrian which starts to work well on pharo.
For some reason it doesn't load in any of my images, but I think that has more to do more with my images being highly non-standard for other reasons.
Yes! What is the direction of the dependency The circle in the middle has literal reference to the other that surround it?
Yes. The idea is each circle's represents the number of methods that class has defined in itself (not through inheritance). I then walk through all of the literals and look for variable bindings that refer to a top level class defined in the Smalltalk SystemDictionary. They're arrayed around the one you're currently inspecting in a circle for now.
because in that case it would be interesting to investigate why there is reference to RBParser
Well specifically.. RBParser is there due to this comment in the code of my image:
parseTreeFor: aSymbol self flag: #FIXME. "UGLY hack for beeing able to share AST package with Persephone... this needs to be fixed later".
Smalltalk at: #ReflectiveMethod ifPresent: [:cls | | method | method := self compiledMethodAt: aSymbol. method hasReflectiveMethod ifTrue: [^method reflectiveMethod methodNode]. ].
^RBParser parseMethod: (self sourceCodeAt: aSymbol) onError: [:aString :pos | ^nil]
I don't know if anyone has already taken care of that, my image is based on an older Pharo image.
Do you take into account extensions?
There's a lot of things I'm not taking into account right now. For the time being I'm inspecting the inside of CompiledMethods, and tracking what's getting compiled into them. Anything that affects compilation will be displayed. I'm not terribly interested in doing any source analysis :)
We want to apply a dependency structural matrix on the complete pharo image to also get an idea of the cyclic dependencies.
I get the feeling playing around with this right now that there are quite a few. Array <-> Compiler are cyclic. String <-> Time are cyclic. Actually the whole Time, TimeAndDate, Date, Duration mess is one giant clusterf*ck.
After when I looked at the collaborators of Behavior I do not see a bad guy for now.
I've got few more images up on my blog with my off the cuff impressions of what is going on.
http://blog.dloh.org/2009/07/visualizing-squeak.html
Hopefully tomorrow I'll find some time to polish off the method <-> class linking code, and polish it up enough that other people could import it into their images and start playing. I'm currently relying on a few language extensions in my image that aren't suitable for general consumption. ( like implicit symbols, super- overloaded comma, and default DNU returns nil).
-- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project