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 :)

> 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

>
> 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

>
> 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 <[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
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
> _______________________________________________
> 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