KnownLands: a Class dependency explorer
Locked
12
12
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
TPureBehavior.png (61K)
Re: KnownLands: a Class dependency explorer
|
|
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
On Thu, Jul 16, 2009 at 4:39 PM, Stéphane Ducasse <[hidden email]> wrote: Hi david 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. 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 Well specifically.. RBParser is there due to this comment in the code of my image: parseTreeFor: aSymbol 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 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 I've got few more images up on my blog with my off the cuff impressions of what is going on. 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
2009/7/16 David Goehrig <[hidden email]>:
> > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
>>
>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
In reply to this post by David Goehrig
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 <[hidden email] > > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
In reply to this post by David Goehrig
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
On Fri, Jul 17, 2009 at 11:23 AM, Alexandre Bergel <[hidden email]> wrote: --
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/ _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by David Goehrig
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 <[hidden email]> Hey Pharoers, _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
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 <[hidden email]> > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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 <[hidden email]> Normally mondrian has a force base layout and several others. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
In reply to this post by Stéphane Ducasse
> 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 <[hidden email]> >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
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 <[hidden email]> wrote:
-- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
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 <[hidden email] > > 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 <[hidden email]> > >> 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 > >> [hidden email] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [hidden email] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
On Mon, Jul 20, 2009 at 5:12 PM, Stéphane Ducasse <[hidden email]> wrote: --
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
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 <[hidden email] > > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
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 <[hidden email]> wrote: May be you should have a look at Glamour -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: KnownLands: a Class dependency explorer
|
|
On Tue, Jul 21, 2009 at 7:40 AM, Stéphane Ducasse <[hidden email]> wrote:
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |