Hi Guys,
I looked a bit in more detail at the class extensions problem. Here I bring a bit more to the discussion table.
I attach a Snaut screenshot of an analysis session of Hapax + Code Foo.
(seems attachment is too big for the mailinglist so here's a link: http://www.inf.unisi.ch/phd/lungu/files/ClassExtensionsInMoose.png)
The panel on the right is the detail of the 91 invocations abstracted in the high-level dependency between Hapax Development and Visual Works. To the right of every method which is extended in a different package thabn Base VisualWorks you can see that package. What you will see is that althoug most of those dependencies are defined in othe packages than VisualWorks Base they still are abstracted in the relationship between Hapax and VisualWorks base. You will see that there is a dependency between hapax and Number>>pythag: which methoid is defined in Hapax itself.
The reason is the following.
A method, even when it is an extension (isExtension is True) belongsTo a class. And the class, logically, belongs to the namespace where it was initially defined and is, logically, packaged in the package it was initially defined in. When I compute the high-level depedencies in softwarenaut i aggregate them from methods to classes and from there up along the namespace of package hierarchy. Since the extended methods are placed in their original classes, I end up with dependencies between the wrong packages.
The high-level dependencies in softwarenaut are wrong because the model can not express the existence of class extensions.
I can see two solutions:
- we introduce a FAMIXClassExtension as an explicit entity which is a class which has a reference to the extended class. maybe we can even introduce a new relationship which is Class Extension. - we piggyback the class extensions on top of the classes in a similar way the metaclasses are implemented. In our example, for Collection we would define a Collection class in CodeFoo, SqueakExtensions, EyeSee and ech one of these would only contain the methods that it defines.
I am interested if anybody else is interested in this. And I want to hear your opinions.
Cheers, Mircea.
On May 26, 2009, at 6:14 PM, Mircea Lungu wrote:
Hi Guys,
I looked a bit in more detail at the class extensions problem. Here I bring a bit more to the discussion table.
I attach a Snaut screenshot of an analysis session of Hapax + Code Foo.
(seems attachment is too big for the mailinglist so here's a link: http://www.inf.unisi.ch/phd/lungu/files/ClassExtensionsInMoose.png)
The panel on the right is the detail of the 91 invocations abstracted in the high-level dependency between Hapax Development and Visual Works. To the right of every method which is extended in a different package thabn Base VisualWorks you can see that package. What you will see is that althoug most of those dependencies are defined in othe packages than VisualWorks Base they still are abstracted in the relationship between Hapax and VisualWorks base. You will see that there is a dependency between hapax and Number>>pythag: which methoid is defined in Hapax itself.
The reason is the following.
A method, even when it is an extension (isExtension is True) belongsTo a class. And the class, logically, belongs to the namespace where it was initially defined and is, logically, packaged in the package it was initially defined in. When I compute the high- level depedencies in softwarenaut i aggregate them from methods to classes and from there up along the namespace of package hierarchy. Since the extended methods are placed in their original classes, I end up with dependencies between the wrong packages.
The high-level dependencies in softwarenaut are wrong because the model can not express the existence of class extensions.
why do you say that? I'm confused? Can we get the class extensions from a famix class?
I can see two solutions:
- we introduce a FAMIXClassExtension as an explicit entity which is
a class which has a reference to the extended class. maybe we can even introduce a new relationship which is Class Extension.
- we piggyback the class extensions on top of the classes in a
similar way the metaclasses are implemented. In our example, for Collection we would define a Collection class in CodeFoo, SqueakExtensions, EyeSee and ech one of these would only contain the methods that it defines.
I am interested if anybody else is interested in this. And I want to hear your opinions.
Yes I'm. We really want to use Moose on pharo and we have to take into account class extensions. May be the extensions we did in cook are dealing with them. I' m confused right now. Jannick, simon can you answer? Now the problem is that cook extensions as implemented in VW are not really good. Jannik rewrote it for Pharo.
Stef
Cheers, Mircea. _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
- we introduce a FAMIXClassExtension as an explicit entity which is
a class which has a reference to the extended class. maybe we can even introduce a new relationship which is Class Extension.
We could have something like:
FAMIXAssociation subclass: #FAMIXClassExtension instanceVariableNames: 'extendedClass methods belongTo' classVariableNames: '' poolDictionaries: '' category: 'Famix-Core'
belongTo will then point to the extending package
Cheers, Alexandre
Ciao Alex,
We could have something like:
FAMIXAssociation subclass: #FAMIXClassExtension instanceVariableNames: 'extendedClass methods belongTo' classVariableNames: '' poolDictionaries: '' category: 'Famix-Core'
belongTo will then point to the extending package
Currently an extended method has its own packagedIn which is different than its class's packagedIn. So the informatoin about the package in which the extension resides is there, just not explicit. What you propose with the association is a step further towards clarity by making the relationship an entity.
What I was thinking about was a step even further. Making both the 'relationship' and the 'class extension' entities. Like this:
FAMIXClass subclass: #FAMIXClassExtension instanceVariableNames: '' classVariableNames: ''
poolDictionaries: '' category: 'Famix-Core'
and
FAMIXAssociation subclass: #FAMIXExtensionRelationship instanceVariableNames: 'extended extension' classVariableNames: '' poolDictionaries: '' category: 'Famix-Core' - extended would point to a FAMIXClass - extension would point to a FAMIXClassExtension
This former approach sees a class extension as a class-like entity which contains the extended methods. The advantage is that this makes dependency analysis more uniform. We then can treat extended methods just like normal methods when aggregating invocations from the method level to the package level. For example:
aMEthod belongsTo packagedIn
will give us the package in which the method was defined, independently of wether it is an extension or not.
One thing which I think will be easier this way is visualizing extension relationships. Generating a polymetric view of the dependencies between two packages like the one in the figure will be straightforward since we have entities for both the extensions and the original classes.
Does my point make sense?
Cheers, Mircea.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I understand your point
FAMIXClass subclass: #FAMIXClassExtension instanceVariableNames: '' classVariableNames: ''
poolDictionaries: '' category: 'Famix-Core'
I fear this may be problematic. In the Pharo version of Moose (I haven't checked for VW), FAMIXClass is referenced in a number of places. For example: - FAMIXInvocation>>isAPotentialIncomingInvocationFor: contains 'invoRVar class = FAMIXClass' - FAMIXClass>>isADirectSubclassOf: contains 'aClass class = FAMIXClass'
This suggest that instances of FAMIXClassExtension will probably not be have the same effect when a FAMIXClass is expected. It does not seem to be a big deal though. But why FAMIXClass>>isExtended is not enough?
Cheers, Alexandre
Hi Mircea
Do you have some doc on the principles behind Software Naut/way to use it. Because I always found it obscure yet I'm interested. Actually I have been playing with Mondrian in the past few days to get something more or less similar (at least in goal terms) with software naut.
So I stumble upon the same problem as you when dealing with dependencies between packages. Sure the possibility of having ClassExtension and ExtensionRelationship is interesting in the long term. In particular it could simplify some viz as you noticed (Jannik had this problem in DSM, where we want to show class extensions too).
Meanwhile, I will explain the short-term solution in Famix3 with the Pharo importer. FamixMethod has a #parentPackage attribute (should be #packagedIn in Famix2) which points to the most specific package it belongs to. If it's an ordinary method, it points to the same package as its parent class (might be room for space optimization here). If it's a class extension, then it points to the package which makes the extension. This is detected and done by the Smalltalk importer in Pharo. I dont know whether this is the case in VW with Famix2, but it should be possible to do the same (since FAMIX2Method also has a packagedIn attribute)
When looking for dependencies, I start from the packages down to the methods, hence easily check whether a method is part of the package or part of a class extensions. This is enough for the task at hand, but might be cumbersome for other things (where having first-class class extensions would help).
In the near time, two areas which need improvement: - the way the importer currently works, it takes into account class extensions made by other packages to explicitly imported packages, but does not import class extension made by the imported packages to external packages. - refine the Famix-Smalltalk API to easily access class extension from/ to FamixClass and FamixPackage (this is partially done, but only as a bi-relation between packages and extended classes, we dont have the methods)
So if you have time to do a clean improvement of Famix for extensions, do it (there might be some gotcha points as Alex notices). I believe it is possible to find a work around with the current model.
On 27 mai 09, at 13:19, Alexandre Bergel wrote:
I understand your point
FAMIXClass subclass: #FAMIXClassExtension instanceVariableNames: '' classVariableNames: ''
poolDictionaries: '' category: 'Famix-Core'
I fear this may be problematic. In the Pharo version of Moose (I haven't checked for VW), FAMIXClass is referenced in a number of places. For example:
- FAMIXInvocation>>isAPotentialIncomingInvocationFor: contains
'invoRVar class = FAMIXClass'
- FAMIXClass>>isADirectSubclassOf: contains 'aClass class =
FAMIXClass'
This suggest that instances of FAMIXClassExtension will probably not be have the same effect when a FAMIXClass is expected. It does not seem to be a big deal though. But why FAMIXClass>>isExtended is not enough?
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
On 27 mai 09, at 15:24, Simon Denier wrote:
In the near time, two areas which need improvement:
- the way the importer currently works, it takes into account class
extensions made by other packages to explicitly imported packages, but does not import class extension made by the imported packages to external packages.
- refine the Famix-Smalltalk API to easily access class extension
from/to FamixClass and FamixPackage (this is partially done, but only as a bi-relation between packages and extended classes, we dont have the methods)
Did that today (not the importer, just the API) and updated the tests in consequence.
As ref, here is the API in PhaMoose/Famix3
FAMIXMethod #isExtension "true if the method is a class extension (parentPackage retrieves the package which makes the extension)"
FAMIXClass #isExtended true is the class is extended by other packages, i.e. has some class extensions #extendedInPackages returns the packages which extend this class #extendedMethods returns the methods which are extensions of this class #localMethods, #definedMethods (alias, deprecated) returns locally defined methods, i.e. defined in the same package as the class
FAMIXClass#methods returns all methods defined in a class, including class extensions.
FAMIXPackage #extensionMethods returns the class extensions made by this package #localMethods returns methods locally defined in the package #extensionClasses returns classes extended by THIS package #localClasses, #definedClasses (alias, deprecated) returns classes defined in the package (including extenDED classes) #extendedClasses returns local classes extended by OTHER packages
FAMIXPackage#classes returns localClasses FAMIXPackage#methods returns localMethods and extensionMethods
I hope it clears a few things. I tried to get a concise yet consistent name format, but you are welcome to comment. In particular, some confusion is possible between #extensionClasses and #extendedClasses
On 27 mai 09, at 13:19, Alexandre Bergel wrote:
I understand your point
FAMIXClass subclass: #FAMIXClassExtension instanceVariableNames: '' classVariableNames: ''
poolDictionaries: '' category: 'Famix-Core'
I fear this may be problematic. In the Pharo version of Moose (I haven't checked for VW), FAMIXClass is referenced in a number of places. For example:
- FAMIXInvocation>>isAPotentialIncomingInvocationFor: contains
'invoRVar class = FAMIXClass'
- FAMIXClass>>isADirectSubclassOf: contains 'aClass class =
FAMIXClass'
This suggest that instances of FAMIXClassExtension will probably not be have the same effect when a FAMIXClass is expected. It does not seem to be a big deal though. But why FAMIXClass>>isExtended is not enough?
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
-- Simon
I am glad to see your fixes. Your tests go green for me.
Cheers, Alexandre
On 28 May 2009, at 11:53, Simon Denier wrote:
On 27 mai 09, at 15:24, Simon Denier wrote:
In the near time, two areas which need improvement:
- the way the importer currently works, it takes into account class
extensions made by other packages to explicitly imported packages, but does not import class extension made by the imported packages to external packages.
- refine the Famix-Smalltalk API to easily access class extension
from/to FamixClass and FamixPackage (this is partially done, but only as a bi-relation between packages and extended classes, we dont have the methods)
Did that today (not the importer, just the API) and updated the tests in consequence.
As ref, here is the API in PhaMoose/Famix3
FAMIXMethod #isExtension "true if the method is a class extension (parentPackage retrieves the package which makes the extension)"
FAMIXClass #isExtended true is the class is extended by other packages, i.e. has some class extensions #extendedInPackages returns the packages which extend this class #extendedMethods returns the methods which are extensions of this class #localMethods, #definedMethods (alias, deprecated) returns locally defined methods, i.e. defined in the same package as the class
FAMIXClass#methods returns all methods defined in a class, including class extensions.
FAMIXPackage #extensionMethods returns the class extensions made by this package #localMethods returns methods locally defined in the package #extensionClasses returns classes extended by THIS package #localClasses, #definedClasses (alias, deprecated) returns classes defined in the package (including extenDED classes) #extendedClasses returns local classes extended by OTHER packages
FAMIXPackage#classes returns localClasses FAMIXPackage#methods returns localMethods and extensionMethods
I hope it clears a few things. I tried to get a concise yet consistent name format, but you are welcome to comment. In particular, some confusion is possible between #extensionClasses and #extendedClasses
On 27 mai 09, at 13:19, Alexandre Bergel wrote:
I understand your point
FAMIXClass subclass: #FAMIXClassExtension instanceVariableNames: '' classVariableNames: ''
poolDictionaries: '' category: 'Famix-Core'
I fear this may be problematic. In the Pharo version of Moose (I haven't checked for VW), FAMIXClass is referenced in a number of places. For example:
- FAMIXInvocation>>isAPotentialIncomingInvocationFor: contains
'invoRVar class = FAMIXClass'
- FAMIXClass>>isADirectSubclassOf: contains 'aClass class =
FAMIXClass'
This suggest that instances of FAMIXClassExtension will probably not be have the same effect when a FAMIXClass is expected. It does not seem to be a big deal though. But why FAMIXClass>>isExtended is not enough?
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 29 mai 09, at 00:54, Alexandre Bergel wrote:
I am glad to see your fixes. Your tests go green for me.
Well, they should not :) Two tests should fail because I didnt patch the importer yet.
Cheers, Alexandre
On 28 May 2009, at 11:53, Simon Denier wrote:
On 27 mai 09, at 15:24, Simon Denier wrote:
In the near time, two areas which need improvement:
- the way the importer currently works, it takes into account
class extensions made by other packages to explicitly imported packages, but does not import class extension made by the imported packages to external packages.
- refine the Famix-Smalltalk API to easily access class extension
from/to FamixClass and FamixPackage (this is partially done, but only as a bi-relation between packages and extended classes, we dont have the methods)
Did that today (not the importer, just the API) and updated the tests in consequence.
As ref, here is the API in PhaMoose/Famix3
FAMIXMethod #isExtension "true if the method is a class extension (parentPackage retrieves the package which makes the extension)"
FAMIXClass #isExtended true is the class is extended by other packages, i.e. has some class extensions #extendedInPackages returns the packages which extend this class #extendedMethods returns the methods which are extensions of this class #localMethods, #definedMethods (alias, deprecated) returns locally defined methods, i.e. defined in the same package as the class
FAMIXClass#methods returns all methods defined in a class, including class extensions.
FAMIXPackage #extensionMethods returns the class extensions made by this package #localMethods returns methods locally defined in the package #extensionClasses returns classes extended by THIS package #localClasses, #definedClasses (alias, deprecated) returns classes defined in the package (including extenDED classes) #extendedClasses returns local classes extended by OTHER packages
FAMIXPackage#classes returns localClasses FAMIXPackage#methods returns localMethods and extensionMethods
I hope it clears a few things. I tried to get a concise yet consistent name format, but you are welcome to comment. In particular, some confusion is possible between #extensionClasses and #extendedClasses
On 27 mai 09, at 13:19, Alexandre Bergel wrote:
I understand your point
FAMIXClass subclass: #FAMIXClassExtension instanceVariableNames: '' classVariableNames: ''
poolDictionaries: '' category: 'Famix-Core'
I fear this may be problematic. In the Pharo version of Moose (I haven't checked for VW), FAMIXClass is referenced in a number of places. For example:
- FAMIXInvocation>>isAPotentialIncomingInvocationFor: contains
'invoRVar class = FAMIXClass'
- FAMIXClass>>isADirectSubclassOf: contains 'aClass class =
FAMIXClass'
This suggest that instances of FAMIXClassExtension will probably not be have the same effect when a FAMIXClass is expected. It does not seem to be a big deal though. But why FAMIXClass>>isExtended is not enough?
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
I couldn't easily spot the tests related to your extension. I manually identified few of them. Luckily, I found only the green ones.
Alexandre
On 29 May 2009, at 05:35, Simon Denier wrote:
On 29 mai 09, at 00:54, Alexandre Bergel wrote:
I am glad to see your fixes. Your tests go green for me.
Well, they should not :) Two tests should fail because I didnt patch the importer yet.
Cheers, Alexandre
On 28 May 2009, at 11:53, Simon Denier wrote:
On 27 mai 09, at 15:24, Simon Denier wrote:
In the near time, two areas which need improvement:
- the way the importer currently works, it takes into account
class extensions made by other packages to explicitly imported packages, but does not import class extension made by the imported packages to external packages.
- refine the Famix-Smalltalk API to easily access class extension
from/to FamixClass and FamixPackage (this is partially done, but only as a bi-relation between packages and extended classes, we dont have the methods)
Did that today (not the importer, just the API) and updated the tests in consequence.
As ref, here is the API in PhaMoose/Famix3
FAMIXMethod #isExtension "true if the method is a class extension (parentPackage retrieves the package which makes the extension)"
FAMIXClass #isExtended true is the class is extended by other packages, i.e. has some class extensions #extendedInPackages returns the packages which extend this class #extendedMethods returns the methods which are extensions of this class #localMethods, #definedMethods (alias, deprecated) returns locally defined methods, i.e. defined in the same package as the class
FAMIXClass#methods returns all methods defined in a class, including class extensions.
FAMIXPackage #extensionMethods returns the class extensions made by this package #localMethods returns methods locally defined in the package #extensionClasses returns classes extended by THIS package #localClasses, #definedClasses (alias, deprecated) returns classes defined in the package (including extenDED classes) #extendedClasses returns local classes extended by OTHER packages
FAMIXPackage#classes returns localClasses FAMIXPackage#methods returns localMethods and extensionMethods
I hope it clears a few things. I tried to get a concise yet consistent name format, but you are welcome to comment. In particular, some confusion is possible between #extensionClasses and #extendedClasses
On 27 mai 09, at 13:19, Alexandre Bergel wrote:
I understand your point
FAMIXClass subclass: #FAMIXClassExtension instanceVariableNames: '' classVariableNames: '' > poolDictionaries: '' > category: 'Famix-Core'
I fear this may be problematic. In the Pharo version of Moose (I haven't checked for VW), FAMIXClass is referenced in a number of places. For example:
- FAMIXInvocation>>isAPotentialIncomingInvocationFor: contains
'invoRVar class = FAMIXClass'
- FAMIXClass>>isADirectSubclassOf: contains 'aClass class =
FAMIXClass'
This suggest that instances of FAMIXClassExtension will probably not be have the same effect when a FAMIXClass is expected. It does not seem to be a big deal though. But why FAMIXClass>>isExtended is not enough?
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Do you have some doc on the principles behind Software Naut/way to use it. Because I always found it obscure yet I'm interested. Actually I have been playing with Mondrian in the past few days to get something more or less similar (at least in goal terms) with software naut.
Hi Simon,
I was meaning to prepare a screencast of Softwarenaut for a long time. I gave a shot at it today. Have a look at:
I hope it answers some of your Softwarenaut questions. Let me know if there is anything else you want to learn about.
Cheers, Mircea.
Nice work Mircea!
It's in the news :) http://moose.unibe.ch/news/first-softwarenaut-screentcast
Cheers, Doru
On 30 May 2009, at 20:23, Mircea Lungu wrote:
Do you have some doc on the principles behind Software Naut/way to use it. Because I always found it obscure yet I'm interested. Actually I have been playing with Mondrian in the past few days to get something more or less similar (at least in goal terms) with software naut.
Hi Simon,
I was meaning to prepare a screencast of Softwarenaut for a long time. I gave a shot at it today. Have a look at:
I hope it answers some of your Softwarenaut questions. Let me know if there is anything else you want to learn about.
Cheers, Mircea.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Hehe, thanks for announcing the news about Softwarenaut, Chief Editor :)
A nice sunday, Mircea.
On May 31, 2009, at 10:53 AM, Tudor Girba wrote:
Nice work Mircea!
It's in the news :) http://moose.unibe.ch/news/first-softwarenaut-screentcast
Cheers, Doru
On 30 May 2009, at 20:23, Mircea Lungu wrote:
Do you have some doc on the principles behind Software Naut/way to use it. Because I always found it obscure yet I'm interested. Actually I have been playing with Mondrian in the past few days to get something more or less similar (at least in goal terms) with software naut.
Hi Simon,
I was meaning to prepare a screencast of Softwarenaut for a long time. I gave a shot at it today. Have a look at:
I hope it answers some of your Softwarenaut questions. Let me know if there is anything else you want to learn about.
Cheers, Mircea.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 30 mai 09, at 20:23, Mircea Lungu wrote:
Do you have some doc on the principles behind Software Naut/way to use it. Because I always found it obscure yet I'm interested. Actually I have been playing with Mondrian in the past few days to get something more or less similar (at least in goal terms) with software naut.
Hi Simon,
I was meaning to prepare a screencast of Softwarenaut for a long time. I gave a shot at it today. Have a look at:
I hope it answers some of your Softwarenaut questions. Let me know if there is anything else you want to learn about.
Perhaps I missed the thing, but there is one item which the screencast did not answer, and this is the very first item I ask myself when looking at a snaut viz :)
So, how is the box representing a package built? What does it represent? I understood represents the size, and the inner schema looks like a treemap (but is not?), perhaps with subpackages, and some labels are chosen to decorate this box?
Another remark which came immediately viewing the cast, it's difficult to see which node you expand,
-- Simon
Hi Simon!
Thanks for the observations.
So, how is the box representing a package built? What does it represent? I understood represents the size, and the inner schema looks like a treemap (but is not?), perhaps with subpackages, and some labels are chosen to decorate this box?
I will update the screencast and explain the way the package figures are constructed. However, you were right - it's a treemap-like view which only presents the packages on the next level. Given the limitations of playing wiht fonts in HotDraw I only display the names of the packages that fit in the corresponding rectangles.
Cheers, Mircea.
-
Alexandre Bergel -
Mircea Lungu -
Simon Denier -
Stéphane Ducasse -
Tudor Girba