New submission from lanza <michele.lanza(a)unisi.ch>:
i'd like to have the possibility to take an arbitrary group of entities and
transform them into a "model" that I can also export to mse
----------
messages: 92
nosy: lanza
priority: Wish
status: unread
title: transforming groups into models
________________________________________________
Moose Bugs <moose-dev(a)iam.unibe.ch>
<http://macamis.unibe.ch/trackers/moose/issue69>
________________________________________________
New submission from lanza <michele.lanza(a)unisi.ch>:
when the list of models in the moose ui is empty (all models removed) the context
menu does not show up anymore
----------
component: Moose UI
messages: 91
nosy: lanza
priority: Bug
status: unread
title: context menu disappears
________________________________________________
Moose Bugs <moose-dev(a)iam.unibe.ch>
<http://macamis.unibe.ch/trackers/moose/issue68>
________________________________________________
New submission from lanza <michele.lanza(a)unisi.ch>:
It would be good to have a menu item which allows me to select a set of models and
"strip them", i.e., only the model entities should remain without stubs
----------
component: Moose
messages: 90
nosy: lanza
priority: Wish
status: unread
title: Stripping Models
________________________________________________
Moose Bugs <moose-dev(a)iam.unibe.ch>
<http://macamis.unibe.ch/trackers/moose/issue67>
________________________________________________
What is the best way to export the source code of a modeled entity
within an mse file? I.e., suppose we extract a function and do not
want to rely on the sourceAnchor to be able to access its few lines
of source code in Moose. Is using a dedicated property the right way
or is there a better one?
Cheers
M
Hi;
I'd greatly appreciate any help/advice on how to best view MSE files
describing functional programs. I've uploaded one such file to
http://atelier.inf.unisi.ch/~baroneak/yuv.mse
Information I'm modeling includes global variable and function
definitions, and information about functions, such as which file they
are in, whether or not they are predicates (heuristically determined,
always false in the example file attached), and how many parentheses
they have (as a heuristic for function size/complexity, similar to
lines of code.)
The current mondrian script I'm using to visualize it looks like this:
------------
view := ViewRenderer new.
view interaction popupText: [:entity | 'Name: ', entity name].
view nodes: mooseModel allFiles using: RectangleShape withBorder forEach:
[:file | |fInCurFile edges | fInCurFile := mooseModel
allFunctions select:
[:curFunc | ((file name asByteString) =
(curFunc sourceAnchor copyFrom: 6 to:
curFunc sourceAnchor size))].
fInCurFile sortWith: [:f | f propertyNamed: #DIF].
view nodes: fInCurFile
using: (RectangleShape orange
width: [:entity | (entity propertyNamed: #NPAR) / 8]
height: [:entity | (entity propertyNamed: #NPAR) / 8]).
view circleLayout.
edges := Core.OrderedCollection new.
fInCurFile do: [:e | e incomingInvocations do:
[:eInv | edges add: e->(eInv invokedBy)]].
view edges: edges
from: #key
to: #value
using: (LineShape color: Color blue)].
view open.
---------
At a minimum, I'd like to be able to mouse over or click on the orange
squares representing functions and see the associated function name;
right now, the popupText only shows the filenames.
Any other advice on new visualizations, improvements to the mse
exported (I only partially understand the format), etc, would be
great.
Thanks;
Katerina Barone-Adesi
hi
when trying to access the upper and lower bounds of a TypedElement return
the element itself because there is no return sign in the methods
TypedElement>>lower, TypedElement>>upper.
Pierrick
NamedOccurrences raise an error when you want to apply it on a class.
do: DNU on sorter
in addition
Duplication view on a group of class crashes the system I get a
primitive failed on ZoomGraphicsContext.
Stef
New submission from Tudor Girba <girba(a)iam.unibe.ch>:
NamedOccurrences raise an error when you want to apply it on a class.
do: DNU on sorter (submitted by Stef)
----------
assignedto: girba
component: Mondrian
messages: 88
nosy: girba
priority: Bug
status: unread
title: NamedOccurrences raises DNU due to sort:
________________________________________________
Moose Bugs <moose-dev(a)iam.unibe.ch>
<http://macamis.unibe.ch/trackers/moose/issue66>
________________________________________________
Hello ! I had a look at the BasicCodeGenerator. I analysed the example and
then, I tried it with my own EMOF models. Of course, I got some surprising
results :)
For example, when you visit a Package, you apply the visitor ( the
BasicCodeGenerator) on its nesting package. In your example, with the EMOF
model, there is no problems because there is only one package. But in a
model with subpackages, it results in an infiny loop. So, I don't
understand why it is necessary to visit the nesting package. Any idea ?
Thank you
Sara
