8 Dec
2015
8 Dec
'15
3:10 a.m.
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script:
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
=> 0:00:00:10.386
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTOptimizedForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the
traditional layout.
The problem is that translating a composite shape is much slower than translating a
non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8 Dec
8 Dec
3:20 p.m.
Cool that you found such a radical speedup. :-) But now the question is: how do I know if
I have the same problem? Is this only for RTMondrian? How do I fix it if I have it?
On Dec 7, 2015, at 23:10, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script:
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
=> 0:00:00:10.386
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTOptimizedForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the
traditional layout.
The problem is that translating a composite shape is much slower than translating a
non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
9:59 p.m.
Cool that you found such a radical speedup. :-) But
now the question is: how do I know if I have the same problem? Is this only for
RTMondrian? How do I fix it if I have it?
I think the problem is only with the force base layout, because this it is an iterative
layout made of small incremental step. And doing a translation of an element with a
composed shape then this is costly.
I think that only the force base layout had this problem.
The layout builder uses it now, so this is not related to Mondrian.
Alexandre
On Dec 7, 2015, at 23:10, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script:
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
=> 0:00:00:10.386
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTOptimizedForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the
traditional layout.
The problem is that translating a composite shape is much slower than translating a
non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
4:15 p.m.
Hi,
Cool. Is there a downside of using the Optimized version as the default version?
Cheers,
Doru
On Dec 7, 2015, at 9:10 PM, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script:
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
=> 0:00:00:10.386
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTOptimizedForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the
traditional layout.
The problem is that translating a composite shape is much slower than translating a
non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
9:58 p.m.
Cool. Is there a downside of using the Optimized
version as the default version?
No downside as far as I can see.
Alexandre
Cheers,
Doru
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Dec 7, 2015, at 9:10 PM, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script:
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
=> 0:00:00:10.386
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTOptimizedForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the
traditional layout.
The problem is that translating a composite shape is much slower than translating a
non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
10:02 p.m.
Then we should just replace the existing one, right?
Doru
On Dec 8, 2015, at 3:57 PM, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
Cool. Is there a downside of using the Optimized
version as the default version?
No downside as far as I can see.
Alexandre
Cheers,
Doru
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On Dec 7, 2015, at 9:10 PM, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script:
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
=> 0:00:00:10.386
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTOptimizedForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the
traditional layout.
The problem is that translating a composite shape is much slower than translating a
non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
10:21 p.m.
Yes
Alexandre
On Dec 8, 2015, at 6:02 PM, Tudor Girba
<tudor(a)tudorgirba.com> wrote:
Then we should just replace the existing one, right?
Doru
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Dec 8, 2015, at 3:57 PM, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Cool. Is there a downside of using the Optimized
version as the default version?
No downside as far as I can see.
Alexandre
Cheers,
Doru
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On Dec 7, 2015, at 9:10 PM, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script:
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
=> 0:00:00:10.386
[ b := RTMondrian new.
b shape box size: 30; color: Color red trans; withText.
b nodes: (1 to: 20).
b edges connectFrom: [ :v | v // 3 ].
b build.
RTOptimizedForceBasedLayout new
"doNotUseProgressBar;"
on: b view elements.
b view] timeToRun
0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the
traditional layout.
The problem is that translating a composite shape is much slower than translating a
non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
10:05 p.m.
Le 08/12/2015 21:57, Alexandre Bergel a écrit :
So why create a new class instead of updating the existing one?
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
Cool. Is there
a downside of using the Optimized version as the default version?
No downside as far as I can see.
Alexandre
10:24 p.m.
So why create a new class instead of updating the
existing one?
Because I have not tested it enough. Moreover, I feel this may impact the continuous
layout one may have.
Inspect the following expression:
RTGeneralExample new forceBasedLayout
The optimized layout may not be efficient here.
Alexandre
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
10:42 p.m.
Le 08/12/2015 22:24, Alexandre Bergel a écrit :
IMO this is why we have stable/development version for a project. If we
decide that it is stable nobody have to change it and during the
development phase everyone can test it/improve it without problem using
the development version of Roassal.
But this is just my opinion :)
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
So why create
a new class instead of updating the existing one?
Because I have not tested it enough. Moreover, I feel this may impact the continuous
layout one may have.
Inspect the following expression:
RTGeneralExample new forceBasedLayout
The optimized layout may not be efficient here.
Alexandre
11:29 p.m.
Well… If something care about creating a stable and development version. Then sure, why
not…
Alexandre
On Dec 8, 2015, at 6:42 PM, Ferlicot D. Cyril
<cyril.ferlicot(a)gmail.com> wrote:
Le 08/12/2015 22:24, Alexandre Bergel a écrit :
IMO this is why we have stable/development version for a project. If we
decide that it is stable nobody have to change it and during the
development phase everyone can test it/improve it without problem using
the development version of Roassal.
But this is just my opinion :)
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
So why
create a new class instead of updating the existing one?
Because I have not tested it enough. Moreover, I feel this may impact the continuous
layout one may have.
Inspect the following expression:
RTGeneralExample new forceBasedLayout
The optimized layout may not be efficient here.
Alexandre
9 Dec
9 Dec
12:35 a.m.
Are you going to maintain 2 versions of a force based layout? My guess is that the answer
to that is no. I would replace the old one with the optimized version.
On Dec 8, 2015, at 19:29, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
Well… If something care about creating a stable and development version. Then sure, why
not…
Alexandre
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Dec 8, 2015, at 6:42 PM, Ferlicot D. Cyril
<cyril.ferlicot(a)gmail.com> wrote:
Le 08/12/2015 22:24, Alexandre Bergel a écrit :
IMO this is why we have stable/development version for a project. If we
decide that it is stable nobody have to change it and during the
development phase everyone can test it/improve it without problem using
the development version of Roassal.
But this is just my opinion :)
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
So why
create a new class instead of updating the existing one?
Because I have not tested it enough. Moreover, I feel this may impact the continuous
layout one may have.
Inspect the following expression:
RTGeneralExample new forceBasedLayout
The optimized layout may not be efficient here.
Alexandre
10:01 a.m.
You still have a #stable and #development versions in
ConfigurationOfRoassal2 (created by Chris Andrei) :)
In my opinion you should really optimize #encompassingRectangle in
TRCompositeShape and use relative position for sub elements. In addition a
cache would be great for this.
2015-12-09 0:35 GMT+01:00 Johan Fabry <jfabry(a)dcc.uchile.cl>cl>:
Are you going to maintain 2 versions of a force based layout? My guess is
that the answer to that is no. I would replace the old one with the
optimized version.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University
of Chile
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
*Guillaume Larcheveque*
On Dec 8, 2015, at 19:29, Alexandre Bergel
<alexandre.bergel(a)me.com>
wrote:
Well… If something care about creating a stable and development version.
Then
sure, why not…
Alexandre
> On Dec 8, 2015, at 6:42 PM, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com>
wrote:
>
> Le 08/12/2015 22:24, Alexandre Bergel a écrit :
>>> So why create a new class instead of updating the existing one?
>>
>> Because I have not tested it enough. Moreover, I feel this may impact
the
continuous layout one may have.
Inspect the following expression:
RTGeneralExample new forceBasedLayout
The optimized layout may not be efficient here.
Alexandre
IMO this is why we have stable/development version for a project. If we
decide that it is stable nobody have to change it and during the
development phase everyone can test it/improve it without problem using
the development version of Roassal.
But this is just my opinion :)
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
10:23 a.m.
On 12/09, Guillaume Larcheveque wrote:
You still have a #stable and #development versions in
ConfigurationOfRoassal2 (created by Chris Andrei) :)
In my opinion you should really optimize #encompassingRectangle in
TRCompositeShape and use relative position for sub elements. In addition a
cache would be great for this.
I don't know what are the improvements in the optimized layout,
but is there a reason why you are physically (in canvas) moving the
elements during the iterations?
Wouldn't it be faster to have a dual representation of the shapes in the
quad tree and move the real shapes only at the very end?
That way you could compute the #encompassingRectangle rectangle once for
all shapes (labels are also very slow) and work in the layout just with
Rectangles.
2015-12-09 0:35 GMT+01:00 Johan Fabry <jfabry(a)dcc.uchile.cl>cl>:
Are you going to maintain 2 versions of a force based layout? My guess is
that the answer to that is no. I would replace the old one with the
optimized version.
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University
of Chile
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
*Guillaume Larcheveque* On Dec 8, 2015, at 19:29, Alexandre Bergel
<alexandre.bergel(a)me.com>
wrote:
Well… If something care about creating a stable and development version.
Then
sure, why not…
Alexandre
> On Dec 8, 2015, at 6:42 PM, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com>
wrote:
>
> Le 08/12/2015 22:24, Alexandre Bergel a écrit :
>>> So why create a new class instead of updating the existing one?
>>
>> Because I have not tested it enough. Moreover, I feel this may impact
the
continuous layout one may have.
>
> Inspect the following expression:
> RTGeneralExample new forceBasedLayout
>
> The optimized layout may not be efficient here.
>
> Alexandre
>
>
IMO this is why we have stable/development version for a project. If we
decide that it is stable nobody have to change it and during the
development phase everyone can test it/improve it without problem using
the development version of Roassal.
But this is just my opinion :)
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Peter
3301
days inactive
3302
days old
13 comments
6 participants
participants (6)
-
Alexandre Bergel -
Ferlicot D. Cyril -
Guillaume Larcheveque -
Johan Fabry -
Peter Uhnak -
Tudor Girba