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/
Hi all
allDeclaredProperties
^self mooseDescription computableAttributes
and I need computableAttributes
because apparently fame does not have that.
Stef
