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 <[email protected]
> > 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
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
