Hi guys
I would like to have an edge drawn from a package to the classes that use it. I did but it does not work
view interaction whenEnteringUpdateNode: [:node | view edgesToAll: #sureReferencingClasses.].
in
view shape rectangle. view interaction menuMorphBlock: [ :element | element mooseMenuMorph ].
view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view interaction menuMorphBlock: [ :element | element mooseMenuMorph ]. view interaction whenEnteringUpdateNode: [:node | view edgesToAll: #sureReferencingClasses.]. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout.
I tried
view shape rectangle. view interaction menuMorphBlock: [ :element | element mooseMenuMorph ].
view interaction whenEnteringUpdateNode: [:node | view edgesToAll: #sureReferencingClasses.]. view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view interaction menuMorphBlock: [ :element | element mooseMenuMorph ]. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout.
How can I get an edge between my nodes and a list of other nodes
Hi Stef,
I haven't looked closely at your example, but try the following and let me know whether this solves your problem or not:
view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10. ]
I added this example in the MOEasel.
Cheers, Alexandre
On 14 Jun 2011, at 10:18, Stéphane Ducasse wrote:
Hi guys
I would like to have an edge drawn from a package to the classes that use it. I did but it does not work
view interaction whenEnteringUpdateNode: [:node | view edgesToAll: #sureReferencingClasses.].
in
view shape rectangle. view interaction menuMorphBlock: [ :element | element mooseMenuMorph ].
view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view interaction menuMorphBlock: [ :element | element mooseMenuMorph ]. view interaction whenEnteringUpdateNode: [:node | view edgesToAll: #sureReferencingClasses.]. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout. _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jun 14, 2011, at 6:19 PM, Alexandre Bergel wrote:
Hi Stef,
I haven't looked closely at your example, but try the following and let me know whether this solves your problem or not:
view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10. ]
It seems to work but I do not understand what the edges: is the node that is entered. I could never succeed to find that. For me the API is bogus. I'm totally confused. Can you explain to me why the edges is the starting node?
Now when I do that the original shapes (squares inside squares) that I have turn into a single one and I do not understand why.
view shape rectangle. view interaction menuMorphBlock: [ :element | element mooseMenuMorph ]. view interaction whenEnteringUpdateNode: [:node | view edges: {node} from: #yourself toAll: #sureReferencingClasses.]. view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view interaction menuMorphBlock: [ :element | element mooseMenuMorph ]. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout.
stef
It seems to work but I do not understand what the edges: is the node that is entered.
I see the problem you're facing. Indeed, the syntax of Mondrian is a bit unintuitive. I recently introduced edgesFromAssociations: that makes it simpler to define edges. Consider the script: -=-=-=-=-=-=-=-= view nodes: (1 to: 5). view edgesFromAssociations: {1 -> 3 . 1 -> 5} -=-=-=-=-=-=-=-=
I could never succeed to find that. For me the API is bogus. I'm totally confused. Can you explain to me why the edges is the starting node?
The reason of "edges: nodes from: b1 to: b2" is to produce as much edges as there are nodes. For each node, an edge is created by evaluating b1 and b2 against the node.
Now when I do that the original shapes (squares inside squares) that I have turn into a single one and I do not understand why.
The interaction in Mondrian works well, but I agree this is a bit rough to use. The following: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= view interaction whenEnteringUpdateNode: [:node | view edges: {node} from: #yourself toAll: #sureReferencingClasses.]. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= means that when you enter the node, you replace everything under the node with some edges. You therefore discard the classes in it.
I propose two versions of your code. A long (and ugly one), and a much nicer one, but which does a slightly different thing:
The script draw edges between a packages and classes. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= view interaction whenEnteringUpdateNode: [:node | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: node classes. view gridLayout gapSize: 2. view edges: {node} from: #yourself toAll: #sureReferencingClasses ] whenLeavingUpdateNode: [:node | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: node classes. view gridLayout gapSize: 2 ] withLayoutUpdate: true. view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This version draws edges between classes -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view interaction whenEnteringUpdateNode: [:node | view edges: {node} from: #yourself toAll: #sureReferencingClasses ]. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On Jun 15, 2011, at 4:59 PM, Alexandre Bergel wrote:
It seems to work but I do not understand what the edges: is the node that is entered.
I see the problem you're facing. Indeed, the syntax of Mondrian is a bit unintuitive.
Yes may be having a pass on the renderer Api would be good
I recently introduced edgesFromAssociations: that makes it simpler to define edges. Consider the script:
view nodes: (1 to: 5). view edgesFromAssociations: {1 -> 3 . 1 -> 5} -=-=-=-=-=-=-=-=
I could never succeed to find that. For me the API is bogus. I'm totally confused. Can you explain to me why the edges is the starting node?
The reason of "edges: nodes from: b1 to: b2" is to produce as much edges as there are nodes. For each node, an edge is created by evaluating b1 and b2 against the node.
what do you mean by "by evaluating b1 and b2 against the node"
Now when I do that the original shapes (squares inside squares) that I have turn into a single one and I do not understand why.
The interaction in Mondrian works well, but I agree this is a bit rough to use. The following:
view interaction whenEnteringUpdateNode: [:node | view edges: {node} from: #yourself toAll: #sureReferencingClasses.]. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= means that when you enter the node, you replace everything under the node with some edges. You therefore discard the classes in it.
ah I could not get it then. Indeed the api sucks then
I propose two versions of your code. A long (and ugly one), and a much nicer one, but which does a slightly different thing:
thanks I will have a look.
The script draw edges between a packages and classes.
view interaction whenEnteringUpdateNode: [:node | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: node classes. view gridLayout gapSize: 2. view edges: {node} from: #yourself toAll: #sureReferencingClasses ]
whenLeavingUpdateNode: [:node | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: node classes. view gridLayout gapSize: 2 ] withLayoutUpdate: true. view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout.
This version draws edges between classes
view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view interaction whenEnteringUpdateNode: [:node | view edges: {node} from: #yourself toAll: #sureReferencingClasses ]. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
The reason of "edges: nodes from: b1 to: b2" is to produce as much edges as there are nodes. For each node, an edge is created by evaluating b1 and b2 against the node.
what do you mean by "by evaluating b1 and b2 against the node"
The code: view edges: (1 to: 3) from: #yourself to: [ :v | v * v] is equivalent to: view edgesFromAssociations: {1 -> 1 . 1 -> 4 . 1 -> 9}
Alexandre
Now when I do that the original shapes (squares inside squares) that I have turn into a single one and I do not understand why.
The interaction in Mondrian works well, but I agree this is a bit rough to use. The following:
view interaction whenEnteringUpdateNode: [:node | view edges: {node} from: #yourself toAll: #sureReferencingClasses.]. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= means that when you enter the node, you replace everything under the node with some edges. You therefore discard the classes in it.
ah I could not get it then. Indeed the api sucks then
I propose two versions of your code. A long (and ugly one), and a much nicer one, but which does a slightly different thing:
thanks I will have a look.
The script draw edges between a packages and classes.
view interaction whenEnteringUpdateNode: [:node | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: node classes. view gridLayout gapSize: 2. view edges: {node} from: #yourself toAll: #sureReferencingClasses ]
whenLeavingUpdateNode: [:node | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: node classes. view gridLayout gapSize: 2 ] withLayoutUpdate: true. view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout.
This version draws edges between classes
view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view interaction whenEnteringUpdateNode: [:node | view edges: {node} from: #yourself toAll: #sureReferencingClasses ]. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Stef,
view edges: collection from: block1 to: block2
tries to create a edge for "each" element in the "collection" between the nodes that have the following entities behind: - block1 value: each - block2 value: each
I say it tries because if the nodes are not found, the edge will not get created.
Cheers, Doru
On 15 Jun 2011, at 20:40, Alexandre Bergel wrote:
The reason of "edges: nodes from: b1 to: b2" is to produce as much edges as there are nodes. For each node, an edge is created by evaluating b1 and b2 against the node.
what do you mean by "by evaluating b1 and b2 against the node"
The code: view edges: (1 to: 3) from: #yourself to: [ :v | v * v] is equivalent to: view edgesFromAssociations: {1 -> 1 . 1 -> 4 . 1 -> 9}
Alexandre
Now when I do that the original shapes (squares inside squares) that I have turn into a single one and I do not understand why.
The interaction in Mondrian works well, but I agree this is a bit rough to use. The following:
view interaction whenEnteringUpdateNode: [:node | view edges: {node} from: #yourself toAll: #sureReferencingClasses.]. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= means that when you enter the node, you replace everything under the node with some edges. You therefore discard the classes in it.
ah I could not get it then. Indeed the api sucks then
I propose two versions of your code. A long (and ugly one), and a much nicer one, but which does a slightly different thing:
thanks I will have a look.
The script draw edges between a packages and classes.
view interaction whenEnteringUpdateNode: [:node | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: node classes. view gridLayout gapSize: 2. view edges: {node} from: #yourself toAll: #sureReferencingClasses ]
whenLeavingUpdateNode: [:node | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: node classes. view gridLayout gapSize: 2 ] withLayoutUpdate: true. view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout.
This version draws edges between classes
view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view interaction whenEnteringUpdateNode: [:node | view edges: {node} from: #yourself toAll: #sureReferencingClasses ]. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
On Jun 15, 2011, at 8:52 PM, Tudor Girba wrote:
Stef,
view edges: collection from: block1 to: block2
tries to create a edge for "each" element in the "collection" between the nodes that have the following entities behind:
- block1 value: each
- block2 value: each
Ok I finally got it.... but the api sucks
may be edges: should be edgesFromEntities: collection computeFrom: block1 computeTo: block2
it sucks also :)
edges: is bad because it does indicate that the entities are not edges:
buildEdgesFor: collection ....
Stef
On 15 Jun 2011, at 21:15, Stéphane Ducasse wrote:
On Jun 15, 2011, at 8:52 PM, Tudor Girba wrote:
Stef,
view edges: collection from: block1 to: block2
tries to create a edge for "each" element in the "collection" between the nodes that have the following entities behind:
- block1 value: each
- block2 value: each
Ok I finally got it.... but the api sucks
It does not :).
Doru
may be edges: should be
edgesFromEntities: collection computeFrom: block1 computeTo: block2
it sucks also :)
edges: is bad because it does indicate that the entities are not edges:
buildEdgesFor: collection ....
Stef
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
Stef,
view edges: collection from: block1 to: block2
tries to create a edge for "each" element in the "collection" between the nodes that have the following entities behind:
- block1 value: each
- block2 value: each
Ok I finally got it.... but the api sucks
It does not :).
So we were three to be at least confused and two of us did a lot of diagram with mondrian. May be the api is only usable by 3 + years in mondrian.
Stef
Hi,
On 15 Jun 2011, at 21:31, Stéphane Ducasse wrote:
Stef,
view edges: collection from: block1 to: block2
tries to create a edge for "each" element in the "collection" between the nodes that have the following entities behind:
- block1 value: each
- block2 value: each
Ok I finally got it.... but the api sucks
It does not :).
So we were three to be at least confused and two of us did a lot of diagram with mondrian. May be the api is only usable by 3 + years in mondrian.
Who are those that used Mondrian repeatedly and still cannot figure out what edges:from:to: means? I can think of several other issues (such as debugging a visualization), but I cannot imagine that someone cannot remember what a method with 3 parameters does, especially when that method has a long explanatory comment.
I know significantly more people that can use Mondrian, without knowing Smalltalk even :). That is not an argument, especially that no better alternative was proposed.
I just wanted to point out that "sucks" can easily spawn a simplistic debate :). Let's focus on what we want to have.
Cheers, Doru
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
On Jun 17, 2011, at 1:09 AM, Tudor Girba wrote:
Hi,
On 15 Jun 2011, at 21:31, Stéphane Ducasse wrote:
Stef,
view edges: collection from: block1 to: block2
tries to create a edge for "each" element in the "collection" between the nodes that have the following entities behind:
- block1 value: each
- block2 value: each
Ok I finally got it.... but the api sucks
It does not :).
So we were three to be at least confused and two of us did a lot of diagram with mondrian. May be the api is only usable by 3 + years in mondrian.
Who are those that used Mondrian repeatedly and still cannot figure out what edges:from:to: means? I can think of several other issues (such as debugging a visualization), but I cannot imagine that someone cannot remember what a method with 3 parameters does, especially when that method has a long explanatory comment.
so cyrille and jannik are plain silly. Too bad cyrille and jannik were our expert in mondrian here.
I know significantly more people that can use Mondrian, without knowing Smalltalk even :). That is not an argument, especially that no better alternative was proposed.
I just wanted to point out that "sucks" can easily spawn a simplistic debate :). Let's focus on what we want to have.
Something that tells me how to pass the correct arguments and edges: does not work because these are not the edges that you pass.
buildEdgesFrom: aCollection usingFrom: usingTo:
would be something in the right direction.
Cheers, Doru
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
On 18 Jun 2011, at 14:50, Stéphane Ducasse wrote:
On Jun 17, 2011, at 1:09 AM, Tudor Girba wrote:
Hi,
On 15 Jun 2011, at 21:31, Stéphane Ducasse wrote:
Stef,
view edges: collection from: block1 to: block2
tries to create a edge for "each" element in the "collection" between the nodes that have the following entities behind:
- block1 value: each
- block2 value: each
Ok I finally got it.... but the api sucks
It does not :).
So we were three to be at least confused and two of us did a lot of diagram with mondrian. May be the api is only usable by 3 + years in mondrian.
Who are those that used Mondrian repeatedly and still cannot figure out what edges:from:to: means? I can think of several other issues (such as debugging a visualization), but I cannot imagine that someone cannot remember what a method with 3 parameters does, especially when that method has a long explanatory comment.
so cyrille and jannik are plain silly. Too bad cyrille and jannik were our expert in mondrian here.
Something does not match. Could we be more specific?
Jannik and Cyrille are certainly not silly, especially that they did manage to write so many of these little pictures before :). So, it is obvious that what seems to constitute a problem now, was not a problem a while back.
Please let me know what exactly you did not understand. Was it that it was not clear what the block is applied to, or was it more that you did not know why an edge was not drawn, even if you thought that you wrote the right thing knowing what the method does?
And once you read the various examples, is it really that cryptic this method? Please also consider it from the point of view of the whole sentence: "view edges:from:to:"
I know significantly more people that can use Mondrian, without knowing Smalltalk even :). That is not an argument, especially that no better alternative was proposed.
I just wanted to point out that "sucks" can easily spawn a simplistic debate :). Let's focus on what we want to have.
Something that tells me how to pass the correct arguments and edges: does not work because these are not the edges that you pass.
buildEdgesFrom: aCollection usingFrom: usingTo: would be something in the right direction.
I suggest an even better approach:
buildEdgesFromACollectionWithEntities: usingATransformationBlockAppliedOnEachToGetTheOrigin: andUsingATransformationBlockAppliedOnEachToGetTheTarget:
Stef, this API is really no different than the API of Seaside. It is based a convention. You could argue in the same way that I do not know that I should pass a block after "html div: " and what that block should contain.
It is important to clarify the root of the problem, and I still doubt that the problem is in the name. I believe the problem comes more from the complexity of the operator (traversal + two transformations for each element + looking up corresponding nodes), and the lack of debugging possibilities in Mondrian. Or maybe it is something else.
So, let's take the positive side of this experience and see what is needed.
Cheers, Doru
Cheers, Doru
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Being happy is a matter of choice."
Something that tells me how to pass the correct arguments and edges: does not work because these are not the edges that you pass.
buildEdgesFrom: aCollection usingFrom: usingTo: would be something in the right direction.
I suggest an even better approach:
buildEdgesFromACollectionWithEntities: usingATransformationBlockAppliedOnEachToGetTheOrigin: andUsingATransformationBlockAppliedOnEachToGetTheTarget:
you are not fun because you do not want to listen. Perfect to me. I will not talk anymore.
jannik if you want to say something say it.
Stef
Hi,
On 18 Jun 2011, at 18:36, Stéphane Ducasse wrote:
Something that tells me how to pass the correct arguments and edges: does not work because these are not the edges that you pass.
buildEdgesFrom: aCollection usingFrom: usingTo: would be something in the right direction.
I suggest an even better approach:
buildEdgesFromACollectionWithEntities: usingATransformationBlockAppliedOnEachToGetTheOrigin: andUsingATransformationBlockAppliedOnEachToGetTheTarget:
you are not fun because you do not want to listen. Perfect to me. I will not talk anymore.
I think the fun was spoiled with "sucks", and I think it is a pity that the only thing that you replied to is my feeble attempt to a joke. I believe I brought in arguments, and that I wanted to discuss arguments. So, let's talk arguments.
Cheers, Doru
jannik if you want to say something say it.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"The coherence of a trip is given by the clearness of the goal."
Hi all,
Doru, I will just explain the context :) - we have a new big case study on a java source code. We need to build demonstration on-the-fly to show that: (i) our api is simple and efficient, and (ii) everybody can use it. - I did not build any visualization since 5 months, since I begin to write my thesis, and other papers.
So, when we would like to use Mondrian, the message edges:from:to: is a real problem. It is not the only one, but it illustrates well the problem. For me, edges:from:to: should be used like "edges: aCollectionOfAssociation from: #first to:#second". To give a collection of nodes is not intuitive for 2 reasons: - the first one is in my example: I always think to provide edges and not nodes. - the second is: why to give nodes ? we should have them because we are building a node-visualization. So the selection of good nodes should be done in the blocks from:to:. In fact, I think that a first thing to do is to use the methods edgesFrom:to: (that I just discover...)
Another problem that I encounter with Glamour also, is the debugging. And I really think that problems could be resolved with a good integration with the debugger. For now, it is not possible to understand easily why a script does not run as we want. We should think how to integrate the debugger in Mondrian and Glamour scripting.
The discussion is open :) Jannik
On Jun 18, 2011, at 19:03 , Tudor Girba wrote:
Hi,
On 18 Jun 2011, at 18:36, Stéphane Ducasse wrote:
Something that tells me how to pass the correct arguments and edges: does not work because these are not the edges that you pass.
buildEdgesFrom: aCollection usingFrom: usingTo: would be something in the right direction.
I suggest an even better approach:
buildEdgesFromACollectionWithEntities: usingATransformationBlockAppliedOnEachToGetTheOrigin: andUsingATransformationBlockAppliedOnEachToGetTheTarget:
Hi,
Thanks for the discussion, and sorry for the too long mail, but I did not know how to make it shorter.
Just for reference, there are three basic methods to construct graph elements in Mondrian: - nodes:using: - nodes:using:forEach: - edges:from:to:using:
(And then there is the layout specification: layout:)
These methods offer the means to construct a graph based on your model. They do that through transformations that take entities from your model and produce graph elements. The entities are always passed through the first argument. This is all you should remember.
These methods are like primitives. It might be that your requirements are a level higher and that you need more succinct methods, but these are the basics. All the other rendering methods in ViewRenderer are expressed in terms of these.
Actually, you might notice that you are basically not using any of these methods directly, but through some shortcut methods. However, the idea is that once you understand these methods you should be able to understand the other ones (like edgesFrom:to:)
On 19 Jun 2011, at 09:10, jannik.laval wrote:
Hi all,
Doru, I will just explain the context :)
- we have a new big case study on a java source code. We need to build demonstration on-the-fly to show that: (i) our api is simple and efficient, and (ii) everybody can use it.
- I did not build any visualization since 5 months, since I begin to write my thesis, and other papers.
So, when we would like to use Mondrian, the message edges:from:to: is a real problem. It is not the only one, but it illustrates well the problem. For me, edges:from:to: should be used like "edges: aCollectionOfAssociation from: #first to:#second".
You say it "should be used". But, why should it be used like that when the method is not that? Is it because this is what you think when you look at the name of the method. Or is it because this is what you would like to have as a simple mapping?
I am asking because this is not what the method says. It says "edges: aCollection from: aFromBlock to: aToBlock". The method wants you to provide entities that will be behind the edges. And the other two parameters are transformation blocks, not simple symbols.
It is clear that this is a complex operator. But, giving it another name won't make it easier to understand because the main problem comes from the complexity of the operations. You will inevitably have to learn what those are. And once you do know what they are, the logic becomes evident (at least from my experience).
It's like #do: in Smalltalk. This is highly cryptic for non-Smalltalkers mainly because they do not know what a block is. But, once you understand what a block is, it becomes clear and elegant. It's the same here.
To give a collection of nodes is not intuitive for 2 reasons:
- the first one is in my example: I always think to provide edges and not nodes.
You do not provide edges, or nodes. You provide entities. I believe this is the root of the problem. You are looking at it from the other perspective, which might be valid, but it is not what Mondrian does.
The key is to remember that Mondrian is a transformation engine and that it works with models that do not have nodes and edges, but only entities. You map them on nodes and edges. Perhaps this is what needs to be documented.
- the second is: why to give nodes ? we should have them because we are building a node-visualization. So the selection of good nodes should be done in the blocks from:to:.
In fact, I think that a first thing to do is to use the methods edgesFrom:to: (that I just discover...)
This is a shortcut - see above. There are several such shortcuts in ViewRenderer. Maybe they need to be better documented.
Another problem that I encounter with Glamour also, is the debugging. And I really think that problems could be resolved with a good integration with the debugger. For now, it is not possible to understand easily why a script does not run as we want. We should think how to integrate the debugger in Mondrian and Glamour scripting.
Exactly, this is the key next step!
The discussion is open :)
Thanks :).
Cheers, Doru
Jannik
On Jun 18, 2011, at 19:03 , Tudor Girba wrote:
Hi,
On 18 Jun 2011, at 18:36, Stéphane Ducasse wrote:
Something that tells me how to pass the correct arguments and edges: does not work because these are not the edges that you pass.
buildEdgesFrom: aCollection usingFrom: usingTo: would be something in the right direction.
I suggest an even better approach:
buildEdgesFromACollectionWithEntities: usingATransformationBlockAppliedOnEachToGetTheOrigin: andUsingATransformationBlockAppliedOnEachToGetTheTarget:
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
Hi Doru,
Thank you for the explanation.
On Jun 19, 2011, at 10:32 , Tudor Girba wrote:
Hi,
Thanks for the discussion, and sorry for the too long mail, but I did not know how to make it shorter.
Just for reference, there are three basic methods to construct graph elements in Mondrian:
- nodes:using:
- nodes:using:forEach:
- edges:from:to:using:
(And then there is the layout specification: layout:)
These methods offer the means to construct a graph based on your model. They do that through transformations that take entities from your model and produce graph elements. The entities are always passed through the first argument. This is all you should remember.
These methods are like primitives. It might be that your requirements are a level higher and that you need more succinct methods, but these are the basics. All the other rendering methods in ViewRenderer are expressed in terms of these.
Actually, you might notice that you are basically not using any of these methods directly, but through some shortcut methods. However, the idea is that once you understand these methods you should be able to understand the other ones (like edgesFrom:to:)
Ok, I understand. Now, we should explain it better to redirect new users on the right methods. Maybe, we should put these methods on a protocol named "primitive".
On 19 Jun 2011, at 09:10, jannik.laval wrote:
Hi all,
Doru, I will just explain the context :)
- we have a new big case study on a java source code. We need to build demonstration on-the-fly to show that: (i) our api is simple and efficient, and (ii) everybody can use it.
- I did not build any visualization since 5 months, since I begin to write my thesis, and other papers.
So, when we would like to use Mondrian, the message edges:from:to: is a real problem. It is not the only one, but it illustrates well the problem. For me, edges:from:to: should be used like "edges: aCollectionOfAssociation from: #first to:#second".
You say it "should be used". But, why should it be used like that when the method is not that? Is it because this is what you think when you look at the name of the method. Or is it because this is what you would like to have as a simple mapping?
I know that the method is not that. But when I see the signature, this is what I imagine. And maybe another name can help to understand it.
I am asking because this is not what the method says. It says "edges: aCollection from: aFromBlock to: aToBlock". The method wants you to provide entities that will be behind the edges. And the other two parameters are transformation blocks, not simple symbols.
It is clear that this is a complex operator. But, giving it another name won't make it easier to understand because the main problem comes from the complexity of the operations. You will inevitably have to learn what those are. And once you do know what they are, the logic becomes evident (at least from my experience).
It's like #do: in Smalltalk. This is highly cryptic for non-Smalltalkers mainly because they do not know what a block is. But, once you understand what a block is, it becomes clear and elegant. It's the same here.
To give a collection of nodes is not intuitive for 2 reasons:
- the first one is in my example: I always think to provide edges and not nodes.
You do not provide edges, or nodes. You provide entities. I believe this is the root of the problem. You are looking at it from the other perspective, which might be valid, but it is not what Mondrian does.
The key is to remember that Mondrian is a transformation engine and that it works with models that do not have nodes and edges, but only entities. You map them on nodes and edges. Perhaps this is what needs to be documented.
yes, I understand that. I know that we manipulate entities. but each node has an entity behind. And behind edges there are association of entities. What is strange for me is to provide a collection of entities that should be connected with edges, whereas they are provided before in the script.
Ok, I am understanding that I should not see this method in the process but as a generic method :)
- the second is: why to give nodes ? we should have them because we are building a node-visualization. So the selection of good nodes should be done in the blocks from:to:.
In fact, I think that a first thing to do is to use the methods edgesFrom:to: (that I just discover...)
This is a shortcut - see above. There are several such shortcuts in ViewRenderer. Maybe they need to be better documented.
Yes, we should do that.
Another problem that I encounter with Glamour also, is the debugging. And I really think that problems could be resolved with a good integration with the debugger. For now, it is not possible to understand easily why a script does not run as we want. We should think how to integrate the debugger in Mondrian and Glamour scripting.
Exactly, this is the key next step!
Cool :)))
The discussion is open :)
Thanks :).
Thank you for your explanations, again :) Jannik
Cheers, Doru
Jannik
On Jun 18, 2011, at 19:03 , Tudor Girba wrote:
Hi,
On 18 Jun 2011, at 18:36, Stéphane Ducasse wrote:
Something that tells me how to pass the correct arguments and edges: does not work because these are not the edges that you pass.
buildEdgesFrom: aCollection usingFrom: usingTo: would be something in the right direction.
I suggest an even better approach:
buildEdgesFromACollectionWithEntities: usingATransformationBlockAppliedOnEachToGetTheOrigin: andUsingATransformationBlockAppliedOnEachToGetTheTarget:
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
Thank you for the explanation.
My pleasure :). But now, let's see if we can make it better. There are two actions that seem to come out of the discussion: - do a pass over the comments to better reveal that the input collections are always entities (both behind nodes and behind edges) - reorganize the protocols of ViewRenderer to reveal better the structure of the API
The other thing would be the debugging capabilities.
Who would want to work on these? :)
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
On Jun 19, 2011, at 14:21 , Tudor Girba wrote:
Hi,
Thank you for the explanation.
My pleasure :). But now, let's see if we can make it better. There are two actions that seem to come out of the discussion:
- do a pass over the comments to better reveal that the input collections are always entities (both behind nodes and behind edges)
- reorganize the protocols of ViewRenderer to reveal better the structure of the API
The other thing would be the debugging capabilities.
Who would want to work on these? :)
I will do :) I will begin to work on Moose, on tuesday. I want also to work on DSM.
Jannik
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 19 Jun 2011, at 14:33, jannik.laval wrote:
On Jun 19, 2011, at 14:21 , Tudor Girba wrote:
Hi,
Thank you for the explanation.
My pleasure :). But now, let's see if we can make it better. There are two actions that seem to come out of the discussion:
- do a pass over the comments to better reveal that the input collections are always entities (both behind nodes and behind edges)
- reorganize the protocols of ViewRenderer to reveal better the structure of the API
The other thing would be the debugging capabilities.
Who would want to work on these? :)
I will do :) I will begin to work on Moose, on tuesday. I want also to work on DSM.
Great!
Keep us posted. I will open another thread about DSM.
Doru
Jannik
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We are all great at making mistakes."
For what it is worth: While I was in Chile last year Alexandre, Johan and I designed and (I think) partly implemented an alternative Mondrian API. The idea was to avoid these multi-argument selectors (like in the Seaside API) and have it much more composable and uniform. Not sure what happened with that?
Lukas
On 19 June 2011 14:37, Tudor Girba tudor@tudorgirba.com wrote:
On 19 Jun 2011, at 14:33, jannik.laval wrote:
On Jun 19, 2011, at 14:21 , Tudor Girba wrote:
Hi,
Thank you for the explanation.
My pleasure :). But now, let's see if we can make it better. There are two actions that seem to come out of the discussion:
- do a pass over the comments to better reveal that the input collections are always entities (both behind nodes and behind edges)
- reorganize the protocols of ViewRenderer to reveal better the structure of the API
The other thing would be the debugging capabilities.
Who would want to work on these? :)
I will do :) I will begin to work on Moose, on tuesday. I want also to work on DSM.
Great!
Keep us posted. I will open another thread about DSM.
Doru
Jannik
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We are all great at making mistakes."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
That would be interesting to look at.
Cheers, Doru
On 19 Jun 2011, at 18:19, Lukas Renggli wrote:
For what it is worth: While I was in Chile last year Alexandre, Johan and I designed and (I think) partly implemented an alternative Mondrian API. The idea was to avoid these multi-argument selectors (like in the Seaside API) and have it much more composable and uniform. Not sure what happened with that?
Lukas
On 19 June 2011 14:37, Tudor Girba tudor@tudorgirba.com wrote:
On 19 Jun 2011, at 14:33, jannik.laval wrote:
On Jun 19, 2011, at 14:21 , Tudor Girba wrote:
Hi,
Thank you for the explanation.
My pleasure :). But now, let's see if we can make it better. There are two actions that seem to come out of the discussion:
- do a pass over the comments to better reveal that the input collections are always entities (both behind nodes and behind edges)
- reorganize the protocols of ViewRenderer to reveal better the structure of the API
The other thing would be the debugging capabilities.
Who would want to work on these? :)
I will do :) I will begin to work on Moose, on tuesday. I want also to work on DSM.
Great!
Keep us posted. I will open another thread about DSM.
Doru
Jannik
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We are all great at making mistakes."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Live like you mean it."
I think that this is more than just having correct/good comments....
is the parameter passed to edges: consistent? I do not think so at least from what I understood
edges: from: to: and aView edges: someFamixInvocations from: #sender toAll: #candidates show different cases.
Now if nodes: except a collection of entities playing the node role why edges is not a collection of antities playing edges role?
Corollary why in some cases this is the case and in other not?
Now the comments are absent and not consistent: "aCollection is the collection of edges to represent." is it correct?
edges: aCollection from: aFromBlock "- aCollection is the collection of edges to represent. - aFromBlock will be called on each element of the collection and return one edge source each time. Note that there is no restriction on the elements of aCollection, as long as aFromBlock returns a node. "
aCollection is a bad name for an argument.
Same here..... even if this is a bit better because there is one example showing that the comment is not wrong.
edges: aCollection from: aFromBlock toAll: aToBlock "- aCollection is the collection of edges to represent. - aFromBlock will be called on each element of the collection and return one edge source each time. - aToBlock will be called similarly to return a collection of destination correpsonding to each source. Note that there is no restriction on the elements of aCollection, as long as aFromBlock returns a node and aToBlock returns a collection of nodes. For example: aView edges: someFamixInvocations from: #sender toAll: #candidates aToBlock should return a collection, edges will be drawn from the element returned by aFromBlock to this collection" ^self edges: aCollection from: aFromBlock toAll: aToBlock using: self edgeShape
Stef
Hi Stef,
On 20 Jun 2011, at 13:18, Stéphane Ducasse wrote:
I think that this is more than just having correct/good comments....
is the parameter passed to edges: consistent? I do not think so
It is consistent. All the time the first argument sent to edges:from:to and nodes: is meant to hold a collection of entities that will be the model behind the graph element. In the case of nodes, there is no fancy transformation. In the case of edge, there are two transformations. That is all.
If you find a case in which this is not true, then we need to fix that.
at least from what I understood
edges: from: to: and aView edges: someFamixInvocations from: #sender toAll: #candidates
show different cases.
Now if nodes: except a collection of entities playing the node role why edges is not a collection of antities playing edges role?
It is.
Corollary why in some cases this is the case and in other not?
Just the comments are misleading. It is always the same. Only when you have something marked differently, you expect a different input, like edgesFromAssociations: which expect to have a collection of associations. But those are just convenience.
Now the comments are absent and not consistent: "aCollection is the collection of edges to represent." is it correct?
No. It's a collection of entities. The comment is bogus :)
edges: aCollection from: aFromBlock "- aCollection is the collection of edges to represent.
- aFromBlock will be called on each element of the collection and return one edge source each time.
Note that there is no restriction on the elements of aCollection, as long as aFromBlock returns a node. "
aCollection is a bad name for an argument.
I agree. It should be aCollectionOfEntities.
Same here..... even if this is a bit better because there is one example showing that the comment is not wrong.
edges: aCollection from: aFromBlock toAll: aToBlock "- aCollection is the collection of edges to represent.
- aFromBlock will be called on each element of the collection and return one edge source each time.
- aToBlock will be called similarly to return a collection of destination correpsonding to each source.
Note that there is no restriction on the elements of aCollection, as long as aFromBlock returns a node and aToBlock returns a collection of nodes. For example: aView edges: someFamixInvocations from: #sender toAll: #candidates
aToBlock should return a collection, edges will be drawn from the element returned by aFromBlock to this collection"
^self edges: aCollection from: aFromBlock toAll: aToBlock using: self edgeShape
Again, the comment needs to be fixed.
Does this clarify the situation?
Doru
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
On Jun 20, 2011, at 1:32 PM, Tudor Girba wrote:
Hi Stef,
On 20 Jun 2011, at 13:18, Stéphane Ducasse wrote:
I think that this is more than just having correct/good comments....
is the parameter passed to edges: consistent? I do not think so
It is consistent. All the time the first argument sent to edges:from:to and nodes: is meant to hold a collection of entities that will be the model behind the graph element. In the case of nodes, there is no fancy transformation. In the case of edge, there are two transformations. That is all.
If you find a case in which this is not true, then we need to fix that.
at least from what I understood
edges: from: to: and aView edges: someFamixInvocations from: #sender toAll: #candidates
show different cases.
Now if nodes: except a collection of entities playing the node role why edges is not a collection of antities playing edges role?
It is.
No it is not You have to send messages to nodes to get edges so the collection is not an edge collection
Corollary why in some cases this is the case and in other not?
Just the comments are misleading. It is always the same. Only when you have something marked differently, you expect a different input, like edgesFromAssociations: which expect to have a collection of associations. But those are just convenience.
I really lost then. Because in
view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
aValue is a node not an Edge?
I always have the problem with mondrian that what I say is wrong. It is a wonderful feeling.
Now I see what the API says
is Oh nodes: nodes you specify nodes with nodes nice
but you specify edges with nodes...... not nice
edges: nodes
And for me this is confusing. Because why do I have to remember that edges: is not about edges but about nodes that will generate information about edge. What you call declarative for me is really confusing.
Now changing aCollection to aCollectionOfEntities only work is you explain systematically in the comments that theses are entities in fact the entities that are not first class relationship and nodes that can generate information to represent the edges. Else without context collectionOfEntities look like collection of objects.
Again, the comment needs to be fixed.
Does this clarify the situation?
Yes but I do not like it. Why because
edges: from: to: is connoted
Since math exist edges: are edges and not vertices from: is a vertex and to: another vertex
So if I need to build visualization in Mondrian I will build a layer on top a layer for idiots like me.
buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable
Now I would really like to have a non declarative way of expressing that. In fact I do not even understand why a declarative way is supposed to be better than an imperative one. Especially because most of the time the order is important in Mondrian.
Declarations does not talk to me and the the stack semantics of Mondrian is difficult to understand and debug. And do not dream there will be no debugger able to debug Mondrian scripts in the close future. So we are left with method names and arguments and guessing right.
What frustrate me with mondrian is that I'm programming in lisp without any debugger, but worse not printf..... So I start fast and boum I hit the wall and got trapped in DSL swamps.
Stef
Hi,
I am repeating for the n-th time: The input to Mondrian are not nodes & edges. The input are only entities which can be anything. The engine simply provides a means to transform your entities into nodes and edges.
Take this point of view, and you will see that it becomes consistent :)
You keep on repeating that you are passing nodes to the edges:, but you are not. You are always passing some entities from which the edges are to be constructed. That is all. It just happens that you choose to use the same entity as a model for both an node and an edge. It is clear that if there is no easy mapping between the entity model and the graph model, the script can become cumbersome.
Let's take your example: view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
First, this example is not instructive because it takes several shortcuts, but let's just focus on aValue.
In your script, aValue is the value behind the node, not the node. The node is another object. Then you use it also as the model for the edge because you do not have anything else. So, you will have the same aValue object used both for creating the node and for creating the edge.
So, a method like buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable is wrong in the context of Mondrian, because it uses the wrong vocabulary.
How is that? :)
Cheers, Doru
On 20 Jun 2011, at 14:15, Stéphane Ducasse wrote:
On Jun 20, 2011, at 1:32 PM, Tudor Girba wrote:
Hi Stef,
On 20 Jun 2011, at 13:18, Stéphane Ducasse wrote:
I think that this is more than just having correct/good comments....
is the parameter passed to edges: consistent? I do not think so
It is consistent. All the time the first argument sent to edges:from:to and nodes: is meant to hold a collection of entities that will be the model behind the graph element. In the case of nodes, there is no fancy transformation. In the case of edge, there are two transformations. That is all.
If you find a case in which this is not true, then we need to fix that.
at least from what I understood
edges: from: to: and aView edges: someFamixInvocations from: #sender toAll: #candidates
show different cases.
Now if nodes: except a collection of entities playing the node role why edges is not a collection of antities playing edges role?
It is.
No it is not You have to send messages to nodes to get edges so the collection is not an edge collection
Corollary why in some cases this is the case and in other not?
Just the comments are misleading. It is always the same. Only when you have something marked differently, you expect a different input, like edgesFromAssociations: which expect to have a collection of associations. But those are just convenience.
I really lost then. Because in
view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
aValue is a node not an Edge?
I always have the problem with mondrian that what I say is wrong. It is a wonderful feeling.
Now I see what the API says
is Oh nodes: nodes you specify nodes with nodes nice
but you specify edges with nodes...... not nice
edges: nodesAnd for me this is confusing. Because why do I have to remember that edges: is not about edges but about nodes that will generate information about edge. What you call declarative for me is really confusing.
Now changing aCollection to aCollectionOfEntities only work is you explain systematically in the comments that theses are entities in fact the entities that are not first class relationship and nodes that can generate information to represent the edges. Else without context collectionOfEntities look like collection of objects.
Again, the comment needs to be fixed.
Does this clarify the situation?
Yes but I do not like it. Why because
edges: from: to: is connoted
Since math exist edges: are edges and not vertices from: is a vertex and to: another vertex
So if I need to build visualization in Mondrian I will build a layer on top a layer for idiots like me.
buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable
Now I would really like to have a non declarative way of expressing that. In fact I do not even understand why a declarative way is supposed to be better than an imperative one. Especially because most of the time the order is important in Mondrian.
Declarations does not talk to me and the the stack semantics of Mondrian is difficult to understand and debug. And do not dream there will be no debugger able to debug Mondrian scripts in the close future. So we are left with method names and arguments and guessing right.
What frustrate me with mondrian is that I'm programming in lisp without any debugger, but worse not printf..... So I start fast and boum I hit the wall and got trapped in DSL swamps.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Guys,
For what it is worth, may I suggest that this discussion is going nowhere? If each one keeps repeating the same argument this is going to be a very long argument with nasty side effects (not on the software).
Now, may be the problem is that the "input to Mondrian are not nodes & edges"? Because it is based on a graph model and we do use it to represent graphs, so naturally, one expects to use it that way ... The next questions are: What does it use as input? And why is it not just plain edges&nodes?
I think, that the answer "The input are only entities which can be anything" is not satisfying because users will naturally be thinking in terms of what they want to see in the end: nodes&edges.
nicolas
PS: By the way, the buggy comment is mine, I proposed it when first trying to understand how things worked. I, also, did not find it very intuitive that edges: does not simply take a collection of edges as parameter.
I am repeating for the n-th time: The input to Mondrian are not nodes & edges. The input are only entities which can be anything. The engine simply provides a means to transform your entities into nodes and edges.
Take this point of view, and you will see that it becomes consistent :)
You keep on repeating that you are passing nodes to the edges:, but you are not. You are always passing some entities from which the edges are to be constructed. That is all. It just happens that you choose to use the same entity as a model for both an node and an edge. It is clear that if there is no easy mapping between the entity model and the graph model, the script can become cumbersome.
Let's take your example: view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
First, this example is not instructive because it takes several shortcuts, but let's just focus on aValue.
In your script, aValue is the value behind the node, not the node. The node is another object. Then you use it also as the model for the edge because you do not have anything else. So, you will have the same aValue object used both for creating the node and for creating the edge.
So, a method like buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable is wrong in the context of Mondrian, because it uses the wrong vocabulary.
How is that? :)
Cheers, Doru
On 20 Jun 2011, at 14:15, Stéphane Ducasse wrote:
On Jun 20, 2011, at 1:32 PM, Tudor Girba wrote:
Hi Stef,
On 20 Jun 2011, at 13:18, Stéphane Ducasse wrote:
I think that this is more than just having correct/good comments....
is the parameter passed to edges: consistent? I do not think so
It is consistent. All the time the first argument sent to edges:from:to and nodes: is meant to hold a collection of entities that will be the model behind the graph element. In the case of nodes, there is no fancy transformation. In the case of edge, there are two transformations. That is all.
If you find a case in which this is not true, then we need to fix that.
at least from what I understood
edges: from: to: and aView edges: someFamixInvocations from: #sender toAll: #candidates
show different cases.
Now if nodes: except a collection of entities playing the node role why edges is not a collection of antities playing edges role?
It is.
No it is not You have to send messages to nodes to get edges so the collection is not an edge collection
Corollary why in some cases this is the case and in other not?
Just the comments are misleading. It is always the same. Only when you have something marked differently, you expect a different input, like edgesFromAssociations: which expect to have a collection of associations. But those are just convenience.
I really lost then. Because in
view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
aValue is a node not an Edge?
I always have the problem with mondrian that what I say is wrong. It is a wonderful feeling.
Now I see what the API says
is Oh nodes: nodes you specify nodes with nodes nice
but you specify edges with nodes...... not nice
edges: nodesAnd for me this is confusing. Because why do I have to remember that edges: is not about edges but about nodes that will generate information about edge. What you call declarative for me is really confusing.
Now changing aCollection to aCollectionOfEntities only work is you explain systematically in the comments that theses are entities in fact the entities that are not first class relationship and nodes that can generate information to represent the edges. Else without context collectionOfEntities look like collection of objects.
Again, the comment needs to be fixed.
Does this clarify the situation?
Yes but I do not like it. Why because
edges: from: to: is connoted
Since math exist edges: are edges and not vertices from: is a vertex and to: another vertex
So if I need to build visualization in Mondrian I will build a layer on top a layer for idiots like me.
buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable
Now I would really like to have a non declarative way of expressing that. In fact I do not even understand why a declarative way is supposed to be better than an imperative one. Especially because most of the time the order is important in Mondrian.
Declarations does not talk to me and the the stack semantics of Mondrian is difficult to understand and debug. And do not dream there will be no debugger able to debug Mondrian scripts in the close future. So we are left with method names and arguments and guessing right.
What frustrate me with mondrian is that I'm programming in lisp without any debugger, but worse not printf..... So I start fast and boum I hit the wall and got trapped in DSL swamps.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
On 20 Jun 2011, at 15:11, Nicolas Anquetil wrote:
Guys,
For what it is worth, may I suggest that this discussion is going nowhere? If each one keeps repeating the same argument this is going to be a very long argument with nasty side effects (not on the software).
I do not mean to annoy anyone. I actually thought we were actually making progress (no joke). I think we are all trying to explain what we think, but I think there is a mismatch in the points of view, and somehow it just does not seem to come out right :)
I am interested in getting it right, because it can produce a nice documentation, or it might uncover some other solutions.
Now, may be the problem is that the "input to Mondrian are not nodes & edges"? Because it is based on a graph model and we do use it to represent graphs, so naturally, one expects to use it that way ... The next questions are: What does it use as input? And why is it not just plain edges&nodes?
Because you do not always have a natural set of edges in your entity model. For example, in Smalltalk, there is no object that represents inheritance, and yet you would want to represent inheritance as an edge visually. Visually :). So, to do that, you will take the class as the model of the edge and draw the edge from that class to the #superclass.
Now, if you do have an object that represents a relationship, then by all means use it as the model behind the edge. For example, for the same example of inheritance, in FAMIX we would use FAMIXInheritance.
In other cases, you have only relations without natural nodes. For example, if you have a collection of mails that have senders and receivers as strings, the mail is a relation, but the nodes need to be constructed.
The idea of Mondrian is to not limit the possibility of visualizing to only graph models. That is why you have blocks as transformations.
I think, that the answer "The input are only entities which can be anything" is not satisfying because users will naturally be thinking in terms of what they want to see in the end: nodes&edges
How is it now?
nicolas
PS: By the way, the buggy comment is mine, I proposed it when first trying to understand how things worked. I, also, did not find it very intuitive that edges: does not simply take a collection of edges as parameter.
No problem :)
Doru
I am repeating for the n-th time: The input to Mondrian are not nodes & edges. The input are only entities which can be anything. The engine simply provides a means to transform your entities into nodes and edges.
Take this point of view, and you will see that it becomes consistent :)
You keep on repeating that you are passing nodes to the edges:, but you are not. You are always passing some entities from which the edges are to be constructed. That is all. It just happens that you choose to use the same entity as a model for both an node and an edge. It is clear that if there is no easy mapping between the entity model and the graph model, the script can become cumbersome.
Let's take your example: view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
First, this example is not instructive because it takes several shortcuts, but let's just focus on aValue.
In your script, aValue is the value behind the node, not the node. The node is another object. Then you use it also as the model for the edge because you do not have anything else. So, you will have the same aValue object used both for creating the node and for creating the edge.
So, a method like buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable is wrong in the context of Mondrian, because it uses the wrong vocabulary.
How is that? :)
Cheers, Doru
On 20 Jun 2011, at 14:15, Stéphane Ducasse wrote:
On Jun 20, 2011, at 1:32 PM, Tudor Girba wrote:
Hi Stef,
On 20 Jun 2011, at 13:18, Stéphane Ducasse wrote:
I think that this is more than just having correct/good comments....
is the parameter passed to edges: consistent? I do not think so
It is consistent. All the time the first argument sent to edges:from:to and nodes: is meant to hold a collection of entities that will be the model behind the graph element. In the case of nodes, there is no fancy transformation. In the case of edge, there are two transformations. That is all.
If you find a case in which this is not true, then we need to fix that.
at least from what I understood
edges: from: to: and aView edges: someFamixInvocations from: #sender toAll: #candidates
show different cases.
Now if nodes: except a collection of entities playing the node role why edges is not a collection of antities playing edges role?
It is.
No it is not You have to send messages to nodes to get edges so the collection is not an edge collection
Corollary why in some cases this is the case and in other not?
Just the comments are misleading. It is always the same. Only when you have something marked differently, you expect a different input, like edgesFromAssociations: which expect to have a collection of associations. But those are just convenience.
I really lost then. Because in
view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
aValue is a node not an Edge?
I always have the problem with mondrian that what I say is wrong. It is a wonderful feeling.
Now I see what the API says
is Oh nodes: nodes you specify nodes with nodes nice
but you specify edges with nodes...... not nice
edges: nodesAnd for me this is confusing. Because why do I have to remember that edges: is not about edges but about nodes that will generate information about edge. What you call declarative for me is really confusing.
Now changing aCollection to aCollectionOfEntities only work is you explain systematically in the comments that theses are entities in fact the entities that are not first class relationship and nodes that can generate information to represent the edges. Else without context collectionOfEntities look like collection of objects.
Again, the comment needs to be fixed.
Does this clarify the situation?
Yes but I do not like it. Why because
edges: from: to: is connoted
Since math exist edges: are edges and not vertices from: is a vertex and to: another vertex
So if I need to build visualization in Mondrian I will build a layer on top a layer for idiots like me.
buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable
Now I would really like to have a non declarative way of expressing that. In fact I do not even understand why a declarative way is supposed to be better than an imperative one. Especially because most of the time the order is important in Mondrian.
Declarations does not talk to me and the the stack semantics of Mondrian is difficult to understand and debug. And do not dream there will be no debugger able to debug Mondrian scripts in the close future. So we are left with method names and arguments and guessing right.
What frustrate me with mondrian is that I'm programming in lisp without any debugger, but worse not printf..... So I start fast and boum I hit the wall and got trapped in DSL swamps.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
It might be clearer now. May be the problem is that what would seem a "normal case" is considered equal to the "exception" ?
May be an acceptable solution would be to consider "you do not have a natural set of edges in your entity model" as an exception and make a special method for that (edges:from:to: with another name), and consider that the normal case is that one does have entities for the edges?
nicoals
----- Mail original -----
De: "Tudor Girba" tudor@tudorgirba.com À: "Moose-related development" moose-dev@iam.unibe.ch Envoyé: Lundi 20 Juin 2011 15:28:55 Objet: [Moose-dev] Re: Mondrian question Hi,
On 20 Jun 2011, at 15:11, Nicolas Anquetil wrote:
Guys,
For what it is worth, may I suggest that this discussion is going nowhere? If each one keeps repeating the same argument this is going to be a very long argument with nasty side effects (not on the software).
I do not mean to annoy anyone. I actually thought we were actually making progress (no joke). I think we are all trying to explain what we think, but I think there is a mismatch in the points of view, and somehow it just does not seem to come out right :)
I am interested in getting it right, because it can produce a nice documentation, or it might uncover some other solutions.
Now, may be the problem is that the "input to Mondrian are not nodes & edges"? Because it is based on a graph model and we do use it to represent graphs, so naturally, one expects to use it that way ... The next questions are: What does it use as input? And why is it not just plain edges&nodes?
Because you do not always have a natural set of edges in your entity model. For example, in Smalltalk, there is no object that represents inheritance, and yet you would want to represent inheritance as an edge visually. Visually :). So, to do that, you will take the class as the model of the edge and draw the edge from that class to the #superclass.
Now, if you do have an object that represents a relationship, then by all means use it as the model behind the edge. For example, for the same example of inheritance, in FAMIX we would use FAMIXInheritance.
In other cases, you have only relations without natural nodes. For example, if you have a collection of mails that have senders and receivers as strings, the mail is a relation, but the nodes need to be constructed.
The idea of Mondrian is to not limit the possibility of visualizing to only graph models. That is why you have blocks as transformations.
I think, that the answer "The input are only entities which can be anything" is not satisfying because users will naturally be thinking in terms of what they want to see in the end: nodes&edges
How is it now?
nicolas
PS: By the way, the buggy comment is mine, I proposed it when first trying to understand how things worked. I, also, did not find it very intuitive that edges: does not simply take a collection of edges as parameter.
No problem :)
Doru
I am repeating for the n-th time: The input to Mondrian are not nodes & edges. The input are only entities which can be anything. The engine simply provides a means to transform your entities into nodes and edges.
Take this point of view, and you will see that it becomes consistent :)
You keep on repeating that you are passing nodes to the edges:, but you are not. You are always passing some entities from which the edges are to be constructed. That is all. It just happens that you choose to use the same entity as a model for both an node and an edge. It is clear that if there is no easy mapping between the entity model and the graph model, the script can become cumbersome.
Let's take your example: view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
First, this example is not instructive because it takes several shortcuts, but let's just focus on aValue.
In your script, aValue is the value behind the node, not the node. The node is another object. Then you use it also as the model for the edge because you do not have anything else. So, you will have the same aValue object used both for creating the node and for creating the edge.
So, a method like buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable is wrong in the context of Mondrian, because it uses the wrong vocabulary.
How is that? :)
Cheers, Doru
On 20 Jun 2011, at 14:15, Stéphane Ducasse wrote:
On Jun 20, 2011, at 1:32 PM, Tudor Girba wrote:
Hi Stef,
On 20 Jun 2011, at 13:18, Stéphane Ducasse wrote:
I think that this is more than just having correct/good comments....
is the parameter passed to edges: consistent? I do not think so
It is consistent. All the time the first argument sent to edges:from:to and nodes: is meant to hold a collection of entities that will be the model behind the graph element. In the case of nodes, there is no fancy transformation. In the case of edge, there are two transformations. That is all.
If you find a case in which this is not true, then we need to fix that.
at least from what I understood
edges: from: to: and aView edges: someFamixInvocations from: #sender toAll: #candidates
show different cases.
Now if nodes: except a collection of entities playing the node role why edges is not a collection of antities playing edges role?
It is.
No it is not You have to send messages to nodes to get edges so the collection is not an edge collection
Corollary why in some cases this is the case and in other not?
Just the comments are misleading. It is always the same. Only when you have something marked differently, you expect a different input, like edgesFromAssociations: which expect to have a collection of associations. But those are just convenience.
I really lost then. Because in
view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
aValue is a node not an Edge?
I always have the problem with mondrian that what I say is wrong. It is a wonderful feeling.
Now I see what the API says
is Oh nodes: nodes you specify nodes with nodes nice
but you specify edges with nodes...... not nice
edges: nodesAnd for me this is confusing. Because why do I have to remember that edges: is not about edges but about nodes that will generate information about edge. What you call declarative for me is really confusing.
Now changing aCollection to aCollectionOfEntities only work is you explain systematically in the comments that theses are entities in fact the entities that are not first class relationship and nodes that can generate information to represent the edges. Else without context collectionOfEntities look like collection of objects.
Again, the comment needs to be fixed.
Does this clarify the situation?
Yes but I do not like it. Why because
edges: from: to: is connoted
Since math exist edges: are edges and not vertices from: is a vertex and to: another vertex
So if I need to build visualization in Mondrian I will build a layer on top a layer for idiots like me.
buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable
Now I would really like to have a non declarative way of expressing that. In fact I do not even understand why a declarative way is supposed to be better than an imperative one. Especially because most of the time the order is important in Mondrian.
Declarations does not talk to me and the the stack semantics of Mondrian is difficult to understand and debug. And do not dream there will be no debugger able to debug Mondrian scripts in the close future. So we are left with method names and arguments and guessing right.
What frustrate me with mondrian is that I'm programming in lisp without any debugger, but worse not printf..... So I start fast and boum I hit the wall and got trapped in DSL swamps.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jun 20, 2011, at 3:38 PM, Nicolas Anquetil wrote:
It might be clearer now. May be the problem is that what would seem a "normal case" is considered equal to the "exception" ?
May be an acceptable solution would be to consider "you do not have a natural set of edges in your entity model" as an exception and make a special method for that (edges:from:to: with another name), and consider that the normal case is that one does have entities for the edges?
not sure it will work. :) I would have to really understand it first. but edges: from: to: is conceptually problematic compared to nodes:
and I fully understand what doru is saying. Yes I can understand now with all my cleverness but my raw stef does not because edges: is not nodes:
Stef
nicoals
----- Mail original -----
De: "Tudor Girba" tudor@tudorgirba.com À: "Moose-related development" moose-dev@iam.unibe.ch Envoyé: Lundi 20 Juin 2011 15:28:55 Objet: [Moose-dev] Re: Mondrian question Hi,
On 20 Jun 2011, at 15:11, Nicolas Anquetil wrote:
Guys,
For what it is worth, may I suggest that this discussion is going nowhere? If each one keeps repeating the same argument this is going to be a very long argument with nasty side effects (not on the software).
I do not mean to annoy anyone. I actually thought we were actually making progress (no joke). I think we are all trying to explain what we think, but I think there is a mismatch in the points of view, and somehow it just does not seem to come out right :)
I am interested in getting it right, because it can produce a nice documentation, or it might uncover some other solutions.
Now, may be the problem is that the "input to Mondrian are not nodes & edges"? Because it is based on a graph model and we do use it to represent graphs, so naturally, one expects to use it that way ... The next questions are: What does it use as input? And why is it not just plain edges&nodes?
Because you do not always have a natural set of edges in your entity model. For example, in Smalltalk, there is no object that represents inheritance, and yet you would want to represent inheritance as an edge visually. Visually :). So, to do that, you will take the class as the model of the edge and draw the edge from that class to the #superclass.
Now, if you do have an object that represents a relationship, then by all means use it as the model behind the edge. For example, for the same example of inheritance, in FAMIX we would use FAMIXInheritance.
In other cases, you have only relations without natural nodes. For example, if you have a collection of mails that have senders and receivers as strings, the mail is a relation, but the nodes need to be constructed.
The idea of Mondrian is to not limit the possibility of visualizing to only graph models. That is why you have blocks as transformations.
I think, that the answer "The input are only entities which can be anything" is not satisfying because users will naturally be thinking in terms of what they want to see in the end: nodes&edges
How is it now?
nicolas
PS: By the way, the buggy comment is mine, I proposed it when first trying to understand how things worked. I, also, did not find it very intuitive that edges: does not simply take a collection of edges as parameter.
No problem :)
Doru
I am repeating for the n-th time: The input to Mondrian are not nodes & edges. The input are only entities which can be anything. The engine simply provides a means to transform your entities into nodes and edges.
Take this point of view, and you will see that it becomes consistent :)
You keep on repeating that you are passing nodes to the edges:, but you are not. You are always passing some entities from which the edges are to be constructed. That is all. It just happens that you choose to use the same entity as a model for both an node and an edge. It is clear that if there is no easy mapping between the entity model and the graph model, the script can become cumbersome.
Let's take your example: view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
First, this example is not instructive because it takes several shortcuts, but let's just focus on aValue.
In your script, aValue is the value behind the node, not the node. The node is another object. Then you use it also as the model for the edge because you do not have anything else. So, you will have the same aValue object used both for creating the node and for creating the edge.
So, a method like buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable is wrong in the context of Mondrian, because it uses the wrong vocabulary.
How is that? :)
Cheers, Doru
On 20 Jun 2011, at 14:15, Stéphane Ducasse wrote:
On Jun 20, 2011, at 1:32 PM, Tudor Girba wrote:
Hi Stef,
On 20 Jun 2011, at 13:18, Stéphane Ducasse wrote:
> I think that this is more than just having correct/good > comments.... > > is the parameter passed to edges: consistent? I do not think so
It is consistent. All the time the first argument sent to edges:from:to and nodes: is meant to hold a collection of entities that will be the model behind the graph element. In the case of nodes, there is no fancy transformation. In the case of edge, there are two transformations. That is all.
If you find a case in which this is not true, then we need to fix that.
> at least from what I understood > > edges: from: to: > and > aView edges: someFamixInvocations from: #sender toAll: > #candidates > > show different cases. > > Now if nodes: except a collection of entities playing the node > role > why edges is not a collection of antities playing edges role?
It is.
No it is not You have to send messages to nodes to get edges so the collection is not an edge collection
> Corollary why in some cases this is the case and in other not?
Just the comments are misleading. It is always the same. Only when you have something marked differently, you expect a different input, like edgesFromAssociations: which expect to have a collection of associations. But those are just convenience.
I really lost then. Because in
view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
aValue is a node not an Edge?
I always have the problem with mondrian that what I say is wrong. It is a wonderful feeling.
Now I see what the API says
is Oh nodes: nodes you specify nodes with nodes nice
but you specify edges with nodes...... not nice
edges: nodesAnd for me this is confusing. Because why do I have to remember that edges: is not about edges but about nodes that will generate information about edge. What you call declarative for me is really confusing.
Now changing aCollection to aCollectionOfEntities only work is you explain systematically in the comments that theses are entities in fact the entities that are not first class relationship and nodes that can generate information to represent the edges. Else without context collectionOfEntities look like collection of objects.
Again, the comment needs to be fixed.
Does this clarify the situation?
Yes but I do not like it. Why because
edges: from: to: is connoted
Since math exist edges: are edges and not vertices from: is a vertex and to: another vertex
So if I need to build visualization in Mondrian I will build a layer on top a layer for idiots like me.
buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable
Now I would really like to have a non declarative way of expressing that. In fact I do not even understand why a declarative way is supposed to be better than an imperative one. Especially because most of the time the order is important in Mondrian.
Declarations does not talk to me and the the stack semantics of Mondrian is difficult to understand and debug. And do not dream there will be no debugger able to debug Mondrian scripts in the close future. So we are left with method names and arguments and guessing right.
What frustrate me with mondrian is that I'm programming in lisp without any debugger, but worse not printf..... So I start fast and boum I hit the wall and got trapped in DSL swamps.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jun 20, 2011, at 3:28 PM, Tudor Girba wrote:
Hi,
On 20 Jun 2011, at 15:11, Nicolas Anquetil wrote:
Guys,
For what it is worth, may I suggest that this discussion is going nowhere? If each one keeps repeating the same argument this is going to be a very long argument with nasty side effects (not on the software).
I do not mean to annoy anyone. I actually thought we were actually making progress (no joke). I think we are all trying to explain what we think, but I think there is a mismatch in the points of view, and somehow it just does not seem to come out right :)
sure
I am interested in getting it right, because it can produce a nice documentation, or it might uncover some other solutions.
Now, may be the problem is that the "input to Mondrian are not nodes & edges"? Because it is based on a graph model and we do use it to represent graphs, so naturally, one expects to use it that way ... The next questions are: What does it use as input? And why is it not just plain edges&nodes?
Because you do not always have a natural set of edges in your entity model. For example, in Smalltalk, there is no object that represents inheritance, and yet you would want to represent inheritance as an edge visually. Visually :). So, to do that, you will take the class as the model of the edge and draw the edge from that class to the #superclass.
sure but do not called it just edges: but generateEdgesFrom:
Now, if you do have an object that represents a relationship, then by all means use it as the model behind the edge. For example, for the same example of inheritance, in FAMIX we would use FAMIXInheritance.
In other cases, you have only relations without natural nodes. For example, if you have a collection of mails that have senders and receivers as strings, the mail is a relation, but the nodes need to be constructed.
The idea of Mondrian is to not limit the possibility of visualizing to only graph models. That is why you have blocks as transformations.
Yes We know all that :)
I think, that the answer "The input are only entities which can be anything" is not satisfying because users will naturally be thinking in terms of what they want to see in the end: nodes&edges
How is it now?
The same. This is about the mental model of the person that sit and try.
nicolas
PS: By the way, the buggy comment is mine, I proposed it when first trying to understand how things worked. I, also, did not find it very intuitive that edges: does not simply take a collection of edges as parameter.
No problem :)
Doru
I am repeating for the n-th time: The input to Mondrian are not nodes & edges. The input are only entities which can be anything. The engine simply provides a means to transform your entities into nodes and edges.
Take this point of view, and you will see that it becomes consistent :)
You keep on repeating that you are passing nodes to the edges:, but you are not. You are always passing some entities from which the edges are to be constructed. That is all. It just happens that you choose to use the same entity as a model for both an node and an edge. It is clear that if there is no easy mapping between the entity model and the graph model, the script can become cumbersome.
Let's take your example: view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
First, this example is not instructive because it takes several shortcuts, but let's just focus on aValue.
In your script, aValue is the value behind the node, not the node. The node is another object. Then you use it also as the model for the edge because you do not have anything else. So, you will have the same aValue object used both for creating the node and for creating the edge.
So, a method like buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable is wrong in the context of Mondrian, because it uses the wrong vocabulary.
How is that? :)
Cheers, Doru
On 20 Jun 2011, at 14:15, Stéphane Ducasse wrote:
On Jun 20, 2011, at 1:32 PM, Tudor Girba wrote:
Hi Stef,
On 20 Jun 2011, at 13:18, Stéphane Ducasse wrote:
I think that this is more than just having correct/good comments....
is the parameter passed to edges: consistent? I do not think so
It is consistent. All the time the first argument sent to edges:from:to and nodes: is meant to hold a collection of entities that will be the model behind the graph element. In the case of nodes, there is no fancy transformation. In the case of edge, there are two transformations. That is all.
If you find a case in which this is not true, then we need to fix that.
at least from what I understood
edges: from: to: and aView edges: someFamixInvocations from: #sender toAll: #candidates
show different cases.
Now if nodes: except a collection of entities playing the node role why edges is not a collection of antities playing edges role?
It is.
No it is not You have to send messages to nodes to get edges so the collection is not an edge collection
Corollary why in some cases this is the case and in other not?
Just the comments are misleading. It is always the same. Only when you have something marked differently, you expect a different input, like edgesFromAssociations: which expect to have a collection of associations. But those are just convenience.
I really lost then. Because in
view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
aValue is a node not an Edge?
I always have the problem with mondrian that what I say is wrong. It is a wonderful feeling.
Now I see what the API says
is Oh nodes: nodes you specify nodes with nodes nice
but you specify edges with nodes...... not nice
edges: nodesAnd for me this is confusing. Because why do I have to remember that edges: is not about edges but about nodes that will generate information about edge. What you call declarative for me is really confusing.
Now changing aCollection to aCollectionOfEntities only work is you explain systematically in the comments that theses are entities in fact the entities that are not first class relationship and nodes that can generate information to represent the edges. Else without context collectionOfEntities look like collection of objects.
Again, the comment needs to be fixed.
Does this clarify the situation?
Yes but I do not like it. Why because
edges: from: to: is connoted
Since math exist edges: are edges and not vertices from: is a vertex and to: another vertex
So if I need to build visualization in Mondrian I will build a layer on top a layer for idiots like me.
buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable
Now I would really like to have a non declarative way of expressing that. In fact I do not even understand why a declarative way is supposed to be better than an imperative one. Especially because most of the time the order is important in Mondrian.
Declarations does not talk to me and the the stack semantics of Mondrian is difficult to understand and debug. And do not dream there will be no debugger able to debug Mondrian scripts in the close future. So we are left with method names and arguments and guessing right.
What frustrate me with mondrian is that I'm programming in lisp without any debugger, but worse not printf..... So I start fast and boum I hit the wall and got trapped in DSL swamps.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jun 20, 2011, at 2:46 PM, Tudor Girba wrote:
Hi,
I am repeating for the n-th time: The input to Mondrian are not nodes & edges. The input are only entities which can be anything. The engine simply provides a means to transform your entities into nodes and edges.
Yes I know :) still some entities map to edges and to nodes. and pther to both
Take this point of view, and you will see that it becomes consistent :)
You keep on repeating that you are passing nodes to the edges:, but you are not. You are always passing some entities from which the edges are to be constructed. That is all. It just happens that you choose to use the same entity as a model for both an node and an edge. It is clear that if there is no easy mapping between the entity model and the graph model, the script can become cumbersome.
Let's take your example: view node: 'node' forIt: [ view interaction whenEnteringUpdateNode: [ :aValue | view edges: {aValue} from: #yourself toAll: ((1 to: 9) copyWithout: aValue ) ].
view shape rectangle size: 30. view nodes: (1 to: 9). view gridLayout gapSize: 10.
First, this example is not instructive because it takes several shortcuts, but let's just focus on aValue.
Why it is not instructive this is what I was trying to build. I asked and I got that.
In your script, aValue is the value behind the node, not the node.
I know so what
The node is another object.
I know that luckily
Then you use it also as the model for the edge because you do not have anything else.
Yes
So, you will have the same aValue object used both for creating the node and for creating the edge.
Yes
So, a method like buildEdgesFromVertices: nodes fromAccessor: aValuable toAccessor: aValuable is wrong in the context of Mondrian, because it uses the wrong vocabulary.
How is that? :)
Does not help because I knew that more or less. I even put an self inspect to understand what was node.
I think that mondrian DSL violates basic assumption about vertex and edges that the user can have. So we will rape his cognitive load. Ok. Let us rape him.
Of course I know that arguments are not nodes and edges still there is a mismatch between nodes: acollectionOfEntitiesThatConceptuallyPlayTheRoelOfNodes and edges: acollectionOfEntitiesThatDoNotConceptuallyPlayTheRoelOfEdgesButAreTheNodesOnes.
So we will learn by heart that the arguments of edges is not an entity representing an edge.
No need to reply because all your explanations does not change that fact.
Stef
edges: aCollection from: aFromBlock "- aCollection is the collection of edges to represent.
- aFromBlock will be called on each element of the collection and return one edge source each time.
Note that there is no restriction on the elements of aCollection, as long as aFromBlock returns a node. "
aCollection is a bad name for an argument.
I agree. It should be aCollectionOfEntities.
I renamed "aCollection" into "aCollectionOfEntities" in all the edges:* methods. I also replace "aCollection is the collection of edges to represent." by " aCollectionOfEntities is the collection of from which the edges are defined from."
Now in Version 2.107 of Mondrian
Cheers, Alexandre
Same here..... even if this is a bit better because there is one example showing that the comment is not wrong.
edges: aCollection from: aFromBlock toAll: aToBlock "- aCollection is the collection of edges to represent.
- aFromBlock will be called on each element of the collection and return one edge source each time.
- aToBlock will be called similarly to return a collection of destination correpsonding to each source.
Note that there is no restriction on the elements of aCollection, as long as aFromBlock returns a node and aToBlock returns a collection of nodes. For example: aView edges: someFamixInvocations from: #sender toAll: #candidates
aToBlock should return a collection, edges will be drawn from the element returned by aFromBlock to this collection"
^self edges: aCollection from: aFromBlock toAll: aToBlock using: self edgeShape
Again, the comment needs to be fixed.
Does this clarify the situation?
Doru
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Thanks alex
On Jun 20, 2011, at 2:52 PM, Alexandre Bergel wrote:
edges: aCollection from: aFromBlock "- aCollection is the collection of edges to represent.
- aFromBlock will be called on each element of the collection and return one edge source each time.
Note that there is no restriction on the elements of aCollection, as long as aFromBlock returns a node. "
aCollection is a bad name for an argument.
I agree. It should be aCollectionOfEntities.
I renamed "aCollection" into "aCollectionOfEntities" in all the edges:* methods. I also replace "aCollection is the collection of edges to represent." by " aCollectionOfEntities is the collection of from which the edges are defined from."
Now in Version 2.107 of Mondrian
Cheers, Alexandre
Same here..... even if this is a bit better because there is one example showing that the comment is not wrong.
edges: aCollection from: aFromBlock toAll: aToBlock "- aCollection is the collection of edges to represent.
- aFromBlock will be called on each element of the collection and return one edge source each time.
- aToBlock will be called similarly to return a collection of destination correpsonding to each source.
Note that there is no restriction on the elements of aCollection, as long as aFromBlock returns a node and aToBlock returns a collection of nodes. For example: aView edges: someFamixInvocations from: #sender toAll: #candidates
aToBlock should return a collection, edges will be drawn from the element returned by aFromBlock to this collection"
^self edges: aCollection from: aFromBlock toAll: aToBlock using: self edgeShape
Again, the comment needs to be fixed.
Does this clarify the situation?
Doru
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
The package MondrianNew in the squeaksource repository of Mondrian contains a bunch of classes we quickly defined: MORenderer>> addEdge: addEdges: addNode: addNodes:
MOEdgeFactory>> from:to:
MONodeFactory>> on:
Cheers, Alexandre
On 19 Jun 2011, at 17:52, Tudor Girba wrote:
That would be interesting to look at.
Cheers, Doru
On 19 Jun 2011, at 18:19, Lukas Renggli wrote:
For what it is worth: While I was in Chile last year Alexandre, Johan and I designed and (I think) partly implemented an alternative Mondrian API. The idea was to avoid these multi-argument selectors (like in the Seaside API) and have it much more composable and uniform. Not sure what happened with that?
Lukas
On 19 June 2011 14:37, Tudor Girba tudor@tudorgirba.com wrote:
On 19 Jun 2011, at 14:33, jannik.laval wrote:
On Jun 19, 2011, at 14:21 , Tudor Girba wrote:
Hi,
Thank you for the explanation.
My pleasure :). But now, let's see if we can make it better. There are two actions that seem to come out of the discussion:
- do a pass over the comments to better reveal that the input collections are always entities (both behind nodes and behind edges)
- reorganize the protocols of ViewRenderer to reveal better the structure of the API
The other thing would be the debugging capabilities.
Who would want to work on these? :)
I will do :) I will begin to work on Moose, on tuesday. I want also to work on DSM.
Great!
Keep us posted. I will open another thread about DSM.
Doru
Jannik
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We are all great at making mistakes."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Live like you mean it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jun 20, 2011, at 3:03 PM, Alexandre Bergel wrote:
The package MondrianNew in the squeaksource repository of Mondrian contains a bunch of classes we quickly defined: MORenderer>> addEdge: addEdges: addNode: addNodes:
MOEdgeFactory>> from:to:
MONodeFactory>> on:
How should use that? Do you have examples?
Stef
Cheers, Alexandre
On 19 Jun 2011, at 17:52, Tudor Girba wrote:
That would be interesting to look at.
Cheers, Doru
On 19 Jun 2011, at 18:19, Lukas Renggli wrote:
For what it is worth: While I was in Chile last year Alexandre, Johan and I designed and (I think) partly implemented an alternative Mondrian API. The idea was to avoid these multi-argument selectors (like in the Seaside API) and have it much more composable and uniform. Not sure what happened with that?
Lukas
On 19 June 2011 14:37, Tudor Girba tudor@tudorgirba.com wrote:
On 19 Jun 2011, at 14:33, jannik.laval wrote:
On Jun 19, 2011, at 14:21 , Tudor Girba wrote:
Hi,
> Thank you for the explanation.
My pleasure :). But now, let's see if we can make it better. There are two actions that seem to come out of the discussion:
- do a pass over the comments to better reveal that the input collections are always entities (both behind nodes and behind edges)
- reorganize the protocols of ViewRenderer to reveal better the structure of the API
The other thing would be the debugging capabilities.
Who would want to work on these? :)
I will do :) I will begin to work on Moose, on tuesday. I want also to work on DSM.
Great!
Keep us posted. I will open another thread about DSM.
Doru
Jannik
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We are all great at making mistakes."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Live like you mean it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
For example: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | renderer node1 node2 edge | renderer := MORenderer new. node1 := renderer node on: 'hello'. node2 := renderer node on: 'world'. edge := renderer edge from: node1 to: node2. renderer addNodes: {node1 . node2}. renderer addEdge: edge. renderer layout horizontalLine. renderer element applyLayout. renderer open -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The result is:
Another example: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= renderer := MORenderer new. node1 := renderer node on: 'hello'. triangleShape := renderer shape triangle. triangleShape width: [ :v | v size * 10 ]. triangleShape height: [ :v | v size * 20 ]. node1 shape: triangleShape.
node2 := renderer node on: 'world'. node2 shape: (circleShape := renderer shape ellipse). edge := renderer edge from: node1 to: node2. renderer layout horizontalLine. renderer element applyLayout.
renderer addNodes: {node1 . node2}. renderer addEdge: edge. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The result is:
Cheers, Alexandre
On 20 Jun 2011, at 09:40, Stéphane Ducasse wrote:
On Jun 20, 2011, at 3:03 PM, Alexandre Bergel wrote:
The package MondrianNew in the squeaksource repository of Mondrian contains a bunch of classes we quickly defined: MORenderer>> addEdge: addEdges: addNode: addNodes:
MOEdgeFactory>> from:to:
MONodeFactory>> on:
How should use that? Do you have examples?
Stef
Cheers, Alexandre
On 19 Jun 2011, at 17:52, Tudor Girba wrote:
That would be interesting to look at.
Cheers, Doru
On 19 Jun 2011, at 18:19, Lukas Renggli wrote:
For what it is worth: While I was in Chile last year Alexandre, Johan and I designed and (I think) partly implemented an alternative Mondrian API. The idea was to avoid these multi-argument selectors (like in the Seaside API) and have it much more composable and uniform. Not sure what happened with that?
Lukas
On 19 June 2011 14:37, Tudor Girba tudor@tudorgirba.com wrote:
On 19 Jun 2011, at 14:33, jannik.laval wrote:
On Jun 19, 2011, at 14:21 , Tudor Girba wrote:
> Hi, > >> Thank you for the explanation. > > My pleasure :). But now, let's see if we can make it better. There are two actions that seem to come out of the discussion: > - do a pass over the comments to better reveal that the input collections are always entities (both behind nodes and behind edges) > - reorganize the protocols of ViewRenderer to reveal better the structure of the API > > The other thing would be the debugging capabilities. > > Who would want to work on these? :)
I will do :) I will begin to work on Moose, on tuesday. I want also to work on DSM.
Great!
Keep us posted. I will open another thread about DSM.
Doru
Jannik
> > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every successful trip needs a suitable vehicle." > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We are all great at making mistakes."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Live like you mean it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jun 20, 2011, at 3:48 PM, Alexandre Bergel wrote:
For example:
| renderer node1 node2 edge | renderer := MORenderer new. node1 := renderer node on: 'hello'.
for: may be better?
node2 := renderer node on: 'world'.
edge := renderer edge from: node1 to: node2.
renderer addNodes: {node1 . node2}. renderer addEdge: edge.
Now this is true that this is a bit strange to have to add explicit nodes and edges
renderer layout horizontalLine. renderer element applyLayout. renderer open -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The result is: <Screen shot 2011-06-20 at 09.48.18.png>
Another example:
renderer := MORenderer new. node1 := renderer node on: 'hello'. triangleShape := renderer shape triangle. triangleShape width: [ :v | v size * 10 ]. triangleShape height: [ :v | v size * 20 ]. node1 shape: triangleShape.
node2 := renderer node on: 'world'. node2 shape: (circleShape := renderer shape ellipse). edge := renderer edge from: node1 to: node2. renderer layout horizontalLine. renderer element applyLayout.
renderer addNodes: {node1 . node2}. renderer addEdge: edge. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The result is: <Screen shot 2011-06-20 at 09.47.47.png>
Cheers, Alexandre
On 20 Jun 2011, at 09:40, Stéphane Ducasse wrote:
On Jun 20, 2011, at 3:03 PM, Alexandre Bergel wrote:
The package MondrianNew in the squeaksource repository of Mondrian contains a bunch of classes we quickly defined: MORenderer>> addEdge: addEdges: addNode: addNodes:
MOEdgeFactory>> from:to:
MONodeFactory>> on:
How should use that? Do you have examples?
Stef
Cheers, Alexandre
On 19 Jun 2011, at 17:52, Tudor Girba wrote:
That would be interesting to look at.
Cheers, Doru
On 19 Jun 2011, at 18:19, Lukas Renggli wrote:
For what it is worth: While I was in Chile last year Alexandre, Johan and I designed and (I think) partly implemented an alternative Mondrian API. The idea was to avoid these multi-argument selectors (like in the Seaside API) and have it much more composable and uniform. Not sure what happened with that?
Lukas
On 19 June 2011 14:37, Tudor Girba tudor@tudorgirba.com wrote:
On 19 Jun 2011, at 14:33, jannik.laval wrote:
> > On Jun 19, 2011, at 14:21 , Tudor Girba wrote: > >> Hi, >> >>> Thank you for the explanation. >> >> My pleasure :). But now, let's see if we can make it better. There are two actions that seem to come out of the discussion: >> - do a pass over the comments to better reveal that the input collections are always entities (both behind nodes and behind edges) >> - reorganize the protocols of ViewRenderer to reveal better the structure of the API >> >> The other thing would be the debugging capabilities. >> >> Who would want to work on these? :) > > I will do :) > I will begin to work on Moose, on tuesday. > I want also to work on DSM.
Great!
Keep us posted. I will open another thread about DSM.
Doru
> Jannik > >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every successful trip needs a suitable vehicle." >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We are all great at making mistakes."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Live like you mean it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jun 19, 2011, at 6:19 PM, Lukas Renggli wrote:
For what it is worth: While I was in Chile last year Alexandre, Johan and I designed and (I think) partly implemented an alternative Mondrian API. The idea was to avoid these multi-argument selectors (like in the Seaside API) and have it much more composable and uniform. Not sure what happened with that?
I would love to see it.
Lukas
On 19 June 2011 14:37, Tudor Girba tudor@tudorgirba.com wrote:
On 19 Jun 2011, at 14:33, jannik.laval wrote:
On Jun 19, 2011, at 14:21 , Tudor Girba wrote:
Hi,
Thank you for the explanation.
My pleasure :). But now, let's see if we can make it better. There are two actions that seem to come out of the discussion:
- do a pass over the comments to better reveal that the input collections are always entities (both behind nodes and behind edges)
- reorganize the protocols of ViewRenderer to reveal better the structure of the API
The other thing would be the debugging capabilities.
Who would want to work on these? :)
I will do :) I will begin to work on Moose, on tuesday. I want also to work on DSM.
Great!
Keep us posted. I will open another thread about DSM.
Doru
Jannik
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We are all great at making mistakes."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Better late reply than never reply: Alex and I did not continue with this due to time constraints. Too much things that need to be done ''now'' to be able to make time for long-term stuff :-( I would like to continue with that. Maybe we could all sit down at a table at ESUG and talk this through?
On 19 Jun 2011, at 12:19, Lukas Renggli wrote:
For what it is worth: While I was in Chile last year Alexandre, Johan and I designed and (I think) partly implemented an alternative Mondrian API. The idea was to avoid these multi-argument selectors (like in the Seaside API) and have it much more composable and uniform. Not sure what happened with that?
Lukas
On 19 June 2011 14:37, Tudor Girba tudor@tudorgirba.com wrote:
On 19 Jun 2011, at 14:33, jannik.laval wrote:
On Jun 19, 2011, at 14:21 , Tudor Girba wrote:
Hi,
Thank you for the explanation.
My pleasure :). But now, let's see if we can make it better. There are two actions that seem to come out of the discussion:
- do a pass over the comments to better reveal that the input collections are always entities (both behind nodes and behind edges)
- reorganize the protocols of ViewRenderer to reveal better the structure of the API
The other thing would be the debugging capabilities.
Who would want to work on these? :)
I will do :) I will begin to work on Moose, on tuesday. I want also to work on DSM.
Great!
Keep us posted. I will open another thread about DSM.
Doru
Jannik
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We are all great at making mistakes."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
How can I make the edge not from the package but the class inside the originating package?
view interaction whenEnteringUpdateNode: [:node | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: node classes. view gridLayout gapSize: 2. view edges: {node} from: #yourself toAll: #sureReferencingClasses ]
whenLeavingUpdateNode: [:node | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: node classes. view gridLayout gapSize: 2 ] withLayoutUpdate: true. view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view interaction whenEnteringUpdateNode: [:node | view edges: {node} from: #yourself toAll: #sureReferencingClasses ]. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexandre
On 15 Jun 2011, at 14:54, Stéphane Ducasse wrote:
How can I make the edge not from the package but the class inside the originating package?
view interaction whenEnteringUpdateNode: [:node | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: node classes. view gridLayout gapSize: 2. view edges: {node} from: #yourself toAll: #sureReferencingClasses ]
whenLeavingUpdateNode: [:node | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: node classes. view gridLayout gapSize: 2 ] withLayoutUpdate: true. view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Ok that way :)
this is cool that package and classes can understand the same message :)
On Jun 15, 2011, at 4:59 PM, Alexandre Bergel wrote:
view nodes: model allPackages forEach: [:pack | view shape rectangle fillColor: Color orange; height: 7; width: 7. view interaction whenEnteringUpdateNode: [:node | view edges: {node} from: #yourself toAll: #sureReferencingClasses ]. view nodes: pack classes. view gridLayout gapSize: 2. ].
view gridLayout.
-
Alexandre Bergel -
jannik.laval -
Johan Fabry -
Lukas Renggli -
Nicolas Anquetil -
Stéphane Ducasse -
Tudor Girba