Moose-dev January 2011

moose-dev@list.inf.unibe.ch

23 participants
129 discussions

meaningful commit comments
by Tudor Girba 27 Jan '11

27 Jan '11

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

2 2

Issue 505 in moose-technology: The Smalltalk importer should not populate the default comment in FAMIXClass
by moose-technology＠googlecode.com 27 Jan '11

27 Jan '11

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.

1 1

hudson
by Alexandre Bergel 26 Jan '11

26 Jan '11

I would love to see only green ticks :-) Maybe we can remove unnecessary projects? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

Fwd: MooseChef 1/4, a small DSL to query dependencies between famix entities
by Simon Denier 26 Jan '11

26 Jan '11

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

1 0

Fwd: MooseChef 2/4, querying objects and scaling
by Simon Denier 26 Jan '11

26 Jan '11

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

1 0

Issue 504 in moose-technology: Finder should be customized with the amount of fixed displayed panes
by moose-technology＠googlecode.com 26 Jan '11

26 Jan '11

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.

1 1

MooseChef 4/4, migration, tips and tricks
by Simon Denier 26 Jan '11

26 Jan '11

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

3 2

MooseChef 3/4, filtering results based on scope
by Simon Denier 25 Jan '11

25 Jan '11

*** 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

1 0

MooseChef 1/4, a small DSL to query dependencies between famix entities
by Simon Denier 25 Jan '11

25 Jan '11

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

1 0

Issues related to Spy (which includes Hapao) are now tracked on the moose code google
by Alexandre Bergel 25 Jan '11

25 Jan '11

I added a tag Component-Spy Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev January 2011