Hi Bill, thanks for the good wishes :-) Regarding rendering times, I dont have any problems, usual interactions are snappy. Have a look at the screencasts to see the tool in action, especially the second one ( http://pleiad.dcc.uchile.cl/research/software/aspectmaps_struct_zoom ) to see what I mean. AspectMaps is built using Moose ( http://www.moosetechnology.org ) and more specifically using an extended FAMIX model of Java as the data structure and the Mondrian ( http://www.moosetechnology.org/tools/mondrian ) visualization engine to do the visualization. I could not have done it without these tools and the guys behind the tools helping me out where I needed :-) So if you want to do some kind of visualization of data I highly recommend you to check this out! On 15 May 2010, at 21:04, Schwab,Wilhelm K wrote:

Johan,

Best of luck with it! Taking a really quick look at your web site, this looks like something that could take a lot of time rendering graphics. Is drawing time a problem for you? Did you do anything in particular to avoid bottlenecks? I ask because I am starting to port some of my graphical code to Pharo; some of it is going from home-grown to using gnuplot, but elsewhere I was able to simply pass (Windows speak) an HDC into a function in a DLL and do a lot of rendering fairly quickly as a result. I am still looking for how to approach that in Pharo+Linux. I am starting to make my own .so's with success, but have yet to produce graphics that way.

Bill

-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

On May 16, 2010, at 9:48 AM, Tudor Girba wrote:

Hi Johan,

I took a quick look and it looks interesting.

Just a note for discussion. Executing "AspectMapsUI open" installs the traits. One of your trait extension is adding TAMStructuralZoom to FAMIXClass.

Now, when I browse the FAMIXClass, I get this in the browser:

----- FAMIXType subclass: #FAMIXClass uses: TAMStructuralZoom instanceVariableNames: 'isInterface' classVariableNames: '' poolDictionaries: '' category: 'Famix-Core' -----

There are two problems with this:

1. So, now if I just want to edit the base class, I have to take care and delete the Trait before, because the Trait is part of the definition.

This is a limitation of the browser, but we have to pay attention to it.

2. If you look in Monticello, the base package (FAMIX-Core in this case) is not dirty, but if you explicitly look for Changes, it gets dirty. I do not know how this could be solved. Perhaps we need extension as first class?

this happens also for none trait. One day we will have to do a large pass on monticello.

Cheers, Doru

On 16 May 2010, at 02:36, Johan Fabry wrote:

...

Hi all,

this is a small package that I wrote after doing a traits-based refactoring of AspectMaps (Plug: Check out AspectMaps for a cool visualization of Aspects. http://pleiad.cl/aspectmaps. It has nice screencasts. All comments welcome!)

AspectMaps extends a number of classes of FAMIX to do its thing, using standard class extensions. This works OK when you are not using traits. But when using a trait, you need to redef the class, i.e. change the original package (in this case one of the moose packages). A big no-no. This kind of change should also be encapusulated in the AspectMaps package, but currently this is not possible. So, as long as traits and packages dont play well together, these kinds of refactorings are out.

However not so when you are using the TraitsApplication package. This package provides a means to programmatically install/uninstall traits. Call it in a post-load action on a package (if such a thing exists), in a class initialize method, et cetera (for AspectMaps I do it in the AspectMaps>>open method). I thought this could be useful to some members of the community so I am releasing it publicly. You can find it at http://www.squeaksource.com/TraitsApplication

CAVEAT: This is a quick implementation, it is non-optimal. It can be made much more elegant, but that requires time that I dont have right now :-(. I does not handle fancy trait compositions (yet). I give no guarantees other than that 1) it passes all of its tests 2) it works for me :-)

So check it out. Comments are welcome! -- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

-- www.tudorgirba.com

"Speaking louder won't make the point worthier."

_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

On 16 May 2010, at 03:48, Tudor Girba wrote:

I took a quick look and it looks interesting.

Thanks :-)

Just a note for discussion. Executing "AspectMapsUI open" installs the traits. One of your trait extension is adding TAMStructuralZoom to FAMIXClass.

Now, when I browse the FAMIXClass, I get this in the browser:

----- FAMIXType subclass: #FAMIXClass uses: TAMStructuralZoom instanceVariableNames: 'isInterface' classVariableNames: '' poolDictionaries: '' category: 'Famix-Core' -----

There are two problems with this:

1. So, now if I just want to edit the base class, I have to take care and delete the Trait before, because the Trait is part of the definition.

This is a limitation of the browser, but we have to pay attention to it.

My philosophy here is to not hide anything from the developer, which is why the Trait is part of the definition. What you see is what you get. Delete the Trait when editing the base class and it goes away. What you see is what you get. So just edit the class as you want to, you can even add new Traits manually. You can always remove the TAMStructuralZoom trait (or any other trait actually) using the traits uninstaller.

2. If you look in Monticello, the base package (FAMIX-Core in this case) is not dirty, but if you explicitly look for Changes, it gets dirty. I do not know how this could be solved. Perhaps we need extension as first class?

OK this should not happen. I tried to be as close to how the browser works when redefining a class (the redefinition even gets recorded in changes) because I want to avoid breaking any magic that is going on. But apparently I did not succeed completely. If any Monticello magicians can tell me what incantation to add I would be most happy to oblige! -- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

On 16 May 2010, at 19:30, Tudor Girba wrote:

...

My philosophy here is to not hide anything from the developer, which is why the Trait is part of the definition. What you see is what you get. Delete the Trait when editing the base class and it goes away. What you see is what you get.

So just edit the class as you want to, you can even add new Traits manually. You can always remove the TAMStructuralZoom trait (or any other trait actually) using the traits uninstaller.

I know that, but I was just pointing out that if I change the base class and commit while your code is loaded, I publish unwillingly your trait. So, when your code is loaded I have to be careful to first remove the trait and only afterwards publish my change.

This is a severe limitation and it stems from the Trait definition being tightly coupled with the class definition (both in the model and in the browser).

OK so we are in agreement :-) -- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile