Hi!
We are looking for a case study for our work on test coverage.
Moose (i.e., packages having their name beginning with 'Moose-') has all the characteristics of the ideal candidate. It is fairly large (399 classes and >3800 methods), it is important and has a relatively poor coverage. Only 52% of the method are executed by unit tests.
For example, I was surprised that many methods of MooseModel are actually not executed by unit tests (e.g., inferNamespaceParentBasedOnNames, installDefaultModels).
The LAN Example is never executed for example. Even DefaultStateEntity has many untested methods. This could very well be dead code.
Is there a part that you would like us to focus on first?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Cyrille,
I noticed that in the DistributionMap package we have a LinkedTabGroupMorph. However, this class is not referenced anywhere. Any idea what its goal is?
Cheers,
Doru
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Hi Alain,
In the latest Glamour, you will have a light color for no empty panes.
Cheers,
Doru
On 15 Jan 2011, at 18:38, Alain Plantec wrote:
> Le 15/01/2011 18:23, Tudor Girba a écrit :
>> Well, those panes are actually drawn, only the renderer draws them with transparent color.
>>
>> You could show an empty text there:
>> browser transmit to: #below; andShow: [:a | a text display: ''].
>>
>> However, this is a bit against the idea of Glamour which is to show data. Here, you would show something only because of the visual appearance.
> yes, I agree with you but you could make the panes with "no data" rendered with a darker color (very light gray fro example).
> So the user would have a clear idea of how is composed the browser. Having blank areas is uncomfortable to me.
>
> btw, how is it possible to update the browser when a part of it is changed ?
> Thanks
> Alain
>
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
LinkedIn
------------
Moose-related,
I'd like to add you to my professional network on LinkedIn.
- Andre Hora
Andre Hora
Software Engineer at INRIA Lille Nord Europe - RMod team at INRIA
Lille Area, France
Confirm that you know Andre Hora
https://www.linkedin.com/e/-hlc47i-gj9cetfn-1p/isd/2192800060/c2iF1T9u/
--
(c) 2010, LinkedIn Corporation
Updates:
Status: Fixed
Labels: -Milestone-4.2 Milestone-4.3
Comment #16 on issue 145 by tudor.gi...(a)gmail.com: check #flag: senders
http://code.google.com/p/moose-technology/issues/detail?id=145
This issue is too wide to ever get closed. We should create more specific
issues if needed.
Updates:
Status: Fixed
Labels: -Type-Defect Type-Enhancement Milestone-4.3 Component-Glamour
Comment #1 on issue 430 by tudor.gi...(a)gmail.com: [Glamour][Mondrian]
increase/decrease zooming
http://code.google.com/p/moose-technology/issues/detail?id=430
Take a look at MOViewRenderer>>openWithStatusbar
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Famix
New issue 496 by cy.delau...(a)gmail.com: bug when opening system
complexity : MOTreeLayout(Object)>>doesNotUnderstand: #topGap:
http://code.google.com/p/moose-technology/issues/detail?id=496
In the latest moose dev image:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
If you create a model and try to visualize system complexity from all
classes, an error will be thrown:
MOTreeLayout(Object)>>doesNotUnderstand: #topGap:
I guess it is due to some modifications in mondrian and that the code of
system complexity has not been updated.
I believe a package with an extension method should be seen as depending on the package owning the extended class (and also depending on the extended class)
Right now, this is not implemented in the various {sure|potential}ReferencedPackage , {sure|potential}ReferencedClass
After discussing with Simon, we believe that this would at least call for an explicit representation of the extension as an association.
This would go in Famix-Smalltalk
The question maybe how to represent this?
Simon sees it as an association between a package and a method: Me (package) defines an extension (the method)
I was rather thinking of a class/method association: Me (class) am extended by you (method)
and the reverse: me (method) extends you (class)
then of course we would need to implement the query system on top of this ...
what do you people think about this?
nicolas