Hi All,
Several time I saw the need to add a particular edge between two nodes
that I know. I added a new method addEdgeFrom:to: in ViewRenderer.
Here the appropriate test. Feel free to comment.
-=-=-=-=-=-=-=-=-=-=-=-=
testAddEdge
| view |
view := MOViewRenderer new.
view nodes: (1 to: 2).
view addEdgeFrom: 1 to: 2.
window := view open.
self assert: (view root edges size = 1).
self assert: (view root edges first source =
(view nodeForDomainValue: 1)).
self assert: (view root edges first target =
(view nodeForDomainValue: 2)).
-=-=-=-=-=-=-=-=-=-=-=-=
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Jannik,
I enhanced Mondrian with what you asked for (preferred size in
presence of subviews (was existing in VW but not in Pharo), extra
method for edge addition).
However, I still cannot open your DSM. The reason is that
FAMIX2Package does not understand color:
FAMIX2Package new color: Color blue
Again, I am not sure this is the best way to do this. Shape should be
aware of colors, not the domain.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi All,
I added a new package in Moose, that use Mondrian to display some
visualization. Moose is now dependent on Mondrian.
Rio is used for file accesses.
I updated MooseLoader.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi All,
On the LAN example, some metrics raise an exception:
FAMIXClass>>fanIn, fanOut, numberOfComments, tightClassCohesion
Just try:
MooseModel root first allClasses first tightClassCohesion
or
MooseModel root first allClasses first fanIn
I commented their pragma out in the last version of Famix-Core.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi All,
There is a problem I have been working on for a while.
Open an easel (MOEasel open), and execute the script
view shape: (MORectangleShape new width: 30; height: 20; text: 'A').
view nodes: (1 to: 20)
outer rectangles of the nodes do not get displayed correctly. I have
no clue why. The entry point I guess is MORectangleShape>>display:
anElement on: aCanvas
A beer for the one who found it :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi David and others,
Each OBNode understand the message definition. In the first version of
OB, this definition method is supposed to return an instance of
OBDefinition or one of its subclass.
I saw a way to have a graphical object instead of the text pane. What
is the trick to achieve this?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi All,
I was just wondering what the status is for loading MSE files into
Moose. I mean, getting a Moose Model from a Java application.
Just wondering.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex,
I saw that you removed FAMIXFunction from FAMIX-Core. Is there a
particular reason for this?
But, there is a larger issue here. FAMIX-Core is not meant to be
programmed, but instead it should be generate-able from the MSE
specification of FAMIX. So, basically a test should be to create an
MSE from the descriptions from FAMIX-Core and then regenerate exactly
the same classes back.
Like this, we can make sure that it remains portable and in sync (via
Fame) with implementations in other languages.
To deal with the implementation details, there is a Famix-
Implementation package.
Cheers,
Doru
--
www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot
be done."
Hi All,
I am slowing uncovering a problem with Moose-All. If I make a package
(let's say Moose-OBBrowser) and make it required to another one (let's
say Moose-All).
Before saving, I always check whether there is a new version in MC. If
there is one, I merge. But for some reason, merging remove the
dependency I just added.
Simon, were you trapped by this? There is a Moose-ModuleAlgorithms-
simon_denier.19 that is not loaded by Moose-All. Just wondering.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi list
No, it's neither a contest between me and Doru, nor a sudden frenzy
for big pictures hanging on the wall.
Here it is, although it's still not a final version (in particular,
I'm not satisfied with the catch phrase at the top)
http://rmod.lille.inria.fr/seaside/pier/people/Simon+Denier/mooseposter?_s=…
Comments are welcome, although the window is small as I will send it
tomorrow for printing.
Very important, I actually need some logos in pdf or graffle format
from the following teams/universities: SCG Bern, Lugano, VUB, Louvain
la Neuve, SOUL (to be put next to the RMoD logo)
Or I will try to reuse the ones found on the web.
--
Simon
Hello
I want to use EyeSee and I've some questions:
first, how to give different colors to 'Bars' into a verticalBarDiagram?
precisely, if: models := (models1 union: models2), how to say to diagram
that:
if models1 includes: current then
current visualBar color -> #green
else
current visualBar color -> #red
??
I did this but It does not work:
|diag models removedModels|
models := ...
removedModels := ...
diag := Smalltalk.EyeSee.DiagramRenderer new.
(diag verticalBarDiagram)
y: #size;
regularAxis;
gridLine;
color: [:each| models includes: each];
models: (models addAll: removedModels; yourself).
diag open.
thanks,
Hani
In this method, there is: #ErrorPrintingTheObject << #labels >> 'Error
printing the object'
I do not understand what this mean. Why not "self error: 'Error
printing the object'"
?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi list
I am looking for any media material (picture, screenshots of tools,
slideshow, videos, podcasts) related to Moose. Some could be put on
the website for the community, and I think they should be put in a
file repository to be shared under a CC licence.
Right now I am working on a poster for Moose and that's why I need
such materials.
--
Simon
Hi All,
Doru emitted a request on Mondrian. I added the class
MOFigureSelection to capture when a node is selected.
Example in:
MOViewRendererTest>>testFigureSelection
| view node1 announcer |
view := MOViewRenderer new.
view setUsefulHandlersForNodes.
announcer := view interaction.
view nodes: (1 to: 20).
node1 := view nodeForDomainValue: 1.
self deny: (node1 isSelected).
announcer announce: (MOFigureSelection event: nil on: node1).
self assert: (node1 isSelected).
Note that the message setUsefulHandlersForNodes should be sent to the
view. It is automatically sent within an easel. (maybe this is a point
we could discuss).
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex,
I guess this was meant for moose-dev :).
The previous/next point to other associations, and they can be used to
indicate the order of associations.
Cheers,
Doru
On 10 Mar 2009, at 22:59, Alexandre Bergel wrote:
> Dear list,
>
> Why an association has a previous and a next ?
> What are these variables for?
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Hey guys,
I use Fame (ver 0.372 form the bern store) and I want to generate code
for a metamodel. The code int the
AbstractCodeGenerator>>previewChanges does not compile.
As the image shows, it does not find the Sensor and ORChangeBrowser
classes. Is there another prerequisite that I should load.
Thanks,
Mircea.
Hi list
First I'm not proficient at all with how the visualworks UI works and
how to change the design within a widget.
I'm just *trying* to get the width of each item in the list below
larger, so that each displays the full text.
Poking around, it is a UI.SequenceViewSpec widget. I tried to change
the #style attribute, but it does not change the width.
--
Simon
Hi Jannik,
[Jannik is porting his work on DSM from VW to Pharo]
Currently, a view renderer does not understand the message newShape.
I am still unconvinced that having this newShape is a good thing.
Maybe Doru can tell us a bit more about that.
It is not obvious why a ShapeRenderer is necessary. It contains a list
of shapes that I cannot clearly figure out what this is useful for.
Cheers,
Alexandre
On 5 Mar 2009, at 18:28, Laval Jannik wrote:
> Est-il possible d'avoir la méthode newShape dans MOViewRenderer ?
>
> J'ai porté DSM sur Pharo et il a besoin de cette méthode.
> Je peux le faire si le portge est simple :)
>
> ---
> Jannik Laval
> PhD Student - Software Quality - INRIA
> Certified Project Management Associate (IPMA)
> http://www.jannik-laval.eu
> http://rmod.lille.inria.fr
> ---
>
>
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi there
I browse the code of SqMondrian to understand how it works (with the
previous help of Alex) and after a while, I wondered how the traversal
of nodes and edges was really done.
It seems like traversing the graph and drawing shapes are deeply
intertwined.
It took me a bit of time to figure out, but it seems that the
following method defined for the nil object is very important :)
UndefinedObject>>display: anElement on: aCanvas
anElement display: anElement on: aCanvas
The call sequence look like:
@rootnode#displayOn: -> nil#display: rootnode on: aCanvas -> (...)
rootnode children#displayOn: aCanvas -> ... -> shape#display: aNode
on: aCanvas -> nil display: aNode on: aCanvas -> aNode
children#displayOn: aCanvas -> .....
Or, from Root to nil to root children to child shape to nil to child
to children of child to shape to nil to ....etc.
It's quite weird how it always goes through nil to launch and continue
the traversal :)
Not discussing the previous design which had its own reason, but now
that we have separate composite shape, I think we can also separate
the nodes traversal logic from the shape drawing logic for clarity.
--
Simon
[Sorry for having part of this email in French, we are talking about
optimizing and graph traversal in SqMondrian]
> J'ai compris comment fonctionnait la traversée et le dessin des
> éléments/shapes dans Mondrian. En fait, les deux sont mixés
>
> A chaque fois que tu fais le display sur une shape, tu as :
>
> Shape>>display: anElement on: aCanvas
> (...)
> next display: anElement on: aCanvas
>
> Sauf que next est toujours à nil dans la version actuelle de
> Mondrian !
Legacy code.
Yes, I fixed this.
> et là c'est bon, on repart sur
> GraphElement>>display: anElement on: aCanvas
> aCanvas translateBy: self bounds origin during: [ :canvas |
> self nodes do: [ :each | each displayOn: canvas ].
> self edges do: [ :each | each displayOn: canvas ]
> ]
>
> NB: anElement est inutile dans les Element
You're right. We should fix this.
> La cerise sur le gateau : quand on lance le dessin sur le root node,
> on a
>
> Element>>shape
> display: self
> on: aCanvas
>
> mais shape est nil pour le Root node, donc on passe par
> UndefinedObject et là c'est bon :)
>
>
>
> OK il devrait y avoir moyen de clarifier ça pour faire la traversée
> directement niveau node dans displayOn: et pas via les Shape.
Yes, the shape knows nothing about the graph structure.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Simon,
Edges are quite slow to draw. I introduced a new method that
exemplifies such a situation. Just execute: MessageTally spyOn:
MOBenchmarks new edges
This method render 1000 times 30*30 edges.
You will see that 96% is spent in MOStraightLineShape>>display:on:
Within this 96%:
- about 37% in MOEdge(MOFigure)>>display:on: (26% in
BalloonCanvas(FormCanvas)>>translateBy:during:)
- about 33% in BalloonCanvas>>drawPath:borderWidth:borderColor:
- about 10% in MONode(MOFigure)>>bounds
There are rooms for improvement here. An obvious one is to replace
IdentityDictionary by RBIdentityDictionary. I just did this in the
last version of Mondrian, and I gained 26% of gain.
Apparently, the bounds is computed twice. This could probably be
optimized as well.
>> Je pense avoir trouvé une des raisons pour laquelle le dessin des
>> edge est si lent. Dans le code actual des displayOn:.... la
>> position des edge est recalculée à chaque fois. Le bounds des
>> element source/target est utilisé dans le calcul, mais le bounds du
>> edge lui-même n'est jamais initialisé et pas exploitable.
>
> Exemple pour StraightLineShape
> display: anElement on: aCanvas
> |bounds|
> bounds := anElement boundsOf: self.
> aCanvas
> drawPath: (Array
> with: (bounds origin)
> with: (bounds corner))
> borderWidth: (self widthFor: anElement)
> borderColor: (self colorFor: anElement).
> next display: anElement on: aCanvas
>
>
> Ca marche sauf si les node sont draggable, dans ce cas les bounds
> des edges ne sont pas mis a jour par le drag. C'est pas très clair
> comment propager un événement Node sur les Edge connectés pour
> l'instant
A MOGraphElement has a variable edges. I do not think this variable is
used at all. Maybe you could rename this variable edges -> cacheEdges
and use this variables to store outgoing edges.
I would like to enforce the fact that a variable is a cache. This is
an important information. It is often hard to distinguish variables
that are conceptually relevant, and the ones that are use to caches
values.
Thanks for your effort.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi all,
I'm developing a tool to mine mailing lists in Moose (called Maispion)
In this context, i'm playing with code_swarm[1]. It is a visualization
tool that shows the CVS commits history of a project.
Here's a *preliminary* video of the Moose mailing list i get from it
(tweaked to display emails instead of commits):
http://www.tulipemoutarde.be/documents/mooseDevMovie.avi
I have some ideas to improve it but would like to hear from you if you
have any suggestions to make this visualization cooler
(or, maybe, even useful :)
Cheers,
Francois
[1] http://vis.cs.ucdavis.edu/~ogawa/codeswarm/
