I am usings the code to produce the attached image.
view shape: (MOArrowedOrthoVerticalLineShape new).
view edges: inheritance from: #superclass to: #yourself.
How do I achieve that with Roassal?
And just to document something I got working... previously to hide lines
while keeping the layout I was using...
view shape: (MOStraightLineShape new color: Color white).
view edgesFrom: [ :xx | xx - 1 ].
and now...
(view edgesFrom: [ :xx | xx - 1 ] ) do: [ :edge | edge - ROEdge ] .
cheers -ben
Hello Moosers,
As you already know, Dennis is working on the hierarchical graph data
structure and its great associated visualization in Pharo :) We have been
testing his code on software systems which have an inherently hierarchical
structure with low level relationships propagating up along the package
structure, but also thought we would try it on a different type of
hierarchical data. The two contributions (the HG data structure & the
visualization) are after all independent of the domain model.
Do you know of any data sources that have the following two properties?
1. There exists a set of relationships between low level, leaf entities
2. The low level, leaf entities can be aggregated along containment
relationships
One example would be trade relationships existent between companies, can be
aggregated to regions, countries, continents...
If you are aware of such a data set, we'd offer a beer for the information
:)
Cheers!
M.
Just interested in learning more about the internals of Roassal. I see
this comment in ROElement>>positionRelativeTo: anElement
"Return the position of myself against the position of one of my
parent, anElement. The returned position is relative to it."
"This method is useful to draw edges that are nested"
How do nested edges fit into the architecture ?
Another MooseChef decision:
aPackage queryOutgoingReferences
returns all the FamixReferences made from aPackage.
this is implemented by taking all methods (self methods) in the package
and asking them what reference they make.
And we have
FAMIXPackage>>methods
^ self localMethods union: self extensionMethods
So when asking a package what external references it makes, we get
references stemming from methods that extend classes of other packages.
We found this while computing a coupling metric for packages.
So the solution would be easy to implement, but we are not sure what is
the best solution ?
- we could change FAMIXPackage>>methods (methods belong to the package
that owns their class)
- we could change queryOutgoingReferences
(references/invocation/accesses stem from the methods in the classes in
the package, not from the methods in the package)
- or we could change our metric
nicolas
Hi! I am a newbie in Smalltalk and specially en Eyesee.
I'm having trouble with the scale of the Y axis in a vertical bar diagram.
If I define a dictionary as
d := {'a'->(1/3) . 'b'->(3/2) . 'c'->(7/4)}.
I can create a nice diagram with this
chart := ESDiagramRenderer new.
chart verticalBarDiagram
y: [:eachAssociation | eachAssociation value];
identifier: [:eachAssociation | eachAssociation key];
regularAxis;
models: d .
chart open
whose Y axis is very well populated with labels indicating different
steps in the scale.
But if I redefine d as
d := {'a'->(1/3) . 'b'->(7/5) . 'c'->(17/4)}.
(which is closer to the data I am working on) most of the labels in the
Y axis are gone.
How can I instruct Eyesee to show a more informative scale?
Thanks in advance for your help.
Cheers
Lautaro Pecile.
Status: New
Owner: tudor.gi...(a)gmail.com
CC: alexandr...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7
New issue 822 by tudor.gi...(a)gmail.com: Roassal line color does not work
with the model of the edge
http://code.google.com/p/moose-technology/issues/detail?id=822
Right now, the color of a line is a constant. It should be a transformation
that works with the model of the edge.
Status: New
Owner: tudor.gi...(a)gmail.com
CC: alexandr...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7
New issue 821 by tudor.gi...(a)gmail.com: Roassal Mondrian builder crashes
when an edge has the same model as one of the nodes
http://code.google.com/p/moose-technology/issues/detail?id=821
To reproduce after the introduction of models behind edges:
view nodes: (Array with: 4 with: 2).
view edges: (Array with: 4 with: 2) from: 4 to: 2.
Status: New
Owner: tudor.gi...(a)gmail.com
CC: alexandr...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7
New issue 820 by tudor.gi...(a)gmail.com: Roassal Mondrian builder does not
initialize edges with a model
http://code.google.com/p/moose-technology/issues/detail?id=820
The method used for initializing the edge is:
buildEdgeFrom: fromNode to: toNode
"Shape is not initialized here"
^ (ROEdge from: fromNode to: toNode) + shape
The problem here is that the edge does not receive a model object. Because
there is no model object, the transformations for properties like width or
color cannot be expressed properly.
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7
New issue 819 by tudor.gi...(a)gmail.com: Roassal line width does not work
with the model of the edge
http://code.google.com/p/moose-technology/issues/detail?id=819
This does not work at the moment:
view := ROMondrianViewBuilder new.
view shape label.
view nodes: (1 to: 2).
view shape line width: [:x | x ].
view edgesFrom: [:x | x // 2].
view treeLayout .
view open
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7
New issue 818 by tudor.gi...(a)gmail.com: Roassal tree layout does not
preserve the order of nodes
http://code.google.com/p/moose-technology/issues/detail?id=818
In Pharo 1.4, Collection>>difference: uses a set, thus, it does not
preserve the order of the elements.
Because of this, the following method has to be rewritten:
ROAbstractGraphLayout>>childrenFor: aNode except: aNodeCollection
^(self childrenFor: aNode) difference: aNodeCollection
Just a few thoughts about how the Roassal Easel [Examples] are presented.
Some text describing the meaning of the blue and pink grouping boxes
would be useful - but to hazard a guess blue is the replicated Mondrian
functionality and pink is the new Roassal functionality ?
The ZoomIn and ZoomOut buttons don't work with either the [Examples] of
[Info] displayed - which is fair enough, but there is no feedback to
indicate the buttons will have no effect. This is quite nit-picking so
perhaps can be ignored.
Once any particular example is clicked, there is nothing that displays
what the current example is - so if (like me) you forget which it was
two seconds after you click it, you end up a bit lost. It would be nice
to have something that identifies the current example.
Example>interaction>leftAndRightClick - fails
Example>interaction>clickAndMove - the element ends up about 150 pixels
below the click. It should either centre or align a corner with the click.
Example>colors>normalizer - it is not clear what the purpose of this is,
especially under a colors section - it is just an empty black box that
is moved around.
just documenting another migration....
this in Mondrian...
view interaction menuItems add: 'Browse class' -> [:a2 | a2 browse ].
view interaction registerMenu.
appears to become this in Roassal...
view interaction item: 'Browse class' action: #browse.
How do you get a context menu on the background?
btw, I see that ROEaselMorphic>>populateMenuOn: calls
#zoomInButtonOn: which calls #addMenu:callBack:
Does #addMenu:callBack always draw the item in a box? Can you get
multiple items in one box?
From an outside perspective if there can be only one item per box then
#addButton:callBack would seem a more appropriate name.
Anybody can submit an opinion to the following issue:
MooseChef allows to express a query such as:
aClass queryOutgoingInvocations
aMethod queryOutgoingReferences
that will return all methods invoked from 'aClass' for the first query
and all classes referenced by 'aMethod' in the second query
Then you can constraint the scope of the result, for example to say that
you are interested by the package containing the referenced classes
aMethod queryOutgoingReferences atPackageScope
You can also down scope the result, for example to say you want all the
methods of the class referenced:
aMethod queryOutgoingReferences atMethodScope
Finally, there is something to say you are not interested in relation
that loop back to the original object queried
aClass queryOutgoingInvocations withoutSelfLoops
will return all classes that own methods invoked from 'aClass' except
'aClass' itself (that would be a selfLoop)
one sees on this example that withoutSelfLoops involves some scoping:
queryOutgoingInvocations will return a collection of methods, but the
query was sent to a class.
So when we say withoutSelfLoop, we actually mean all methods that don't
belong to the class to which the query was sent.
This is equivalent to:
aClass queryOutgoingInvocations atClassScope withoutSelfLoops
Up to now, the semantic is rather Ok, but when you use hidden down
scoping, it starts to be less clear:
aMethod queryOutgoingReference withoutSelfLoops
will return all classes referenced in 'aMethod' taken at methodScope and
removing self loop.
In the end, the result will ignore references to the class owning 'aMethod'.
What do you think?
There is some logic in the semantic, but it is not so intuitive.
Looking at the query, I cannot convince me that this is the result that
one would expect.
Should we change the semantic?
To what? (keep up-scoping and forbid implicit down-scoping? forbid all
implicit re-scoping?)
nicolas
PS: This may look like a rather theoretical question, but I actually
have a bug partly related to that and I need to know how to solve it
I have just downloaded Moose47 and am starting to migrate my app from
Mondrian to Roassal.
For the code below where 'a mondrian' /becomes/ 'a roassal' ...
At "#1" I get MNU ROLine>>fromPositions
For now I worked around this by deleting #fromPositions: and #toPositions:
but how do I get similar functionality to manage where the endpoints ?
I did find in "attachPoint := ROShorterDistanceAttachPoint instance" in
ROLine>>initialize but it would be good to get an idea of the overall
architecture for this.
At "#2" I get MNU ROMondrianViewBuilder>>domain - where #domain returns
an OrderedList of all the model entities, of which I ask each for all
its relationship links to other model entities to define the edges.
For now I worked around this by factoring "EpcimRoot withAllSubclasses"
out to a temporary variable, but I am wondering how in future to access
the model entities of the graph.
I did find "#elementsWithModelDo:" in
ROMondrianViewBuilder>>rawEdgesFrom:to: but not sure whether that is a
public/private method.
----------------------
a mondrian
title: 'Class Definition - Full Model' ;
painting:
[ :view
:selection |
view shape label.
view interaction popupText: [ : element | element class
comment ].
view nodes: (EpcimRoot withAllSubclasses).
view edgesFrom: #superclass.
(view shape line) "#1: /was/ a MOStraightLine
/becomes/ a ROLine "
color: Color lightBrown.
fromPositions: #(#center);
toPositions: #(#center).
view edges: view domain "#2: view /was/ a
MOViewRenderer /becomes/ a ROMondrianViewBuilder"
from: #yourself toAll: [ :x | x relations collect: [
:z | z key ] ].
view horizontalTreeLayout .
]
Status: New
Owner: ----
CC: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Glamour
New issue 701 by alexandr...(a)gmail.com: Cut and Paste do not update a
Glamour Port
http://code.google.com/p/moose-technology/issues/detail?id=701
Email snippets:
Regarding copy paste, indeed it seems that pasting a text does not update
the port. Please open a ticket.
-------
I found another strange behavior, likely to be a bug.
Try:
-=-=-=-=-=-=
| browser |
browser := GLMFinder new.
browser text
act: [:prez :v | prez text inspect ] on: $i entitled: 'Inspect'.
browser openOn: 'hello world'
-=-=-=-=-=-=
If you type something and press cmd-i then you open an inspector on what
you have typed.
Now, do a cut and paste in the textpane, and press cmd-i. You have an
inspector on 'hello world', no matter what you have cut&pasted.
>>
>>
>> Hi Stef,
>> Sorry but the problem is not that there are no 64-bit vms and images
>> available. The problem is that the available 32-bit vm and image cannot be
>> pushed further 500MB. Even worst is that as far as I understood we are not
>> even sure why is like that.
>>
>> For me a reasonable size for a Moose image containing an average size Java
>> Enterprise application is between 500MB and 1500MB. So a 32-bit vm\image
>> should be perfectly able to store the whole model and to have enough free
>> space for computations.
>>
>>
>> It is true that we cannot go larger than 500 mb?
>>
> yes, the hardcoded limit is 500mb
do you know why?
>
>>
>>
>> Partial loading could be a solution in some cases but we need tool support
>> for that. I cannot invest 2 weeks every time I need to script a 10 minutes
>> analysis trying to figure out how to partially load the information that I
>> "might" need. Without having a full model available the entire idea of
>> prototyping analysis behind Moose goes down the drain and so Moose itself
>> lose a lot of its meaning.
>> I think the whole point is to have all the data on the system in analysis at
>> hand. Either having 10GB model stored in an image or loading the needed
>> entities on demand it is not relevant as soon as it is transparent for the
>> user and the performances are not too bad.
>>
>> Cheers,
>> Fabrizio
>>
>> 2012/7/25 <stephan(a)stack.nl>
>>>
>>> Hi Doru,
>>>
>>> When thinking about scalability of Moose, what scenarios do you have
>>> in mind? Up to about half a terabyte, you can run out of main memory
>>> on a single machine cost-effectively. The main limitation there is
>>> the lack of a 64-bit vm and image. As far as I understand the access
>>> patterns involved, a main memory based or distributed main memory
>>> solution is far preferable for actually analyzing systems. What do you
>>> hope to achieve by going to disk? When we did the data conversion project,
>>> we thought about partitioning over multiple images but finally managed
>>> with partial loading.
>>>
>>> Stephan
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
Hi,
A topic that was raised recently is the scalability issue of Moose. Indeed, it would be great to have again some traction in this direction.
I think there are a couple of possibilities in this area:
- Gemstone. This is the straightforward idea and it would probably match quite well the FAMIX object-oriented model. The realization might not be that easy because we would need to go through all the details of the language independence. Also, we would need a remote UI, or at least a bridge for Glamour. Perhaps the Seaside interface of Glamour, or another Seaside-based one, would be a good direction.
- Graph DBs. http://neo4j.org/ would be an interesting target here. I have no experience in this area, but I would be very interested in collaborating with someone on this.
- Relational DBs. I know that Marco D'Ambros worked on a solution to map FAMIX meta-descriptions to Glorp in VW. And it seemed to work. I think Alberto Bacchelli is or has used it.
- Fuel. Loading with Fuel is about one order of magnitude faster than loading plain MSE: for example for ArgoUML 0.32 I got 108s for the MSE, and 17s for the Fuel based MSE information. So, having the Fuel export next to the MSE file can be a significant improvement. However, this solution only works when you have computations that treat one model at a time (so, it's not so nice if you have to switch between models all the time). I attached a simple script to analyze the difference between plain MSE loading and Fuel load variations.
- Filtered loading. This solution works well when you have the full model, but you do not need all of it. FMMetaRepositoryFilter offers the infrastructure for a filtered loading at the level of FAME: if you want to load a sub part of your model, you construct a sub-meta-model and then let Fame do the rest. This kind of works, but it is only available at the moment in code (look at the tests). We need to move to the next step of integrating this solution and replace the MooseImportingContext and possibly offer a UI as well.
If you want to pick up on any of these topics, let's open a separate thread and see what we can do.
Cheers,
Doru
--
www.tudorgirba.com
"We can create beautiful models in a vacuum.
But, to get them effective we have to deal with the inconvenience of reality."
Status: New
Owner: tudor.gi...(a)gmail.com
CC: alexandr...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7
New issue 815 by tudor.gi...(a)gmail.com: Roassal Mondrian builder does not
accept nodes that are not subclasses of Collection
http://code.google.com/p/moose-technology/issues/detail?id=815
The guard condition restricts unnecessarily:
nodes: objects
| els |
self assert: [ objects isKindOf: Collection] description: 'Should provide
a collection as parameter'.
Status: New
Owner: ----
CC: alexandr...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7
New issue 806 by tudor.gi...(a)gmail.com: Roassal does not store edges in the
proper place
http://code.google.com/p/moose-technology/issues/detail?id=806
If you do:
view nodes: #(1 2) forEach: [ :each |
view shape label.
view nodes: ({each * 10 . (each * 100)}).
view treeLayout.
].
view edgesFromAssociations: {10 -> 100. 20 -> 200}.
The inner nodes are not laid out in a tree. The reason is that the edges
are stored in the parent node that defines them, rather than in the most
specific common parent of the from and to nodes.
We got the same problem in Mondrian.
Hi!
I've just found this video:
http://cel.inf.usi.ch/index.php?action=gallery
I am not sure I really want to program a tetris that way, but the tool they have is interesting. It intensively use zooming in and out. When you zoom in, you see different objects and when you zoom out they disappear or they change their visual representation.
For Roassal, we are thinking about adding new graphical elements when a particular height of the camera is reached. The elements will then disappear when the camera is getting altitude. However, it looks a bit simple in my opinion. Is there any compelling scenario for a better mechanism?
Is there anything else you guys want to see in this zooming ability?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-MooseCore
New issue 814 by anquetil...(a)gmail.com: [MooseChef] Need to deal with
entities that don't have scope
http://code.google.com/p/moose-technology/issues/detail?id=814
This is linked to issue 812.
Making the change for this issue, highlighted a problem with scope:
Some queries might return objects that do not have scope (ex:
primitiveType, StructuralEntities, ...).
The result can be then filtered with withoutSelfLoop that relies on scope
There might be other example where one might ending up asking the scope of
an unscoped entity.
Possible solutions:
- ensure that all entities have a relevant scope in MooseChef
- create an "#unscoped" MooseChef scope and update MooseChef accordingly
- return nil when asking the scope of an unscoped entity, and reprogram
withoutSelfLoop to handle that case (not sure it is possible)
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
>
>
>
>
>
>