Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Hapao
New issue 601 by alexandr...(a)gmail.com: Covered methods and tests
http://code.google.com/p/moose-technology/issues/detail?id=601
It would be good to see what are the tests that _indirectly_ tests a
methods.
Thanks Laurent & Patrick
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.7
New issue 793 by tudor.gi...(a)gmail.com: TreePresentation does not show the
selected item when rendering with Morphic
http://code.google.com/p/moose-technology/issues/detail?id=793
You can reproduce the problem with the example found in:
GLMBasicExamples>>treeWithInitialSelection
"
| browser |
browser := self new treeWithInitialSelection.
browser openOn: {
#first->{$a->{}. $c->{}. $d->{}}.
#second->{$e->{}. $f->{}}.
#third->{$h->{}}
}.
(browser panes first port: #selection) value: (browser panes first port:
#entity) value.
"
| browser |
browser := GLMTabulator new.
browser
column: #one;
column: [ :c |
c
row: #two;
row: #three ].
(browser transmit)
to: #one;
andShow: [ :a |
(a tree)
title: 'first tree';
children: [ :x | x value ].
(a tree)
title: 'second tree';
children: [ :x | x value ] ].
(browser transmit)
to: #two;
from: #one;
andShow: [ :a | a text title: 'Selection preview' ].
(browser transmit)
to: #three;
from: #one port: #selectionPath;
andShow: [ :a | a text title: 'Selection path preview' ].
^ browser
Hello,
I'm looking to improve current implementation, and maybe you can help me.
The current procedure is based in a custom serialization of each
MooseElement. It's inspired on MSE, I describe this with the following
pseudo-code:
serialize: aMooseElement
(MooseModel meta descriptionOf: aMooseElement class) allAttributes
do: [ :anAttribute |
| values |
values := anAttribute getFrom: aMooseElement.
(self shouldIgnore: anAttribute withAll: values)
ifFalse: [ self serialize: anAttribute withAll: values ] ].
where:
shouldIgnore: anAttribute withAll: values
^ values isEmpty or: [
anAttribute isDerived or: [
anAttribute type == FM3MetaDescription boolean and: [
values size == 1 and: [
values first == false ]]]]
The advantage of serializing the MooseElements in this way (and not just as
a normal object) is to avoid storing unnecessary stuff that aMooseElement
references.
It's a disadvantage using FM3PropertyDescription>>getFrom: (and then to
import, FM3PropertyDescription>>setOn:values:) which ends sending #perform:
of the corresponding accessor selector. It'd be better to use #instVarAt:
(and #instVarAt:put:) as Fuel normally does.
I hope I've been clear enough to explain up to this point. Now my question:
Do you think Fuel can do something on each MooseElement like
- clean up some unnecessary references
- declare some instance variables as transient
- if it's not good idea to modify the elements, create a method like
MooseElement>>copyWithoutDerivedValues, and so actually serialize such copy
instead of the original element
- any other
???
and thus, serialize the MooseElements as normal Fuel objects, removing the
custom procedure.
I'll be happy to receive some help from Moose and Fame experts!
Thanks in advance.
Martín
Status: New
Owner: andreho...(a)gmail.com
Labels: Type-Enhancement Priority-Medium Component-Famix
New issue 509 by andreho...(a)gmail.com: Modularization Quality Metric
http://code.google.com/p/moose-technology/issues/detail?id=509
We implemented the Bunch metrics of coupling and cohesion as quality
metrics for existing packages (FAMIXPackage) and namespaces
(FAMIXNamespace).
Now the idea is to implement the Modularization Quality Metric as a quality
metric for existing group of packages (FAMIXPackageGroup) and namespaces
(FAMIXNamespaceGroup).
Pointer to the papers that propose the metrics:
Using Automatic Clustering to Produce High-Level System Organizations of
Source Code (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=693283)
Bunch: A Clustering Tool for the Recovery and Maintenance of Software
System Structures
(http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=792498)
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 767 by sean.p.d...(a)gmail.com: Book: presentation names are
confusing
http://code.google.com/p/moose-technology/issues/detail?id=767
For example, on
http://www.themoosebook.org/book/internals/glamour/presentations/action-list
ActionListPresentation is referenced, but the class name is
GLMActionListPresentation. So, when I pasted it into a workspace, it was
highlighted red as an unrecognized class. I think it'd be clearer to either
use full presentation class names or spaces between camel case
(e.g. "Action List Presentation").
The same is true for some of the other presentations e.g. DiffPresentation
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 644 by cy.delau...(a)gmail.com: A fly by help to show each time the
source code of an entity
http://code.google.com/p/moose-technology/issues/detail?id=644
Maybe it would be interesting when navigating in moose, to always have a
fly by help that show the source code of an element
Status: New
Owner: ----
CC: georgega...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-ExternalTools
New issue 782 by tudor.gi...(a)gmail.com: inFamix should export basic metrics
for methods
http://code.google.com/p/moose-technology/issues/detail?id=782
inFamix should export basic method metrics:
- LOC (lines of code)
- NOS (number of statements)
- CYCLO (cyclomatic complexity)
Status: New
Owner: ----
Labels: Type-Enhancement Priority-Medium Component-Glamour
New issue 582 by tudor.gi...(a)gmail.com: Watcher support in Glamour
http://code.google.com/p/moose-technology/issues/detail?id=582
Like we now have a statusbar, we should also have a detailed preview shown
in a floating Watcher window. The behavior would be similar to Quick Look
on Mac.
Hi,
We just had over the last couple of days some 194 failed tests:
http://ci.moosetechnology.org/job/moose-latest-dev/957/
191 of them came from a parallel commit into Mondrian. I solved it now, but to prevent this kind of thing in the future, I now changed the build to send notifications to this mailing list.
We still have three tests (related to Monticello) that are failing on the server.
Cheers,
Doru
--
www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."
Hi,
I made some progress with the TreeMapLayout. Two challenges remain to be
solved.
The first one is related to dragging. It is kind if complicated to explain
in words, so I made this short screencast:
http://cl.ly/150n1t2Z2h1y3L0z1U0L
As you can see the positions of the shapes get updated only when hovering
over them, not instantly when dragging, as I would like them to.
One difference code-wise to other graph layouts is that the owner of all
shapes is, in this case, not MORoot but the node "org", which is a normal
MONode. I had to do this (change ownership) because MORoot does not get
drawn (is this by design?).
Does anyone have some ideas on what could explain this behavior?
Another question would be: Is it possible to make the inner nodes not
draggable? The user should not be able to move individual shapes inside the
TreeMap around.
Cheers,
Dennis