going to 4.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

going to 4.0

Tudor Girba
Hi,

We should release 4.0. There are just a handful of issues left for 4.0:
http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0

Except for 293, the others should be doable pretty fast. Is anyone  
willing to give a hand this week?

Cheers,
Doru


--
www.tudorgirba.com

"We cannot reach the flow of things unless we let go."



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: going to 4.0

Alexandre Bergel
Thanks Doru for tacking the initiative. I sincerelly hope to have more  
time in two months (at the end of the semester).

I addressed 313. But not in a satisfactory way. You suggested to do a  
figure selection on a mooseUp. This would require to redesign the drag  
mechanism since a graph element can be dragged without being selected.  
I also thought about forcing to release the button before doing a  
drag. But this would seriously hamper the usability.

The solution I used in the Version 408 says that no drag of more than  
200 pixels is permitted by a manual mouse drag. I think this is not so  
bad.

Is Issue 328 still around? Can we do better than the fix you propose?  
Today Johan had a very similar idea on how to fix it. To properly fix  
it, the window change notification is required. But is not included in  
Pharo 1.0.

I had a look at 357, but MAFlatVector is a bit mysterious to me.

Cheers,
Alexandre


On 5 Apr 2010, at 19:36, Tudor Girba wrote:

> Hi,
>
> We should release 4.0. There are just a handful of issues left for  
> 4.0:
> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>
> Except for 293, the others should be doable pretty fast. Is anyone  
> willing to give a hand this week?
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
>
> "We cannot reach the flow of things unless we let go."
>
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: going to 4.0

Tudor Girba
Hi Alex,

Thanks for the fixes, but 408 is not good :). I did not want a  
redesign of the Drag and drop. That should remain just the same. I  
just wanted the figure selection to be announced on mouseUp:.

I tried to propose a fix in tg.409 by simply cut-and-paste the figure  
selection announcement if block to mouseUp:. I believe this is a much  
simpler solution without impacting usability.

There are a couple of problems left. Simple views work well. It also  
seems to work in Class Blueprint, but there are problems in the System  
Complexity. I do not understand why, but if the node is not selected,  
I cannot see it moving while dragging, but when it gets selected it  
appears at the destination. If the node is selected first, then there  
is no redraw at all, so you have to do something with the window to  
see that it moved. It works when it is not yet selected because  
selecting it forces a redraw. But why is it not redrawn when the  
coordinates change? And why does it work in the Class Blueprint?

Also, it looks like dragging a nested node without selecting it,  
causes the edges to not move with the node. When the node is selected,  
everything works as expected. I did not spot the root of the problem  
yet, but it should not be critical.

Could you please take a look?

Cheers,
Doru


> Thanks Doru for tacking the initiative. I sincerelly hope to have  
> more time in two months (at the end of the semester).
>
> I addressed 313. But not in a satisfactory way. You suggested to do  
> a figure selection on a mooseUp. This would require to redesign the  
> drag mechanism since a graph element can be dragged without being  
> selected. I also thought about forcing to release the button before  
> doing a drag. But this would seriously hamper the usability.
>
> The solution I used in the Version 408 says that no drag of more  
> than 200 pixels is permitted by a manual mouse drag. I think this is  
> not so bad.
>
> Is Issue 328 still around? Can we do better than the fix you  
> propose? Today Johan had a very similar idea on how to fix it. To  
> properly fix it, the window change notification is required. But is  
> not included in Pharo 1.0.
>
> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>
> Cheers,
> Alexandre
>
>
> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>
>> Hi,
>>
>> We should release 4.0. There are just a handful of issues left for  
>> 4.0:
>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>
>> Except for 293, the others should be doable pretty fast. Is anyone  
>> willing to give a hand this week?
>>
>> Cheers,
>> Doru
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "We cannot reach the flow of things unless we let go."
>>
>>
>>
>> _______________________________________________
>> 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

--
www.tudorgirba.com

"Being happy is a matter of choice."



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: going to 4.0

Alexandre Bergel
> Thanks for the fixes, but 408 is not good :). I did not want a  
> redesign of the Drag and drop. That should remain just the same. I  
> just wanted the figure selection to be announced on mouseUp:.

All the test remains green and I haven't noticed any difference when  
using Mondrian. So that's good.

> There are a couple of problems left. Simple views work well. It also  
> seems to work in Class Blueprint, but there are problems in the  
> System Complexity. I do not understand why, but if the node is not  
> selected, I cannot see it moving while dragging, but when it gets  
> selected it appears at the destination. If the node is selected  
> first, then there is no redraw at all, so you have to do something  
> with the window to see that it moved. It works when it is not yet  
> selected because selecting it forces a redraw. But why is it not  
> redrawn when the coordinates change? And why does it work in the  
> Class Blueprint?
>
> Also, it looks like dragging a nested node without selecting it,  
> causes the edges to not move with the node. When the node is  
> selected, everything works as expected. I did not spot the root of  
> the problem yet, but it should not be critical.

In Version 410, I force a canvas update when a node is dragged and  
drop. This update was done anyway in the method setDefaultHandler. In  
410, drag and drop updates the canvas without emitting an event. This  
should solve what I understood from your problem.

How can you drag a node without selecting it?

Cheers,
Alexandre

>
>
>> Thanks Doru for tacking the initiative. I sincerelly hope to have  
>> more time in two months (at the end of the semester).
>>
>> I addressed 313. But not in a satisfactory way. You suggested to do  
>> a figure selection on a mooseUp. This would require to redesign the  
>> drag mechanism since a graph element can be dragged without being  
>> selected. I also thought about forcing to release the button before  
>> doing a drag. But this would seriously hamper the usability.
>>
>> The solution I used in the Version 408 says that no drag of more  
>> than 200 pixels is permitted by a manual mouse drag. I think this  
>> is not so bad.
>>
>> Is Issue 328 still around? Can we do better than the fix you  
>> propose? Today Johan had a very similar idea on how to fix it. To  
>> properly fix it, the window change notification is required. But is  
>> not included in Pharo 1.0.
>>
>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>
>> Cheers,
>> Alexandre
>>
>>
>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>
>>> Hi,
>>>
>>> We should release 4.0. There are just a handful of issues left for  
>>> 4.0:
>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>
>>> Except for 293, the others should be doable pretty fast. Is anyone  
>>> willing to give a hand this week?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "We cannot reach the flow of things unless we let go."
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> --
> www.tudorgirba.com
>
> "Being happy is a matter of choice."
>
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: going to 4.0

Tudor Girba
Hi,

On 6 Apr 2010, at 15:35, Alexandre Bergel wrote:

>> Thanks for the fixes, but 408 is not good :). I did not want a  
>> redesign of the Drag and drop. That should remain just the same. I  
>> just wanted the figure selection to be announced on mouseUp:.
>
> All the test remains green and I haven't noticed any difference when  
> using Mondrian. So that's good.

Actually not really :), because there were no tests affected by my  
moving the selection in mouseUp:

>> There are a couple of problems left. Simple views work well. It  
>> also seems to work in Class Blueprint, but there are problems in  
>> the System Complexity. I do not understand why, but if the node is  
>> not selected, I cannot see it moving while dragging, but when it  
>> gets selected it appears at the destination. If the node is  
>> selected first, then there is no redraw at all, so you have to do  
>> something with the window to see that it moved. It works when it is  
>> not yet selected because selecting it forces a redraw. But why is  
>> it not redrawn when the coordinates change? And why does it work in  
>> the Class Blueprint?
>>
>> Also, it looks like dragging a nested node without selecting it,  
>> causes the edges to not move with the node. When the node is  
>> selected, everything works as expected. I did not spot the root of  
>> the problem yet, but it should not be critical.
>
> In Version 410, I force a canvas update when a node is dragged and  
> drop. This update was done anyway in the method setDefaultHandler.  
> In 410, drag and drop updates the canvas without emitting an event.  
> This should solve what I understood from your problem.

Hmm, but that should be triggered in translateBy:. The problem seems  
to appear when bounded is true because I now reverted to bound false  
and everything works as expected within Mondrian. Also, when bounded  
is true and you try to drag and drop outside the area some strange  
things happen in System Complexity. For example, try to drag a  
complete hierarchy randomly outside the canvas and see what happens.

However, when embedded in Glamour, there still is an update problem,  
so in the end I left the update window also in draggable. But, I think  
that something is missing on the Glamour side.

> How can you drag a node without selecting it?

Right. So, now I added a condition to only allow dragging after  
selecting the node.

It now looks like it is Ok. Could you double check.

Cheers,
Doru


> Cheers,
> Alexandre
>
>>
>>
>>> Thanks Doru for tacking the initiative. I sincerelly hope to have  
>>> more time in two months (at the end of the semester).
>>>
>>> I addressed 313. But not in a satisfactory way. You suggested to  
>>> do a figure selection on a mooseUp. This would require to redesign  
>>> the drag mechanism since a graph element can be dragged without  
>>> being selected. I also thought about forcing to release the button  
>>> before doing a drag. But this would seriously hamper the usability.
>>>
>>> The solution I used in the Version 408 says that no drag of more  
>>> than 200 pixels is permitted by a manual mouse drag. I think this  
>>> is not so bad.
>>>
>>> Is Issue 328 still around? Can we do better than the fix you  
>>> propose? Today Johan had a very similar idea on how to fix it. To  
>>> properly fix it, the window change notification is required. But  
>>> is not included in Pharo 1.0.
>>>
>>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>
>>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>>
>>>> Hi,
>>>>
>>>> We should release 4.0. There are just a handful of issues left  
>>>> for 4.0:
>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>>
>>>> Except for 293, the others should be doable pretty fast. Is  
>>>> anyone willing to give a hand this week?
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "We cannot reach the flow of things unless we let go."
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> --
>> www.tudorgirba.com
>>
>> "Being happy is a matter of choice."
>>
>>
>>
>> _______________________________________________
>> 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

--
www.tudorgirba.com

"It's not how it is, it is how we see it."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: going to 4.0

Simon Denier-3

I just noticed and added a new issue http://code.google.com/p/moose-technology/issues/detail?id=358
for 4.0, consecutive to a recent fix, considerable slow down for the Moose importer.


Also what needs to be done for the table widget?


On 6 avr. 2010, at 16:36, Tudor Girba wrote:

> Hi,
>
> On 6 Apr 2010, at 15:35, Alexandre Bergel wrote:
>
>>> Thanks for the fixes, but 408 is not good :). I did not want a redesign of the Drag and drop. That should remain just the same. I just wanted the figure selection to be announced on mouseUp:.
>>
>> All the test remains green and I haven't noticed any difference when using Mondrian. So that's good.
>
> Actually not really :), because there were no tests affected by my moving the selection in mouseUp:
>
>>> There are a couple of problems left. Simple views work well. It also seems to work in Class Blueprint, but there are problems in the System Complexity. I do not understand why, but if the node is not selected, I cannot see it moving while dragging, but when it gets selected it appears at the destination. If the node is selected first, then there is no redraw at all, so you have to do something with the window to see that it moved. It works when it is not yet selected because selecting it forces a redraw. But why is it not redrawn when the coordinates change? And why does it work in the Class Blueprint?
>>>
>>> Also, it looks like dragging a nested node without selecting it, causes the edges to not move with the node. When the node is selected, everything works as expected. I did not spot the root of the problem yet, but it should not be critical.
>>
>> In Version 410, I force a canvas update when a node is dragged and drop. This update was done anyway in the method setDefaultHandler. In 410, drag and drop updates the canvas without emitting an event. This should solve what I understood from your problem.
>
> Hmm, but that should be triggered in translateBy:. The problem seems to appear when bounded is true because I now reverted to bound false and everything works as expected within Mondrian. Also, when bounded is true and you try to drag and drop outside the area some strange things happen in System Complexity. For example, try to drag a complete hierarchy randomly outside the canvas and see what happens.
>
> However, when embedded in Glamour, there still is an update problem, so in the end I left the update window also in draggable. But, I think that something is missing on the Glamour side.
>
>> How can you drag a node without selecting it?
>
> Right. So, now I added a condition to only allow dragging after selecting the node.
>
> It now looks like it is Ok. Could you double check.
>
> Cheers,
> Doru
>
>
>> Cheers,
>> Alexandre
>>
>>>
>>>
>>>> Thanks Doru for tacking the initiative. I sincerelly hope to have more time in two months (at the end of the semester).
>>>>
>>>> I addressed 313. But not in a satisfactory way. You suggested to do a figure selection on a mooseUp. This would require to redesign the drag mechanism since a graph element can be dragged without being selected. I also thought about forcing to release the button before doing a drag. But this would seriously hamper the usability.
>>>>
>>>> The solution I used in the Version 408 says that no drag of more than 200 pixels is permitted by a manual mouse drag. I think this is not so bad.
>>>>
>>>> Is Issue 328 still around? Can we do better than the fix you propose? Today Johan had a very similar idea on how to fix it. To properly fix it, the window change notification is required. But is not included in Pharo 1.0.
>>>>
>>>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>
>>>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We should release 4.0. There are just a handful of issues left for 4.0:
>>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>>>
>>>>> Except for 293, the others should be doable pretty fast. Is anyone willing to give a hand this week?
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "We cannot reach the flow of things unless we let go."
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Being happy is a matter of choice."
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> --
> www.tudorgirba.com
>
> "It's not how it is, it is how we see it."
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
 Simon




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: going to 4.0

Tudor Girba
Ahh, my bad. I fixed it:

Name: Famix-Core-tg.109
Author: tg
Time: 6 April 2010, 5:59:26 pm
UUID: 7875d38f-a694-49a6-9762-dc8a94aa5e38
Ancestors: Famix-Core-tg.108

added a script to initialize the parent type. Also removed the lazy  
initialization from the parentType to not cause unneccessary  
performance penalties


Cheers,
Doru



On 6 Apr 2010, at 17:09, Simon Denier wrote:

>
> I just noticed and added a new issue http://code.google.com/p/moose-technology/issues/detail?id=358
> for 4.0, consecutive to a recent fix, considerable slow down for the  
> Moose importer.
>
>
> Also what needs to be done for the table widget?
>
>
> On 6 avr. 2010, at 16:36, Tudor Girba wrote:
>
>> Hi,
>>
>> On 6 Apr 2010, at 15:35, Alexandre Bergel wrote:
>>
>>>> Thanks for the fixes, but 408 is not good :). I did not want a  
>>>> redesign of the Drag and drop. That should remain just the same.  
>>>> I just wanted the figure selection to be announced on mouseUp:.
>>>
>>> All the test remains green and I haven't noticed any difference  
>>> when using Mondrian. So that's good.
>>
>> Actually not really :), because there were no tests affected by my  
>> moving the selection in mouseUp:
>>
>>>> There are a couple of problems left. Simple views work well. It  
>>>> also seems to work in Class Blueprint, but there are problems in  
>>>> the System Complexity. I do not understand why, but if the node  
>>>> is not selected, I cannot see it moving while dragging, but when  
>>>> it gets selected it appears at the destination. If the node is  
>>>> selected first, then there is no redraw at all, so you have to do  
>>>> something with the window to see that it moved. It works when it  
>>>> is not yet selected because selecting it forces a redraw. But why  
>>>> is it not redrawn when the coordinates change? And why does it  
>>>> work in the Class Blueprint?
>>>>
>>>> Also, it looks like dragging a nested node without selecting it,  
>>>> causes the edges to not move with the node. When the node is  
>>>> selected, everything works as expected. I did not spot the root  
>>>> of the problem yet, but it should not be critical.
>>>
>>> In Version 410, I force a canvas update when a node is dragged and  
>>> drop. This update was done anyway in the method setDefaultHandler.  
>>> In 410, drag and drop updates the canvas without emitting an  
>>> event. This should solve what I understood from your problem.
>>
>> Hmm, but that should be triggered in translateBy:. The problem  
>> seems to appear when bounded is true because I now reverted to  
>> bound false and everything works as expected within Mondrian. Also,  
>> when bounded is true and you try to drag and drop outside the area  
>> some strange things happen in System Complexity. For example, try  
>> to drag a complete hierarchy randomly outside the canvas and see  
>> what happens.
>>
>> However, when embedded in Glamour, there still is an update  
>> problem, so in the end I left the update window also in draggable.  
>> But, I think that something is missing on the Glamour side.
>>
>>> How can you drag a node without selecting it?
>>
>> Right. So, now I added a condition to only allow dragging after  
>> selecting the node.
>>
>> It now looks like it is Ok. Could you double check.
>>
>> Cheers,
>> Doru
>>
>>
>>> Cheers,
>>> Alexandre
>>>
>>>>
>>>>
>>>>> Thanks Doru for tacking the initiative. I sincerelly hope to  
>>>>> have more time in two months (at the end of the semester).
>>>>>
>>>>> I addressed 313. But not in a satisfactory way. You suggested to  
>>>>> do a figure selection on a mooseUp. This would require to  
>>>>> redesign the drag mechanism since a graph element can be dragged  
>>>>> without being selected. I also thought about forcing to release  
>>>>> the button before doing a drag. But this would seriously hamper  
>>>>> the usability.
>>>>>
>>>>> The solution I used in the Version 408 says that no drag of more  
>>>>> than 200 pixels is permitted by a manual mouse drag. I think  
>>>>> this is not so bad.
>>>>>
>>>>> Is Issue 328 still around? Can we do better than the fix you  
>>>>> propose? Today Johan had a very similar idea on how to fix it.  
>>>>> To properly fix it, the window change notification is required.  
>>>>> But is not included in Pharo 1.0.
>>>>>
>>>>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>
>>>>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We should release 4.0. There are just a handful of issues left  
>>>>>> for 4.0:
>>>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>>>>
>>>>>> Except for 293, the others should be doable pretty fast. Is  
>>>>>> anyone willing to give a hand this week?
>>>>>>
>>>>>> Cheers,
>>>>>> Doru
>>>>>>
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "We cannot reach the flow of things unless we let go."
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Being happy is a matter of choice."
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> --
>> www.tudorgirba.com
>>
>> "It's not how it is, it is how we see it."
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Speaking louder won't make the point worthier."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: going to 4.0

Stéphane Ducasse
doru what was the problem?

Stef
On Apr 6, 2010, at 6:00 PM, Tudor Girba wrote:

> Ahh, my bad. I fixed it:
>
> Name: Famix-Core-tg.109
> Author: tg
> Time: 6 April 2010, 5:59:26 pm
> UUID: 7875d38f-a694-49a6-9762-dc8a94aa5e38
> Ancestors: Famix-Core-tg.108
>
> added a script to initialize the parent type. Also removed the lazy initialization from the parentType to not cause unneccessary performance penalties
>
>
> Cheers,
> Doru
>
>
>
> On 6 Apr 2010, at 17:09, Simon Denier wrote:
>
>>
>> I just noticed and added a new issue http://code.google.com/p/moose-technology/issues/detail?id=358
>> for 4.0, consecutive to a recent fix, considerable slow down for the Moose importer.
>>
>>
>> Also what needs to be done for the table widget?
>>
>>
>> On 6 avr. 2010, at 16:36, Tudor Girba wrote:
>>
>>> Hi,
>>>
>>> On 6 Apr 2010, at 15:35, Alexandre Bergel wrote:
>>>
>>>>> Thanks for the fixes, but 408 is not good :). I did not want a redesign of the Drag and drop. That should remain just the same. I just wanted the figure selection to be announced on mouseUp:.
>>>>
>>>> All the test remains green and I haven't noticed any difference when using Mondrian. So that's good.
>>>
>>> Actually not really :), because there were no tests affected by my moving the selection in mouseUp:
>>>
>>>>> There are a couple of problems left. Simple views work well. It also seems to work in Class Blueprint, but there are problems in the System Complexity. I do not understand why, but if the node is not selected, I cannot see it moving while dragging, but when it gets selected it appears at the destination. If the node is selected first, then there is no redraw at all, so you have to do something with the window to see that it moved. It works when it is not yet selected because selecting it forces a redraw. But why is it not redrawn when the coordinates change? And why does it work in the Class Blueprint?
>>>>>
>>>>> Also, it looks like dragging a nested node without selecting it, causes the edges to not move with the node. When the node is selected, everything works as expected. I did not spot the root of the problem yet, but it should not be critical.
>>>>
>>>> In Version 410, I force a canvas update when a node is dragged and drop. This update was done anyway in the method setDefaultHandler. In 410, drag and drop updates the canvas without emitting an event. This should solve what I understood from your problem.
>>>
>>> Hmm, but that should be triggered in translateBy:. The problem seems to appear when bounded is true because I now reverted to bound false and everything works as expected within Mondrian. Also, when bounded is true and you try to drag and drop outside the area some strange things happen in System Complexity. For example, try to drag a complete hierarchy randomly outside the canvas and see what happens.
>>>
>>> However, when embedded in Glamour, there still is an update problem, so in the end I left the update window also in draggable. But, I think that something is missing on the Glamour side.
>>>
>>>> How can you drag a node without selecting it?
>>>
>>> Right. So, now I added a condition to only allow dragging after selecting the node.
>>>
>>> It now looks like it is Ok. Could you double check.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>>
>>>>>
>>>>>> Thanks Doru for tacking the initiative. I sincerelly hope to have more time in two months (at the end of the semester).
>>>>>>
>>>>>> I addressed 313. But not in a satisfactory way. You suggested to do a figure selection on a mooseUp. This would require to redesign the drag mechanism since a graph element can be dragged without being selected. I also thought about forcing to release the button before doing a drag. But this would seriously hamper the usability.
>>>>>>
>>>>>> The solution I used in the Version 408 says that no drag of more than 200 pixels is permitted by a manual mouse drag. I think this is not so bad.
>>>>>>
>>>>>> Is Issue 328 still around? Can we do better than the fix you propose? Today Johan had a very similar idea on how to fix it. To properly fix it, the window change notification is required. But is not included in Pharo 1.0.
>>>>>>
>>>>>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>>>>>
>>>>>> Cheers,
>>>>>> Alexandre
>>>>>>
>>>>>>
>>>>>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> We should release 4.0. There are just a handful of issues left for 4.0:
>>>>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>>>>>
>>>>>>> Except for 293, the others should be doable pretty fast. Is anyone willing to give a hand this week?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Doru
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> www.tudorgirba.com
>>>>>>>
>>>>>>> "We cannot reach the flow of things unless we let go."
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "Being happy is a matter of choice."
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "It's not how it is, it is how we see it."
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Speaking louder won't make the point worthier."
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: going to 4.0

Tudor Girba
There was a lazy initialization of the parentType to an unknownClass.  
This was useful when the model was not quite complete.

The problem was that this parentType was also called many times during  
import and slowed down the whole thing significantly. So, now we have  
a script that initializes these:
MooseModel>>ensureClassesAndNamespaces

Cheers,
Doru


On 6 Apr 2010, at 22:55, Stéphane Ducasse wrote:

> doru what was the problem?
>
> Stef
> On Apr 6, 2010, at 6:00 PM, Tudor Girba wrote:
>
>> Ahh, my bad. I fixed it:
>>
>> Name: Famix-Core-tg.109
>> Author: tg
>> Time: 6 April 2010, 5:59:26 pm
>> UUID: 7875d38f-a694-49a6-9762-dc8a94aa5e38
>> Ancestors: Famix-Core-tg.108
>>
>> added a script to initialize the parent type. Also removed the lazy  
>> initialization from the parentType to not cause unneccessary  
>> performance penalties
>>
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On 6 Apr 2010, at 17:09, Simon Denier wrote:
>>
>>>
>>> I just noticed and added a new issue http://code.google.com/p/moose-technology/issues/detail?id=358
>>> for 4.0, consecutive to a recent fix, considerable slow down for  
>>> the Moose importer.
>>>
>>>
>>> Also what needs to be done for the table widget?
>>>
>>>
>>> On 6 avr. 2010, at 16:36, Tudor Girba wrote:
>>>
>>>> Hi,
>>>>
>>>> On 6 Apr 2010, at 15:35, Alexandre Bergel wrote:
>>>>
>>>>>> Thanks for the fixes, but 408 is not good :). I did not want a  
>>>>>> redesign of the Drag and drop. That should remain just the  
>>>>>> same. I just wanted the figure selection to be announced on  
>>>>>> mouseUp:.
>>>>>
>>>>> All the test remains green and I haven't noticed any difference  
>>>>> when using Mondrian. So that's good.
>>>>
>>>> Actually not really :), because there were no tests affected by  
>>>> my moving the selection in mouseUp:
>>>>
>>>>>> There are a couple of problems left. Simple views work well. It  
>>>>>> also seems to work in Class Blueprint, but there are problems  
>>>>>> in the System Complexity. I do not understand why, but if the  
>>>>>> node is not selected, I cannot see it moving while dragging,  
>>>>>> but when it gets selected it appears at the destination. If the  
>>>>>> node is selected first, then there is no redraw at all, so you  
>>>>>> have to do something with the window to see that it moved. It  
>>>>>> works when it is not yet selected because selecting it forces a  
>>>>>> redraw. But why is it not redrawn when the coordinates change?  
>>>>>> And why does it work in the Class Blueprint?
>>>>>>
>>>>>> Also, it looks like dragging a nested node without selecting  
>>>>>> it, causes the edges to not move with the node. When the node  
>>>>>> is selected, everything works as expected. I did not spot the  
>>>>>> root of the problem yet, but it should not be critical.
>>>>>
>>>>> In Version 410, I force a canvas update when a node is dragged  
>>>>> and drop. This update was done anyway in the method  
>>>>> setDefaultHandler. In 410, drag and drop updates the canvas  
>>>>> without emitting an event. This should solve what I understood  
>>>>> from your problem.
>>>>
>>>> Hmm, but that should be triggered in translateBy:. The problem  
>>>> seems to appear when bounded is true because I now reverted to  
>>>> bound false and everything works as expected within Mondrian.  
>>>> Also, when bounded is true and you try to drag and drop outside  
>>>> the area some strange things happen in System Complexity. For  
>>>> example, try to drag a complete hierarchy randomly outside the  
>>>> canvas and see what happens.
>>>>
>>>> However, when embedded in Glamour, there still is an update  
>>>> problem, so in the end I left the update window also in  
>>>> draggable. But, I think that something is missing on the Glamour  
>>>> side.
>>>>
>>>>> How can you drag a node without selecting it?
>>>>
>>>> Right. So, now I added a condition to only allow dragging after  
>>>> selecting the node.
>>>>
>>>> It now looks like it is Ok. Could you double check.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks Doru for tacking the initiative. I sincerelly hope to  
>>>>>>> have more time in two months (at the end of the semester).
>>>>>>>
>>>>>>> I addressed 313. But not in a satisfactory way. You suggested  
>>>>>>> to do a figure selection on a mooseUp. This would require to  
>>>>>>> redesign the drag mechanism since a graph element can be  
>>>>>>> dragged without being selected. I also thought about forcing  
>>>>>>> to release the button before doing a drag. But this would  
>>>>>>> seriously hamper the usability.
>>>>>>>
>>>>>>> The solution I used in the Version 408 says that no drag of  
>>>>>>> more than 200 pixels is permitted by a manual mouse drag. I  
>>>>>>> think this is not so bad.
>>>>>>>
>>>>>>> Is Issue 328 still around? Can we do better than the fix you  
>>>>>>> propose? Today Johan had a very similar idea on how to fix it.  
>>>>>>> To properly fix it, the window change notification is  
>>>>>>> required. But is not included in Pharo 1.0.
>>>>>>>
>>>>>>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Alexandre
>>>>>>>
>>>>>>>
>>>>>>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We should release 4.0. There are just a handful of issues  
>>>>>>>> left for 4.0:
>>>>>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>>>>>>
>>>>>>>> Except for 293, the others should be doable pretty fast. Is  
>>>>>>>> anyone willing to give a hand this week?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Doru
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> www.tudorgirba.com
>>>>>>>>
>>>>>>>> "We cannot reach the flow of things unless we let go."
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "Being happy is a matter of choice."
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "It's not how it is, it is how we see it."
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> Simon
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Speaking louder won't make the point worthier."
>>
>> _______________________________________________
>> 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

"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
Reply | Threaded
Open this post in threaded view
|

Re: going to 4.0

Alexandre Bergel
In reply to this post by Tudor Girba
>> All the test remains green and I haven't noticed any difference  
>> when using Mondrian. So that's good.
>
> Actually not really :), because there were no tests affected by my  
> moving the selection in mouseUp:

I deliberately do not test the interaction with the Morphic framework.
You're right. Ideally some tests should have become yellow by this  
change.

>> In Version 410, I force a canvas update when a node is dragged and  
>> drop. This update was done anyway in the method setDefaultHandler.  
>> In 410, drag and drop updates the canvas without emitting an event.  
>> This should solve what I understood from your problem.
>
> Hmm, but that should be triggered in translateBy:. The problem seems  
> to appear when bounded is true because I now reverted to bound false  
> and everything works as expected within Mondrian. Also, when bounded  
> is true and you try to drag and drop outside the area some strange  
> things happen in System Complexity. For example, try to drag a  
> complete hierarchy randomly outside the canvas and see what happens.
>
> However, when embedded in Glamour, there still is an update problem,  
> so in the end I left the update window also in draggable. But, I  
> think that something is missing on the Glamour side.

Ok, so at the end

>> How can you drag a node without selecting it?
>
> Right. So, now I added a condition to only allow dragging after  
> selecting the node.
>
> It now looks like it is Ok. Could you double check.

I am checking...

Alexandre

>>>
>>>
>>>> Thanks Doru for tacking the initiative. I sincerelly hope to have  
>>>> more time in two months (at the end of the semester).
>>>>
>>>> I addressed 313. But not in a satisfactory way. You suggested to  
>>>> do a figure selection on a mooseUp. This would require to  
>>>> redesign the drag mechanism since a graph element can be dragged  
>>>> without being selected. I also thought about forcing to release  
>>>> the button before doing a drag. But this would seriously hamper  
>>>> the usability.
>>>>
>>>> The solution I used in the Version 408 says that no drag of more  
>>>> than 200 pixels is permitted by a manual mouse drag. I think this  
>>>> is not so bad.
>>>>
>>>> Is Issue 328 still around? Can we do better than the fix you  
>>>> propose? Today Johan had a very similar idea on how to fix it. To  
>>>> properly fix it, the window change notification is required. But  
>>>> is not included in Pharo 1.0.
>>>>
>>>> I had a look at 357, but MAFlatVector is a bit mysterious to me.
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>
>>>> On 5 Apr 2010, at 19:36, Tudor Girba wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We should release 4.0. There are just a handful of issues left  
>>>>> for 4.0:
>>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.0
>>>>>
>>>>> Except for 293, the others should be doable pretty fast. Is  
>>>>> anyone willing to give a hand this week?
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "We cannot reach the flow of things unless we let go."
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Being happy is a matter of choice."
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> --
> www.tudorgirba.com
>
> "It's not how it is, it is how we see 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