Mondrian question
Locked
123
123
 
|
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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Some battles are better lost than fought." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Doru,
Thank you for the explanation. On Jun 19, 2011, at 10:32 , Tudor Girba wrote:
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".
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.
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 :)
Yes, we should do that.
Cool :)))
Thank you for your explanations, again :) Jannik
_______________________________________________ Moose-dev mailing list [hidden email] 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." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] 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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "We are all great at making mistakes." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]> 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 >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list [hidden email] 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 <[hidden email]> 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 >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "We are all great at making mistakes." >> >> >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Live like you mean it." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Lukas Renggli
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 <[hidden email]> 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 >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "We are all great at making mistakes." >> >> >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 > [hidden email] > 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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: 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 > _______________________________________________ > Moose-dev mailing list > [hidden email] > 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
>> 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 >> [hidden email] >> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
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 <[hidden email]> 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 >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "We are all great at making mistakes." >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Live like you mean it." > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
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: 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 > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] 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: 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 >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> 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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Obvious things are difficult to teach." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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" <[hidden email]> > À: "Moose-related development" <[hidden email]> > 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: 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 > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> [hidden email] > >>> 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 > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by abergel
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 >>> [hidden email] >>> 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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by abergel
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 <[hidden email]> 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 >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "We are all great at making mistakes." >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Live like you mean it." >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |