[Pharo-project] KnownLands: a Class dependency explorer
Hey Pharoers, I've been working on a little project for the past couple days, and now that I have something of a tangible result, I'm going to share the first screen grab. What I've been working on is a visualization tool for analyzing the relationships between Classes and the contents of their CompiledMethods. In the attached screen shot, the TPureBehavior circle in the middle is the root node, and all of the radial nodes are Classes referred to by the CompiledMethods associated with TPureBehavior. Each of these classes is bound to a literal in one of the CompiledMethods. The radius of the circle is directly proportional to the number of methods that Class has. IdentitySet has 2 compiled methods for example, whereas ChangeSet has 124 methods. Once I get collapsing working, and add some trace lines (so that when you've expanded and expanded and expanded it is obvious who is connected to who), I'll post this code somewhere. But what is incredible is how quickly things get really really deeply interconnected things get. Dave -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
Hi david
Hey Pharoers,
I've been working on a little project for the past couple days, and now that I have something of a tangible result, I'm going to share the first screen grab.
What I've been working on is a visualization tool for analyzing the relationships between Classes and the contents of their CompiledMethods.
Cool. BTW if you want to experiment with other visualization you also have mondrian which starts to work well on pharo.
In the attached screen shot, the TPureBehavior circle in the middle is the root node, and all of the radial nodes are Classes referred to by the CompiledMethods associated with TPureBehavior. Each of these classes is bound to a literal in one of the CompiledMethods. The radius of the circle is directly proportional to the number of methods that Class has. IdentitySet has 2 compiled methods for example, whereas ChangeSet has 124 methods.
Once I get collapsing working, and add some trace lines (so that when you've expanded and expanded and expanded it is obvious who is connected to who), I'll post this code somewhere. But what is incredible is how quickly things get really really deeply interconnected things get.
Yes! What is the direction of the dependency The circle in the middle has literal reference to the other that surround it? because in that case it would be interesting to investigate why there is reference to RBParser Do you take into account extensions? We want to apply a dependency structural matrix on the complete pharo image to also get an idea of the cyclic dependencies. After when I looked at the collaborators of Behavior I do not see a bad guy for now.
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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/
2009/7/16 David Goehrig <dave@nexttolast.com>:
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).
Yeah, we have to find someone not caring too much for his shoes to kick these ball of mud! Nicolas
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).
Yeah, we have to find someone not caring too much for his shoes to kick these ball of mud!
I think that we are doing that since Squeak 3.7 so we get used to and making progress
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
Hi David,
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.
I will be interested in knowing what are the problem you're facing in installing Mondrian. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Fri, Jul 17, 2009 at 11:23 AM, Alexandre Bergel <alexandre@bergel.eu>wrote:
I will be interested in knowing what are the problem you're facing in installing Mondrian.
I would too... every time I try to install on any of my images, it goes away for a long time, and never comes out of whatever process coma it has induced. My guess is that some change I made to one of my base classes ages ago has crippled some message send in a bizarre way. I'm not seeing any messages in the transcript, but I've occasionally received out of memory errors. As has been pointed out elsewhere, I tend to abuse my images something fierce, and have very little interest in maintaining baseline compatibility as they're primarily used to prototype language constructs for other projects. Since I don't use Squeak for production code, I tend to abuse it more than a fulltime Smalltalker would. :) Maybe I'll start from a known fresh image, install Mondrian, then attempt to load my stuff. -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
Maybe I'll start from a known fresh image, install Mondrian, then attempt to load my stuff.
I haven't tried with Squeak. With Pharo it works without problem. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hello David, It seems you have an interesting tool. I have a couple of questions about Territory, and may be you want to comment more about its internal architecture: -Do you use constraints solving techniques to find optimal geometric layouts? (or tried larger object graphs?) -Are you using layout adjustment algorithms? (do you manage node insertions or expansions repairing the layout dynamically?) -Any form of soft relaxation or priority weights? -It will support node aliasing? It will support labelling modes? -Have you experimented with triangles or more general polygons? -Do the visualization updates automatically when a user modify a method in a browser? -Do you use MudPie? It will include inheritance or loose method dependencies? Thanks in advance Hernán 2009/7/16 David Goehrig <dave@nexttolast.com>
Hey Pharoers,
I've been working on a little project for the past couple days, and now that I have something of a tangible result, I'm going to share the first screen grab.
What I've been working on is a visualization tool for analyzing the relationships between Classes and the contents of their CompiledMethods.
In the attached screen shot, the TPureBehavior circle in the middle is the root node, and all of the radial nodes are Classes referred to by the CompiledMethods associated with TPureBehavior. Each of these classes is bound to a literal in one of the CompiledMethods. The radius of the circle is directly proportional to the number of methods that Class has. IdentitySet has 2 compiled methods for example, whereas ChangeSet has 124 methods.
Once I get collapsing working, and add some trace lines (so that when you've expanded and expanded and expanded it is obvious who is connected to who), I'll post this code somewhere. But what is incredible is how quickly things get really really deeply interconnected things get.
Dave
-- -=-=-=-=-=-=-=-=-=-=- 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
Normally mondrian has a force base layout and several others. We would be really happy if people want to help. Doru spent already a lot of effort. Hernan if you want constraints solver I have some old code of cassowary, dletablue and friends. Stef
Hello David, It seems you have an interesting tool. I have a couple of questions about Territory, and may be you want to comment more about its internal architecture:
-Do you use constraints solving techniques to find optimal geometric layouts? (or tried larger object graphs?) -Are you using layout adjustment algorithms? (do you manage node insertions or expansions repairing the layout dynamically?) -Any form of soft relaxation or priority weights? -It will support node aliasing? It will support labelling modes? -Have you experimented with triangles or more general polygons? -Do the visualization updates automatically when a user modify a method in a browser? -Do you use MudPie? It will include inheritance or loose method dependencies?
Thanks in advance
Hernán
2009/7/16 David Goehrig <dave@nexttolast.com> Hey Pharoers,
I've been working on a little project for the past couple days, and now that I have something of a tangible result, I'm going to share the first screen grab.
What I've been working on is a visualization tool for analyzing the relationships between Classes and the contents of their CompiledMethods.
In the attached screen shot, the TPureBehavior circle in the middle is the root node, and all of the radial nodes are Classes referred to by the CompiledMethods associated with TPureBehavior. Each of these classes is bound to a literal in one of the CompiledMethods. The radius of the circle is directly proportional to the number of methods that Class has. IdentitySet has 2 compiled methods for example, whereas ChangeSet has 124 methods.
Once I get collapsing working, and add some trace lines (so that when you've expanded and expanded and expanded it is obvious who is connected to who), I'll post this code somewhere. But what is incredible is how quickly things get really really deeply interconnected things get.
Dave
-- -=-=-=-=-=-=-=-=-=-=- 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Oui Stéphane, j'amerais voir quelques exemples de Cassowary et amis. En rapport avec Mondrian j'ai lu les papers (j'ai quelques idées qui pourraient améliorer le framework), c'est un développement exceptionnel, mais je n'ai pas eu du temps de l'appliquer dans notre projet, c'est dommage parce que nous avons ici approximativement 70 paquets. Merci beaucoup! Hernán 2009/7/20 Stéphane Ducasse <stephane.ducasse@inria.fr>
Normally mondrian has a force base layout and several others. We would be really happy if people want to help. Doru spent already a lot of effort. Hernan if you want constraints solver I have some old code of cassowary, dletablue and friends.
Stef
Hello David, It seems you have an interesting tool. I have a couple of questions about Territory, and may be you want to comment more about its internal architecture:
-Do you use constraints solving techniques to find optimal geometric layouts? (or tried larger object graphs?) -Are you using layout adjustment algorithms? (do you manage node insertions or expansions repairing the layout dynamically?) -Any form of soft relaxation or priority weights? -It will support node aliasing? It will support labelling modes? -Have you experimented with triangles or more general polygons? -Do the visualization updates automatically when a user modify a method in a browser? -Do you use MudPie? It will include inheritance or loose method dependencies?
Thanks in advance
Hernán
2009/7/16 David Goehrig <dave@nexttolast.com> Hey Pharoers,
I've been working on a little project for the past couple days, and now that I have something of a tangible result, I'm going to share the first screen grab.
What I've been working on is a visualization tool for analyzing the relationships between Classes and the contents of their CompiledMethods.
In the attached screen shot, the TPureBehavior circle in the middle is the root node, and all of the radial nodes are Classes referred to by the CompiledMethods associated with TPureBehavior. Each of these classes is bound to a literal in one of the CompiledMethods. The radius of the circle is directly proportional to the number of methods that Class has. IdentitySet has 2 compiled methods for example, whereas ChangeSet has 124 methods.
Once I get collapsing working, and add some trace lines (so that when you've expanded and expanded and expanded it is obvious who is connected to who), I'll post this code somewhere. But what is incredible is how quickly things get really really deeply interconnected things get.
Dave
-- -=-=-=-=-=-=-=-=-=-=- 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Doru spent already a lot of effort.
me as well. Mondrian works on Pharo. Just doit: ScriptLoader new installer ss project: 'Mondrian'; install: 'MondrianLoader'. (Smalltalk at: #MondrianLoader) perform: #loadMondrian; perform: #loadMorphicAnnouncementFix Cheers, Alexandre
Hello David, It seems you have an interesting tool. I have a couple of questions about Territory, and may be you want to comment more about its internal architecture:
-Do you use constraints solving techniques to find optimal geometric layouts? (or tried larger object graphs?) -Are you using layout adjustment algorithms? (do you manage node insertions or expansions repairing the layout dynamically?) -Any form of soft relaxation or priority weights? -It will support node aliasing? It will support labelling modes? -Have you experimented with triangles or more general polygons? -Do the visualization updates automatically when a user modify a method in a browser? -Do you use MudPie? It will include inheritance or loose method dependencies?
Thanks in advance
Hernán
2009/7/16 David Goehrig <dave@nexttolast.com> Hey Pharoers,
I've been working on a little project for the past couple days, and now that I have something of a tangible result, I'm going to share the first screen grab.
What I've been working on is a visualization tool for analyzing the relationships between Classes and the contents of their CompiledMethods.
In the attached screen shot, the TPureBehavior circle in the middle is the root node, and all of the radial nodes are Classes referred to by the CompiledMethods associated with TPureBehavior. Each of these classes is bound to a literal in one of the CompiledMethods. The radius of the circle is directly proportional to the number of methods that Class has. IdentitySet has 2 compiled methods for example, whereas ChangeSet has 124 methods.
Once I get collapsing working, and add some trace lines (so that when you've expanded and expanded and expanded it is obvious who is connected to who), I'll post this code somewhere. But what is incredible is how quickly things get really really deeply interconnected things get.
Dave
-- -=-=-=-=-=-=-=-=-=-=- 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thanks Alexandre! This actually works in one of my images, after a few tweaks. I finally figured out what was causing the issue and it had to do with my old image had a half installed version of Mondrian that couldn't unload. That said, Mondrian is conceptually so far away from what I'm aiming for I'm not likely to ever use it :) Dave On Mon, Jul 20, 2009 at 10:01 AM, Alexandre Bergel <alexandre@bergel.eu>wrote:
Doru spent already a lot of effort.
me as well.
Mondrian works on Pharo. Just doit:
ScriptLoader new installer ss project: 'Mondrian'; install: 'MondrianLoader'. (Smalltalk at: #MondrianLoader) perform: #loadMondrian; perform: #loadMorphicAnnouncementFix
Cheers, Alexandre
Hello David, It seems you have an interesting tool. I have a couple of questions about Territory, and may be you want to comment more about its internal architecture:
-Do you use constraints solving techniques to find optimal geometric layouts? (or tried larger object graphs?) -Are you using layout adjustment algorithms? (do you manage node insertions or expansions repairing the layout dynamically?) -Any form of soft relaxation or priority weights? -It will support node aliasing? It will support labelling modes? -Have you experimented with triangles or more general polygons? -Do the visualization updates automatically when a user modify a method in a browser? -Do you use MudPie? It will include inheritance or loose method dependencies?
Thanks in advance
Hernán
2009/7/16 David Goehrig <dave@nexttolast.com> Hey Pharoers,
I've been working on a little project for the past couple days, and now that I have something of a tangible result, I'm going to share the first screen grab.
What I've been working on is a visualization tool for analyzing the relationships between Classes and the contents of their CompiledMethods.
In the attached screen shot, the TPureBehavior circle in the middle is the root node, and all of the radial nodes are Classes referred to by the CompiledMethods associated with TPureBehavior. Each of these classes is bound to a literal in one of the CompiledMethods. The radius of the circle is directly proportional to the number of methods that Class has. IdentitySet has 2 compiled methods for example, whereas ChangeSet has 124 methods.
Once I get collapsing working, and add some trace lines (so that when you've expanded and expanded and expanded it is obvious who is connected to who), I'll post this code somewhere. But what is incredible is how quickly things get really really deeply interconnected things get.
Dave
-- -=-=-=-=-=-=-=-=-=-=- 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
On Jul 20, 2009, at 7:39 PM, David Goehrig wrote:
Thanks Alexandre!
This actually works in one of my images, after a few tweaks. I finally figured out what was causing the issue and it had to do with my old image had a half installed version of Mondrian that couldn't unload.
That said, Mondrian is conceptually so far away from what I'm aiming for I'm not likely to ever use it :)
Why? Because you can script your visualization and try all kind of them. Mondrian a visualisation engine. Soon with lumiere developed by fernando you will be able to script 3d objects.
Dave
On Mon, Jul 20, 2009 at 10:01 AM, Alexandre Bergel <alexandre@bergel.eu
wrote: Doru spent already a lot of effort.
me as well.
Mondrian works on Pharo. Just doit:
ScriptLoader new installer ss project: 'Mondrian'; install: 'MondrianLoader'. (Smalltalk at: #MondrianLoader) perform: #loadMondrian; perform: #loadMorphicAnnouncementFix
Cheers, Alexandre
Hello David, It seems you have an interesting tool. I have a couple of questions about Territory, and may be you want to comment more
about
its internal architecture:
-Do you use constraints solving techniques to find optimal geometric layouts? (or tried larger object graphs?) -Are you using layout adjustment algorithms? (do you manage node insertions or expansions repairing the layout dynamically?) -Any form of soft relaxation or priority weights? -It will support node aliasing? It will support labelling modes? -Have you experimented with triangles or more general polygons? -Do the visualization updates automatically when a user modify a method in a browser? -Do you use MudPie? It will include inheritance or loose method dependencies?
Thanks in advance
Hernán
2009/7/16 David Goehrig <dave@nexttolast.com> Hey Pharoers,
I've been working on a little project for the past couple days, and now that I have something of a tangible result, I'm going to share the first screen grab.
What I've been working on is a visualization tool for analyzing the relationships between Classes and the contents of their CompiledMethods.
In the attached screen shot, the TPureBehavior circle in the middle is the root node, and all of the radial nodes are Classes referred to by the CompiledMethods associated with TPureBehavior. Each of these classes is bound to a literal in one of the CompiledMethods. The radius of the circle is directly proportional to the number of methods that Class has. IdentitySet has 2 compiled methods for example, whereas ChangeSet has 124 methods.
Once I get collapsing working, and add some trace lines (so that when you've expanded and expanded and expanded it is obvious who is connected to who), I'll post this code somewhere. But what is incredible is how quickly things get really really deeply interconnected things get.
Dave
-- -=-=-=-=-=-=-=-=-=-=- 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- -=-=-=-=-=-=-=-=-=-=- 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
On Mon, Jul 20, 2009 at 5:12 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Why? Because you can script your visualization and try all kind of them. Mondrian a visualisation engine. Soon with lumiere developed by fernando you will be able to script 3d objects.
Because the tools I'm working on are more geared more towards live editing of classes and object method dictionaries than modeling and visualization. For example, if a circle represents a class's method dictionary, you can right click on it to see the list of messages associated with its CompiledMethods. Then you can right click on any of the CompiledMethods to bring up an editor, and alter the contents of the method, recompile, and the relationships will change accordingly. Similarly, you can reorganize methods by dragging and dropping them into different classes, etc. The design and structure of Mondrian makes it terribly difficult to produce that sort of interface without doing as much work as it would to just write it from scratch :) Dave -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
May be you should have a look at Glamour because you can script UI. Stef On Jul 20, 2009, at 11:36 PM, David Goehrig wrote:
On Mon, Jul 20, 2009 at 5:12 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Why? Because you can script your visualization and try all kind of them. Mondrian a visualisation engine. Soon with lumiere developed by fernando you will be able to script 3d objects.
Because the tools I'm working on are more geared more towards live editing of classes and object method dictionaries than modeling and visualization.
For example, if a circle represents a class's method dictionary, you can right click on it to see the list of messages associated with its CompiledMethods. Then you can right click on any of the CompiledMethods to bring up an editor, and alter the contents of the method, recompile, and the relationships will change accordingly. Similarly, you can reorganize methods by dragging and dropping them into different classes, etc.
The design and structure of Mondrian makes it terribly difficult to produce that sort of interface without doing as much work as it would to just write it from scratch :)
Dave
-- -=-=-=-=-=-=-=-=-=-=- 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
sorry steff once again its nothing like what I'm working on :) Dave On Tue, Jul 21, 2009 at 5:04 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
May be you should have a look at Glamour because you can script UI.
Stef
On Jul 20, 2009, at 11:36 PM, David Goehrig wrote:
On Mon, Jul 20, 2009 at 5:12 PM, Stéphane Ducasse < stephane.ducasse@inria.fr
wrote:
Why? Because you can script your visualization and try all kind of them. Mondrian a visualisation engine. Soon with lumiere developed by fernando you will be able to script 3d objects.
Because the tools I'm working on are more geared more towards live editing of classes and object method dictionaries than modeling and visualization.
For example, if a circle represents a class's method dictionary, you can right click on it to see the list of messages associated with its CompiledMethods. Then you can right click on any of the CompiledMethods to bring up an editor, and alter the contents of the method, recompile, and the relationships will change accordingly. Similarly, you can reorganize methods by dragging and dropping them into different classes, etc.
The design and structure of Mondrian makes it terribly difficult to produce that sort of interface without doing as much work as it would to just write it from scratch :)
Dave
-- -=-=-=-=-=-=-=-=-=-=- 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
I imagine :) Fernando told me that he wants to program in 3d its objects/class so I imagine that what you want is the "same" looking at browsing coding in a different way. Stef
On Tue, Jul 21, 2009 at 7:40 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Fernando told me that he wants to program in 3d its objects/class so I imagine that what you want is the "same" looking at browsing coding in a different way.
Pretty much along those lines yes. What I'm working on is building the sorts of systems that work well for programming "in the round" where you cover the walls of your meeting room with projectors, and multiple groups of people can directly collaborate on code, test it, and run it right there. The classic code browser approach doesn't lend itself to multiple people editing and manipulating the code at the same time, it is designed for a single user on a screen with limited real estate. The other issue is that the browser environment hides too much complexity, and so it doesn't scale up when you can use gigantic displays with infinite virtual space. I've done 2 initial versions of the interface in Javascript and Forth, and am working on porting the environment to Pharo. I think Pharo Smalltalk + a new editor designed for tele-team programming would be a very compelling platform for a lot of distributed projects. The past few years, every project I've consulted for involved programmers in at least 5 time zones. Our tools really need to better reflect that reality. :) Dave -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
I would really to see that. Recently I was thinking that I would like to have a "daisy" browser one code pane in the middle and around Large icons for sender, implementer .. results. On Jul 21, 2009, at 5:17 PM, David Goehrig wrote:
On Tue, Jul 21, 2009 at 7:40 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Fernando told me that he wants to program in 3d its objects/class so I imagine that what you want is the "same" looking at browsing coding in a different way.
Pretty much along those lines yes. What I'm working on is building the sorts of systems that work well for programming "in the round" where you cover the walls of your meeting room with projectors, and multiple groups of people can directly collaborate on code, test it, and run it right there. The classic code browser approach doesn't lend itself to multiple people editing and manipulating the code at the same time, it is designed for a single user on a screen with limited real estate.
The other issue is that the browser environment hides too much complexity, and so it doesn't scale up when you can use gigantic displays with infinite virtual space. I've done 2 initial versions of the interface in Javascript and Forth, and am working on porting the environment to Pharo. I think Pharo Smalltalk + a new editor designed for tele-team programming would be a very compelling platform for a lot of distributed projects. The past few years, every project I've consulted for involved programmers in at least 5 time zones. Our tools really need to better reflect that reality. :)
Dave -- -=-=-=-=-=-=-=-=-=-=- 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
On Mon, Jul 20, 2009 at 5:12 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Why? Because you can script your visualization and try all kind of them. Mondrian a visualisation engine. Soon with lumiere developed by fernando you will be able to script 3d objects.
Because the tools I'm working on are more geared more towards live editing of classes and object method dictionaries than modeling and visualization.
Mondrian provide advanced facilities for interaction. You can easily switch from one few to another, update the view after having selected an action.
For example, if a circle represents a class's method dictionary, you can right click on it to see the list of messages associated with its CompiledMethods. Then you can right click on any of the CompiledMethods to bring up an editor, and alter the contents of the method, recompile, and the relationships will change accordingly. Similarly, you can reorganize methods by dragging and dropping them into different classes, etc.
dragging and dropping is currently not supported. Maybe this is a stopper.
The design and structure of Mondrian makes it terribly difficult to produce that sort of interface without doing as much work as it would to just write it from scratch :)
There is a lack of documentation, for sure. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (5)
-
Alexandre Bergel -
David Goehrig -
Hernán Morales Durand -
Nicolas Cellier -
Stéphane Ducasse