Hi Doru,
You recently worked on MOHorizontalDominanceOrderLayout. This break #testCoverageLayout.
Just try:
view nodes: (1 to: 100).
view edges: (1 to: 100) from: #yourself to: [:x | x + 1].
view layout: (MOHorizontalDominanceOrderLayout new)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hello,
I would like to know what are the tools provided by SmallDude?
I know there is the 'side by side duplication' view, is there other
visualizations ?
What kind of metrics are available ?
Hi!
Thanks to Simon, there is a MOQuadTree class and its tests in Mondrian. Quadtree is a tree data structure that is used to partition a two dimensional space by recursively subdividing it into four quadrants or regions. We could imagine plenty of new caches using quad trees.
I haven't seen any complain about speed anymore. However, I feel you restraint _yourself_ from pushing Mondrian to its limits :-)
If you experience any slowdown, please keep a description of what you have done before changing your visualization.
QuadTree are probably the way to go if we want to reach 1,000,000 nodes :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
Please try to avoid overrides in your packages. It makes integration
impossible.
Overrides can be useful when you do not have access to the base code.
But, in the case of Moose you do have access. Please, raise the point
and discuss about it if you are unsure of the change. You will be
surprised how often it is actually easy to change the base code, or it
is easy to find another solution.
Do not use overrides just because it's comfortable because in the
slightly longer run they harm more than they help.
Cheers,
Doru
--
www.tudorgirba.com
"What we can governs what we wish."
Hi!
Currently, Mondrian works only on Pharo (I do not have much interest in seeing it in Squeak, even though I am not against).
Should Mondrian use Grease? I have the feeling that we should not over-engineer Mondrian based on an assumption that is not verifiable currently (that Mondrian will be ported to a different Smalltalk).
I will remove from Mondrian all reference of Grease.
Cheers,
Alexandre
[*] http://blog.fitzell.ca/2010/01/easing-compatibility-with-grease.html
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
We sensibly run at the same pace than in mid-july.
Cheers,
Alexandre
Report produced on 2010-08-10T18:50:00-04:00
System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400
Benchmark ManyNode (simple rendering of nodes) :
100 nodes => 7 ms
200 nodes => 12 ms
300 nodes => 18 ms
400 nodes => 24 ms
500 nodes => 29 ms
600 nodes => 150 ms
700 nodes => 42 ms
800 nodes => 47 ms
900 nodes => 53 ms
1000 nodes => 60 ms
1600 nodes => 95 ms
3200 nodes => 186 ms
6400 nodes => 380 ms
Benchmark ManyEdges (simple rendering of edges) :
10 edges => 2 ms
20 edges => 8 ms
30 edges => 21 ms
40 edges => 38 ms
50 edges => 66 ms
60 edges => 104 ms
70 edges => 152 ms
80 edges => 227 ms
90 edges => 306 ms
100 edges => 418 ms
200 edges => 5172 ms
300 edges => 38460 ms
Benchmark ManyInnerNodes :
5 nodes => 175 ms
10 nodes => 2420 ms
15 nodes => 11174 ms
Benchmark Displaying ManyInnerNodes :
5 nodes => 154 ms
10 nodes => 850 ms
15 nodes => 10047 ms
Benchmark Displaying ManyInnerNodesAndEdges :
1 nodes => 9 ms
2 nodes => 240 ms
3 nodes => 3280 ms
4 nodes => 30758 ms
Benchmark Displaying elementAt :
100 nodes => 3 ms
500 nodes => 5 ms
1000 nodes => 9 ms
1500 nodes => 11 ms
2000 nodes => 14 ms
2500 nodes => 17 ms
Benchmark many small nodes :
2000 nodes => 2248 ms
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
The new version of Mondrian should make some of us happy. Before displaying the view, using the #open method, the view is rendered in a non displayed form. This means that if there is an error in your script, you will have a debugger instead of a freeze of the image.
This is something I should have done at least 1 year ago. But at least, now this is done.
If you have a scenario that freezes the image, please let me know. This is really annoying.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex,
I would need your help in introducing the ChildrenShape. Without this,
the FormsBuilder is highly underutilized.
The problem I have is that currently the drawing of the nested graphs
is handled on the Figure side, while it should be handled by the
Shape. So, I would need your help to move this behavior while still
preserving the caching logic.
The ChildrenShape should then override the display:on: to display
these elements.
Would you have time to look into this?
For example, the following code should define a umlClassShape:
| builder childrenShape titleShape umlClassShape |
childrenShape := MOChildrenShape new.
titleShape := MORectangleShape new text: 'Title'; fillColor: Color
transparent.
builder := MOFormsBuilder new.
builder column; center; fill; pref; grow.
builder row; center; pref; fill; grow; row; center; fill; pref; grow.
builder x: 1 y: 1 add: titleShape.
builder x: 1 y: 2 add: childrenShape.
umlClassShape := builder asShape.
view nodeShape: umlClassShape.
view nodes: (1 to: 3) forEach: [:each |
view nodes: (1 to: 10) ]
Cheers,
Doru
--
www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot
be done."
