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
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Famix Milestone-4.3
New issue 500 by tudor.gi...(a)gmail.com: AnnotationType mooseName should
return the fully qualified name
http://code.google.com/p/moose-technology/issues/detail?id=500
It should be like for the class.
Hi,
I did star this morning to import a data base model into an already existing moose model of a Java application and my image is still working. So in another image with the same application's model loaded i did try to import the same data base model but as a separate moose model (so without touching the already loaded one) and the work has been done in 2 minutes.
Than i did try to investigate why to add to a model of ~680000 entities another ~8000 entities takes so long. I did notice that in the method MooseModel>>add: is set an announcement (self announcer announce: (MooseEntityAdded new entity: anElement).). By commenting this announcement the import is perform in 2 minutes. I'm not sure that i'm right but anyway what is this announcement for? Cannot be moved into the method MooseModel>>addAll: after having added all the entities? In this second case the method addAll: can always use a "private" add method that does not perform the announcement.
Cheers,
Fabrizio
Hi!
Just to say that I added a simple visualization in the MOEasel to keep track of the 'as yet unclassified' method category.
You can open an OB by right clicking on a red node. Fixing it and pressing 'Generate' again to see your progress.
Nothing revolutionary, but I find it useful in my case.
Note that are they other useful visualizations for example 'Abstract classes' that check no abstract classes is a leaf.
Version 2.40 of Mondrian does not have any 'as yet unclassified' and abstract class leaf
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Andre,
I see that you worked again on the Bunch Cohesion and Coupling. Could you give us a pointer on what these metrics mean in practice?
Cheers,
Doru
--
www.tudorgirba.com
"Presenting is storytelling."
Hi!
Is there a user friendly archive of this mailing list? I do not find http://www.iam.unibe.ch/pipermail/moose-dev/ particularly useful.
I tried some google, but I haven't found
Maybe I missed something obvious here.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
some small questions...
Can I open a glamour browser modally? (and add buttons to close it?)
Can I add a filter on a list who acts on typing?
Cheers,
Esteban
pd: still no time to come back to the announcer problem... maybe on week end :(
BTW,
I was looking at this license stuff yesterday.
Since verveineJ is based on JDT and JDT uses the EPL (Eclipse Public
License), VerveineJ could be required to use the EPL also ...
"According to article 1(b) of the EPL, additions to the original work
may be licensed independently, including under a commercial license,
provided such additions are "separate modules of software" and do not
constitute a derivative work.[4][5] Changes and additions which do
constitute a derivative work must be licensed under the same terms and
conditions of the EPL, which includes the requirement to make source
code available"
[http://en.wikipedia.org/wiki/Eclipse_Public_License]
"The EPL is approved by the Open Source Initiative (OSI) and listed as
a "free software license" by the Free Software Foundation (FSF)"
any comment?
nicolas
--
Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
Hi!
For the last two years I have been writing code like:
view edges: { obj1 -> obj2 . obj3 -> obj4 } from: #key to: #value.
I have checked your code but I am wondering whether I am the only one
I think it would be cool to be able to write:
view edges: { obj1 -> obj2 . obj3 -> obj4 }
Does it make sense?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
What is the status of MooseChef? Is it already good enough to replace the existing navigation?
Cheers,
Doru
--
www.tudorgirba.com
"Don't give to get. Just give."
Hi,
Do any of you know good resources for learning COBOL?
Cheers,
Doru
--
www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 490 by andrehoraa: check generic-types handling
http://code.google.com/p/moose-technology/issues/detail?id=490
It seems verveineJ does not handle generic types at all. For example if a
method has a return type with generic, the return type is not processed
correctly, and the method might not be created correctly.
Check whether this is the case and solve the problem if it is the case ...
Status: New
Owner: andreho...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Verveine
New issue 497 by andreho...(a)gmail.com: LocalVariables without
ParentBehaviouralEntity
http://code.google.com/p/moose-technology/issues/detail?id=497
It seems that some Local Variables don't have ParentBehaviouralEntity. It
might be related to binding problem in the AST.