Hi,
I noticed that the latest commits in Mondrian are uncommented.
Please use meaningful comments when committing. It significantly eases the tracking of what is happening in the various projects.
Cheers,
Doru
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-SmalltalkImporter
Milestone-4.3
New issue 505 by tudor.gi...(a)gmail.com: The Smalltalk importer should not
populate the default comment in FAMIXClass
http://code.google.com/p/moose-technology/issues/detail?id=505
The Smalltalk importer sets the comments to a FAMIXClass even if the
comment is the default one. This is because asking
ClassDescription>>comment returns the blank comment when empty.
I would love to see only green ticks :-)
Maybe we can remove unnecessary projects?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Begin forwarded message:
> From: Simon Denier <simon.denier(a)gmail.com>
> Date: 25 janvier 2011 23:58:09 HNEC
> To: Simon Denier <simon.denier(a)gmail.com>
> Subject: Re: MooseChef 1/4, a small DSL to query dependencies between famix entities
>
> OK, I just forgot the most important :)
> To load the package
>
> Gofer new
> squeaksource: 'Moose';
> package: 'MooseChef';
> package: 'Moose-Tests-Chef';
> load
>
>
> On 25 janv. 2011, at 23:53, Simon Denier wrote:
>
>> MooseChef is a new package which provides a small DSL to query (some of the) dependencies between famix entities. It is a replacement for the current Moose Cook project, which provides 'navigation methods' between famix entities and resides in the Famix-Extensions package.
>>
>> Basically, MooseChef provides an API with a few methods to ask a method, a class, a package, a namespace for its dependencies (invocations, inheritance, references...) to other entities at various scope (class, package, namespace). Moose Chef comes as a small set of composable queries, with a well defined meaning, which is easy to browse and understand, and reused across Famix entities through traits.
>>
>> *** Source, side, and dependencies
>> To start with, a query has a source (or receiver), that is the famix entity for which we require dependencies. Currently FamixMethod, FamixClass, FamixPackage, and FamixNamepace supports Chef queries. Relative to the source, a query has a side: it can be a query on either incoming or outgoing dependencies. Primitive queries returns a set of dependencies related to the source, that is instances of FamixAssociation: invocations, accesses, inheritances, references.
>>
>> *** Primitive queries to access dependencies as associations
>> Hence, the combination of sides and dependencies define the set of primitive queries availble for any source.
>>
>> source query[Incoming|Outgoing][Invocations|SureInvocations|Accesses|References|Inheritances].
>>
>> You can ask for example
>> aFamixMethod queryIncomingInvocations
>> but also
>> aFamixClass queryIncomingInvocations
>> aFamixPackage queryIncomingInvocations
>>
>> (Notice that a few queries do not make sense for some receiver, like for example asking a FamixMethod for its inheritances or it incoming references - in this case the convention is to return the neutral value, that is an empty collection).
>>
>> Some 'composite' queries are also defined on top: all dependencies, sure dependencies,
>> static dependencies : accesses + references + inheritances
>> sure dependencies : static + sure invocations
>> all dependencies : static + invocations
>>
>> --
>> Simon Denier
>>
>>
>>
>
> --
> Simon Denier
>
>
>
--
Simon Denier
My bad, apparently I missent half of my messages
Begin forwarded message:
> From: Simon Denier <simon.denier(a)gmail.com>
> Date: 25 janvier 2011 23:53:45 HNEC
> Cc: Simon Denier <simon.denier(a)gmail.com>
> Subject: MooseChef 2/4, querying objects and scaling
>
> Once a primitive query has been sent to a Famix entity, you can transform the query result with more refined queries.
>
> *** The other side of the dependencies
> Primitive queries retrieve the associations. However, since we already know the source, we might be interested only by the objects on the other side of the dependency. Chef provides the #opposites selector to directly retrieve the other side of the association: that is the #from side of an incoming dependency, and the #to side of an outgoing dependency.
>
> For example:
> aMethod queryIncomingInvocations opposites
> retrieves the methods calling aMethod.
>
> aMethod queryOutgoingReferences opposites
> retrieves the classes referenced by aMethod.
>
> Reminder:
> - Inheritance: from Class to Class
> - Access: from Method to Variable
> - Invocation: from Method to Method
> - Reference: from Method to Class
> (Class extension: ???)
>
>
> *** Scoping (or scaling) dependencies
> Another interesting operation is to get the dependency information at a higher granularity by changing the scope. That is, one can ask for the dependencies coming from invocations as seen at the package level. This is querying for invoked or invoking packages.
>
> Three scope operators are available on query results: atClassScope, atPackageScope, atNamespaceScope
>
> aMethod queryOutgoingReferences atPackageScope
> retrieves packages which contain classes referenced by the method.
>
> aPackage queryIncomingInvocations atClassScope
> retrieves classes which 'call' the package.
>
> The scope operators exclude self loop by default (this was also the default in Moose Cook). That is, the query result will not contain the scope of the source (you will not get something like PackageX -> PackageX in the result) (the reason for this is that algorithms do not like graphs with self loops in general). However, this could be discussed and I could easily provide a default implementation with self loops included and a refined query #withoutSelfLoops
>
>
> PS (mindnote) I might add some opposite operators to "scale down" results in some cases, like:
>
> aFamixPackage queryAllOugoingDependencies sourceClasses
> retrieves classes from the packages which are involved in outgoing dependencies. Notice it returns the source, not the opposite side of the relationship.
>
> --
> Simon Denier
>
>
>
--
Simon Denier
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Enhancement Priority-Medium Component-Glamour Milestone-4.3
New issue 504 by tudor.gi...(a)gmail.com: Finder should be customized with
the amount of fixed displayed panes
http://code.google.com/p/moose-technology/issues/detail?id=504
GLMFinder should have a way to customize the amount of fixed panes
displayed. For example, sometimes, it can be desirable to have one pane to
fill the entire space at all time.
Maybe something like:
finder := GLMFinder new.
finder fixedSize: 2.
I believe MooseChef is now 100% functional, with a 95% complete API, and test coverage is good although not complete (I reused test classes from Moose Cook).
I think that MooseChef should replace the navigation methods provided by MooseCook in Famix-Extensions
- clean lots of stuff necessary for Moose Cook in Famix-extensions (that's a lot!)
- maybe keep and rewrite a small set of some of the most generic queries of MooseCook with a MooseChef implementation (like clientClasses) to provide short names?
- merge MooseChef into the Famix-extensions package?
*** Tips and tricks
- no test for queries on accesses right now
- self loops excluded by the scoping operators, should not be? Provide a #excludeSelfLoops instead
- be aware of the difference between querying a class and querying a package with respect to class extensions. By definition a class queries all its methods regardless of their package. A package will only query methods defined in itself, including class extensions to other packages, but not the one from other packages (that is only for invocations and accesses)
- there is currently no relation between package and namespace?
MooseChef was conceived with the intent to maximize reuse, exploit polymorphism so that the implementation is small, easy to browse, understand and debug. It is also quite verbose with long selectors so that reading the query would minimize all interpretation error. As a consequence, MooseChef is NOT:
- an optimized library for querying (composing queries create at least one collection at each step)
- a library with concise meaningful names
What I recommend is to use MooseChef as a specification library:
1) prototype your queries with MooseChef
2) then code an optimized version (without all steps induced by the Chef dataflow, with cache...), give it a short but meaningful name (like in MooseCook) as a class extension for your application
3) test your code against the MooseChef specification (you could find bugs in your code, or in Moose Chef :))
*** Why a replacement for Moose Cook?
Moose Cook was the early effort (principally by Hani) to provide a consistent API for navigation across multiple subclass of FamixEntity. As a consequence, we figure out a few choices which are outdated.
- some method names ( *referenced*/*referencing* methods) are confusing as they were defined in Famix2, implies invocations, while Famix References have now been introduced in Famix 3 as first class citizens.
- Moose Cook had to define many variants in each impacted class (basically one for each possible combination of the scope and filter queries above)
- Moose Cook also introduced quite systematically a caching system for all queries
All those points make it quite hard to understand and debug Moose Cook, as they are many methods, each defined for a specific case, which may or may not called other queries in cumulative steps. We frequently have to browse through multiple recursive calls in order to check that a query had the behavior we wanted.
--
Simon Denier
*** Filtering dependencies
The last common refinement is to filter some of the dependencies based on the scope. This is different from scaling in that we don't change the type of result objects, just select or reject some.
aMethod queryOutgoingReferences opposites withinPackage: aPackage
only retrieves referenced classes in the given package
aPackage queryIncomingInvocations atClassScope outOfNamespace: aNamespace
only retrieves invoked classes out of the given namespace
This also works on primitive queries
aMethod queryOutgoingReferences withinPackage: aPackage
which retrieves FamixReferences instead of classes
As for scope, there are 2x3 operators for filtering:
#withinClass: #withinPackage: #withinNamespace #outOfClass: #outOfPackage: #outOfNamespace:
For convenience, the following helpers are also defined:
#withinMyClass #withinMyPackage #withinMyNamespace #outOfMyClass #outOfMyPackage #outOfMyNamespace
aClass queryOutgoingInvocations atClassScope outOfMyPackage
---> invoked classes out of my package
aMethod queryIncomingInvocations opposites withinMyClass
---> invoking methods in the same class
--
Simon Denier
MooseChef is a new package which provides a small DSL to query (some of the) dependencies between famix entities. It is a replacement for the current Moose Cook project, which provides 'navigation methods' between famix entities and resides in the Famix-Extensions package.
Basically, MooseChef provides an API with a few methods to ask a method, a class, a package, a namespace for its dependencies (invocations, inheritance, references...) to other entities at various scope (class, package, namespace). Moose Chef comes as a small set of composable queries, with a well defined meaning, which is easy to browse and understand, and reused across Famix entities through traits.
*** Source, side, and dependencies
To start with, a query has a source (or receiver), that is the famix entity for which we require dependencies. Currently FamixMethod, FamixClass, FamixPackage, and FamixNamepace supports Chef queries. Relative to the source, a query has a side: it can be a query on either incoming or outgoing dependencies. Primitive queries returns a set of dependencies related to the source, that is instances of FamixAssociation: invocations, accesses, inheritances, references.
*** Primitive queries to access dependencies as associations
Hence, the combination of sides and dependencies define the set of primitive queries availble for any source.
source query[Incoming|Outgoing][Invocations|SureInvocations|Accesses|References|Inheritances].
You can ask for example
aFamixMethod queryIncomingInvocations
but also
aFamixClass queryIncomingInvocations
aFamixPackage queryIncomingInvocations
(Notice that a few queries do not make sense for some receiver, like for example asking a FamixMethod for its inheritances or it incoming references - in this case the convention is to return the neutral value, that is an empty collection).
Some 'composite' queries are also defined on top: all dependencies, sure dependencies,
static dependencies : accesses + references + inheritances
sure dependencies : static + sure invocations
all dependencies : static + invocations
--
Simon Denier
I added a tag Component-Spy
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.