[ANN] Traits installer/uninstaller utility

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  
[hidden email] - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Johan Fabry
Sent: Saturday, May 15, 2010 7:37 PM
To: A friendly place where any question about pharo is welcome; [hidden email]
Subject: [Pharo-project] [ANN] Traits installer/uninstaller utility

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  
[hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile




_______________________________________________
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

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?

Cheers,
Doru


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

--
www.tudorgirba.com

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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  
[hidden email] - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

> I took a quick look and it looks interesting.

Thanks :-)

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  
[hidden email] - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Yes it would be good to have better trait integration. In the mean time TraitsApplication is your man :-)

On 16 May 2010, at 04:11, Stéphane Ducasse wrote:

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

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




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi,


On 16 May 2010, at 19:43, Johan Fabry wrote:

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).

Cheers,
Doru



--
www.tudorgirba.com

"Next time you see your life passing by, say 'hi' and get to know her."




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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  
[hidden email] - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project