Hello,
I am trying to add an update event in GLMMorphicRoassalRenderer so that
when the pane containing the roassal visualization is sent an update event,
the corresponding roassal visualization is redrawn (please see:
http://code.google.com/p/**moose-technology/issues/**detail?id=808<http://code.google.com/p/moose-technology/issues/detail?id=808>
).
Now, I can trigger painting block of the GLMRoassalPresentation but there
are some missing entities and the layout not being applied properly.Please
find attached to this mail my code for GLMMorphicRoassalRenderer class to
trigger the update event. Can you please see what is missing in my code
that does not allow proper rendering of roassal visualization?
You can use this code to test the updated rendering feature:
| browser startNumber |
browser := GLMTabulator withStatusbar.
startNumber := 1.
browser column: #one.
browser transmit to: #one; andShow: [ :a |
a roassal
title: 'Numbers in Roassal';
painting: [:view :number |
view shape label.
view interaction
on: ROMouseClick do: [ :event |
ROFocusView new on: event element view: view raw ].
view nodes: (startNumber to: number).
view edgesFrom: [:each | each // 5 ].
self halt.
view treeLayout.
view addMenu: 'Refresh' callBack: [ :stack | startNumber := 10. (browser
paneNamed: #one) update ].
]].
browser openOn: 42
tx,
Usman
On Jul 25, 2012, at 3:42 PM, Andrea Caracciolo wrote:
> Hi Stef,
>
> I read your replies in the mailing list and i wanted to clarify some doubts.
> As I understand, your points are the following:
> - extend the FAMIX meta-model adding new meta-data to make the concept of "project version" and "project" explicit.
not necessarily.
First the moose infrastructure.
> - supporting the exchange of partial models
Yes.
> To me it seems that both of the mentioned ideas contradict the purpose of the MSE format.
> MSE is good for packaging structural information about one single project snapshot.
> If you want to represent a project and all of its versions as a whole, you need to come up with a new representation format.
no :)
mse is a format to exchange data.
> Also shrinking models looks quite hard. You end up with a lot of broken dependencies and you need to generate a file which fits your personal analysis requirements.
Not really. Have a look at MooseImportingContext it is there to manage that you always save and load a coherent model. In fact I use it to import
coherent Smalltalk models. So loading is the same. You look at the graph dependencies and pay attention that if you remove attributes you do not use something that requires it. This is the job of the ImportingContext to manage that for you.
We should ask cyrille because I think that I remember that he worked on partial loading. Now at the end some graph dependencies where
expressed in FAME and I lost track.
> In my opinion, the best option would be to transition to relational database as an intermediate representation medium.
Give a try and let us know but I have some doubts.
> Instead of exchanging models through mse files, you replicate a certain set of DB entires.
Saving to relational databases graphs is not easy and simple.
For the moment imagine that we want to build a dashboard where we monitor some metrics.
you can write a script that
checkout source code
launch verveineJ
generate a new version in use
then you load the use file (filtering information if you can = make sense)
compute your metrics
save a strip down version of your model that fit the purpose of your analysis
now
since you want to do a trend analysis you load following the strategies developed by andre
all the stripped versions, or just 10 of them and the latest….
and you compute your dashboard data.
To me a project: an entity managing files and sources, versions on a disk or whatever it is stored .
After a project could have different loading strategies but well encapsulated.
> Parsing of MSE is replaced by recursively exploring the newly created database entries.
> This would also allow to have different strategies for loading famix objects in memory.
>
>
> Cheers
> _____________________________
> Andrea Caracciolo -- caracciolo(a)iam.unibe.ch
> Software Composition Group
> University of Bern
>
>
>
>
>
>
Status: New
Owner: anquetil...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-VerveineJ
New issue 813 by anquetil...(a)gmail.com: Java primitive type "int" created
as FamixType
http://code.google.com/p/moose-technology/issues/detail?id=813
Parsing some files in Eclipse creates a FamixType for the primitive type int
Hi all,
Could anyone point me in the right direction on how to create a progress
indicator for long running tasks? Are there any examples, implementation I
could look at?
I found *MooseCustomTask* and *SystemProgressBarMorph*. I'm not sure about
using the MooseCustomTask, because what I want to do is not directly
related to moose. Its just a generic task. Are there any other classes that
handle the display of progress bars?
Thanks,
Dennis
Hi all,
Whats the best way to get LOC for nested FAMIXNamespaces?
Lets say I'm looking at a FAMIX model of argouml. I used the "Infer
Namespace Parents Based on Names" command in the Moose Panel.
I have a namespace argouml (org.argouml), and a namespace profile
(org.argouml.profile).
Calling numberOfLinesOfCode on the second namespace gives me a correct
number of around 1000 (I assume because the "children" of profile are
actually FAMIXClasses). Calling it on the first one returns 0.
So what would be the best way to get LOC on parent namespaces like "org",
or "org.argouml"?
Also is this by design that LOC does not get propagated up in the hierarchy
or is it even a bug?
Cheers,
Dennis
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 812 by anquetil...(a)gmail.com: All FamixType are at classScope in
MooseChef
http://code.google.com/p/moose-technology/issues/detail?id=812
All FamixType are at classScope in MooseChef
This means for example that the Java primitive type "void" can be returned
by a mooseChef query:
xyz queryOutgoingDependencies atClassScope
there is an outgoing dependency to void, but void should not be at class
scope
need to change FAMIXType>>atClassScope and FAMIXClass>>atClassScope
Status: New
Owner: anquetil...(a)gmail.com
Labels: Type-Enhancement Priority-Medium Milestone-4.7
New issue 810 by anquetil...(a)gmail.com: Create virtual association
TypeDeclaration in MooseChef
http://code.google.com/p/moose-technology/issues/detail?id=810
Famix recognizes 4 types of associations (reference, access, inheritance,
invocation) and Moosechef was built upon these dependencies
(queryAllOutgoingReferences, ...)
but this misses some actual dependencies that are not expressed by
FamixAssociations like: return type of a method or type of a variable
Since we now have a nice general API to query dependencies, it would be
nicer if it were complete, ...
A possible solution would be to invent some new "virtual associations"
(TypeDeclaration) and create queries for this, ...
With The aid of Andre, we finished creating the TypeDeclaration virtual
association in MooseChef (see also
http://moose-dev.97923.n3.nabble.com/Several-modifications-to-MooseChef-tp3…).
We also created a queryIncoming/OutgoingDependencies that will gather
all dependencies from a model:
allAssociations (real association from Famix) + TypeDeclarations
(virtual association that is "hidden" like the type of a variable).
The MooseChef documentation should be updated accordingly (see "<added>"
markers for additional stuff):
---
** Primitive queries return associations
Primitive queries return a set of dependencies related to the receiver.
Such dependencies are represented by instances of FAMIXAssociation:
invocations, accesses, inheritances, and references.
<added>
MooseChef also recognizes an association that does not exists as such in
Famix: TypeDeclaration.
It exists only for statically typed languages and relates a variable
(FAMIXStructuralEntity) to its type, or a method to its return type.
<added/>
receiver queryAllIncomingInvocations
querySureIncomingInvocations
queryIncomingAccesses
queryIncomingReferences
queryIncomingInheritances
<added>
queryIncomingTypeDeclarations
<added/>
receiver queryAllOutgoingInvocations
querySureOutgoingInvocations
queryOutgoingAccesses
queryOutgoingReferences
queryOutgoingInheritances
<added>
queryOutgoingTypeDeclarations
<added/>
[...]
Some composite queries are also defined on top
static associations = accesses + references + inheritances
sure associations = static + sure invocations
all associations = static + invocations
<added>
dependencies = all associations + typeDeclaration
<added/>
---
There are still some additional hidden dependencies in Famix as
discussed in
http://moose-dev.97923.n3.nabble.com/MooseChef-hidden-dependencies-tp354895…
tests are green (in my image)
nicolas
Hi,
Just to clarify the situation. We have two parsers that are mature enough for large cases studies. They are both closed source:
- VerveineJ: is closed source and it is likely to gain a license that will allow "friends" to use it for free, or something in this direction. At the moment, the sources and the build are available for anyone (although the license is not yet specified). It is mainly built by Nicolas Anquetil (and I helped a bit).
- inFamix: is free to use in any context, but you have to agree with their license usage (so, no real automated download). It is a subset from the inFusion commercial platform. It also supports C/C++. It is built by www.intooitus.com and I helped them a bit, too.
For what they cover, neither is quite complete in the little details, but they are almost there. VerveineJ is slightly better in the coverage of Annotations and a couple of more details (like References). They both export about the same metrics.
I would be interested in working with someone to build a little comparison infrastructure: we take some source code, and we generate a simple diff report on the build server.
It would be important for this community to get a robust solution for Java. I worked quite long on getting both of these mature enough and in evolving FAMIX to support the new language constructs in Java (e.g., Generics and Annotations), and I would still be interested in continuing this enhancement. inFamix also offers C/C++ support, and there one of the major headaches was given by the type alias possibilities, but that is solved now both in FAMIX and in the parser.
>From my experience, the most tedious work in this area is to go through each case study and deal with all the little details not just at the parser level, but also at the meta-model level. We are getting close to a solid solution for Java, but we need to push for the extra mile.
Talking about the meta-model we need to rethink completely the navigation API and be based solely on MooseChef (and possibly Lift). I would be interested in getting people to work with me on this, as well.
Cheers,
Doru
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
Status: New
Owner: alexandr...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Roassal
New issue 808 by guillaum...(a)gmail.com: refresh a GLMRoassalPresentation
http://code.google.com/p/moose-technology/issues/detail?id=808
the update function on GLMRoassalPresentation don't call the painting
block. Consequently the visualization is not refreshed.