29 Jun
2016
29 Jun
'16
12:24 a.m.
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
29 Jun
29 Jun
6:21 a.m.
No, it does not. After the release of Moose that should be any time now we'll switch.
Stephan
Verstuurd vanaf mijn iPad
Op 29 jun. 2016 om 00:24 heeft Alexandre Bergel
<alexandre.bergel(a)me.com> het volgende geschreven:
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
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
6:55 a.m.
Hi,
We are still working on Pharo 5 because we need to release.
Cheers,
Doru
On Jun 29, 2016, at 12:24 AM, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
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
www.feenk.com
"Beauty is where we see it."
8 Jul
8 Jul
12:13 p.m.
But why Moose should be using an alpha version of Pharo?
Some people need stable versions of Moose, so moving to Pharo 60 is the
best way to make them fork.
I do not know what ussman thinks about that, but I do not think that it
is wise to ship Pharo60 to synectique clients
so if this is the case I will advise them to fork everything to be able
to use Pharo 50.
Now people should not complain after that it is difficult to make people
share what there are doing.
Stef
Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
Alexandre
12:45 p.m.
Currently Synectique uses pharo 3 or 4 and we plan to pass to pharo 5
soon :-)
nicolas
On 08/07/2016 12:13, stepharo wrote:
But why Moose should be using an alpha version of
Pharo?
Some people need stable versions of Moose, so moving to Pharo 60 is
the best way to make them fork.
I do not know what ussman thinks about that, but I do not think that
it is wise to ship Pharo60 to synectique clients
so if this is the case I will advise them to fork everything to be
able to use Pharo 50.
Now people should not complain after that it is difficult to make
people share what there are doing.
Stef
Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
--
Nicolas Anquetil
RMod team -- Inria Lille
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
1:05 p.m.
I think that there is a misunderstanding because it's like saying that someone should
fork Pharo 5 because development moved to Pharo 6.
Soon moose 6 will be released on Pharo 5, so Synectique can move to it and run the stable
version.
Considering the resources that we have I think that it makes sense to have Alpha version
of Moose on the Alpha version of Pharo.
Uko
Sent from my iPhone
On 08 Jul 2016, at 12:13, stepharo
<stepharo(a)free.fr> wrote:
But why Moose should be using an alpha version of Pharo?
Some people need stable versions of Moose, so moving to Pharo 60 is the best way to make
them fork.
I do not know what ussman thinks about that, but I do not think that it is wise to ship
Pharo60 to synectique clients
so if this is the case I will advise them to fork everything to be able to use Pharo 50.
Now people should not complain after that it is difficult to make people share what there
are doing.
Stef
Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
18 Jul
18 Jul
10:47 p.m.
No it does not. Pharo 60 is alpha. Moose does not have to use an alpha
version of Pharo.
Soon we will restart to work on Moose for real and I do not want to work
on alpha version of Pharo.
Stef
Le 8/7/16 à 13:05, Yuriy Tymchuk a écrit :
I think that there is a misunderstanding because
it's like saying that someone should fork Pharo 5 because development moved to Pharo
6.
Soon moose 6 will be released on Pharo 5, so Synectique can move to it and run the stable
version.
Considering the resources that we have I think that it makes sense to have Alpha version
of Moose on the Alpha version of Pharo.
Uko
Sent from my iPhone
On 08 Jul 2016, at 12:13, stepharo
<stepharo(a)free.fr> wrote:
But why Moose should be using an alpha version of Pharo?
Some people need stable versions of Moose, so moving to Pharo 60 is the best way to make
them fork.
I do not know what ussman thinks about that, but I do not think that it is wise to ship
Pharo60 to synectique clients
so if this is the case I will advise them to fork everything to be able to use Pharo 50.
Now people should not complain after that it is difficult to make people share what there
are doing.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
19 Jul
19 Jul
12:09 a.m.
On 18/07/16 22:47, stepharo wrote:
No it does not. Pharo 60 is alpha. Moose does not have
to use an alpha
version of Pharo.
That's a choice with advantages and disadvantages. Seaside
moves more slowly
and is used in production systems. That's why it runs on stable releases
of Pharo
and is sometimes not up to date with alpha's. You're saying Moose is
used by
Synectique in production so needs more stability?
A lot of the visualisation and gui work depends on parts that are
supposed to be changing in
Pharo 6, so we need a way to both move ahead and keep production systems
stable.
In Seaside we have several versions available at the same time. That
could work for
Moose too, and that has consequences for dependency maintenance. It is
just more work,
and someone has to do that work.
Stephan
8:19 a.m.
You see synectique alredy forked because they work with a version of
Pharo 3 or 4. Do not expect people to really contribute in such case.
Since they also built their own FAMIX there is no problem. I will see if
we work with their branches.
Stef
Le 19/7/16 à 00:09, Stephan Eggermont a écrit :
On 18/07/16 22:47, stepharo wrote:
No it does not. Pharo 60 is alpha. Moose does not
have to use an
alpha version of Pharo.
That's a choice with advantages and disadvantages.
Seaside moves more
slowly
and is used in production systems. That's why it runs on stable
releases of Pharo
and is sometimes not up to date with alpha's. You're saying Moose is
used by
Synectique in production so needs more stability?
A lot of the visualisation and gui work depends on parts that are
supposed to be changing in
Pharo 6, so we need a way to both move ahead and keep production
systems stable.
In Seaside we have several versions available at the same time. That
could work for
Moose too, and that has consequences for dependency maintenance. It is
just more work,
and someone has to do that work.
Stephan
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
9:32 a.m.
Hi,
Eventually, all systems needs more stability (even Pharo).
Nobody can run a business with a rabbit running away constantly.
Esteban
ps: I think Seaside guys have done a very good job with maintainability and releasing of
products, we should take them as a model to build stable products.
On 19 Jul 2016, at 00:09, Stephan Eggermont
<stephan(a)stack.nl> wrote:
On 18/07/16 22:47, stepharo wrote:
No it does not. Pharo 60 is alpha. Moose does not
have to use an alpha version of Pharo.
That's a choice with advantages and
disadvantages. Seaside moves more slowly
and is used in production systems. That's why it runs on stable releases of Pharo
and is sometimes not up to date with alpha's. You're saying Moose is used by
Synectique in production so needs more stability?
A lot of the visualisation and gui work depends on parts that are supposed to be changing
in
Pharo 6, so we need a way to both move ahead and keep production systems stable.
In Seaside we have several versions available at the same time. That could work for
Moose too, and that has consequences for dependency maintenance. It is just more work,
and someone has to do that work.
Stephan
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
11:46 a.m.
Hi,
If we look at the details of Moose we will see that we have very few modifications in the
core components such as Core, Famix, Fame, Glamour, PetitParser. These are highly stable
since years. For example, the proof for that is that I can perfectly load models, parsers
and custom browsers that are more than 5 years old.
Where there is volatility is at the level of Roassal and GT. For the GTInspector, the
public API is stable since about 3 years, and for GTSpotter since 1 year. Roassal also
appears to have reached a stable state since about 1 year at the level of commonly used
builders.
At least from a macroscopic view, things are not so bad, actually. But, perhaps there are
problems in the details. We can address them if they are announced publicly. Let’s find
them and fix them.
Cheers,
Doru
On Jul 19, 2016, at 1:32 AM, Esteban Lorenzano
<estebanlm(a)gmail.com> wrote:
Hi,
Eventually, all systems needs more stability (even Pharo).
Nobody can run a business with a rabbit running away constantly.
Esteban
ps: I think Seaside guys have done a very good job with maintainability and releasing of
products, we should take them as a model to build stable products.
--
www.tudorgirba.com
www.feenk.com
"Be rather willing to give than demanding to get."
On 19 Jul 2016, at 00:09, Stephan Eggermont
<stephan(a)stack.nl> wrote:
On 18/07/16 22:47, stepharo wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev No it does not. Pharo 60 is alpha. Moose does not
have to use an alpha version of Pharo.
That's a choice with advantages and
disadvantages. Seaside moves more slowly
and is used in production systems. That's why it runs on stable releases of Pharo
and is sometimes not up to date with alpha's. You're saying Moose is used by
Synectique in production so needs more stability?
A lot of the visualisation and gui work depends on parts that are supposed to be changing
in
Pharo 6, so we need a way to both move ahead and keep production systems stable.
In Seaside we have several versions available at the same time. That could work for
Moose too, and that has consequences for dependency maintenance. It is just more work,
and someone has to do that work.
Stephan
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
12:50 a.m.
Now that I've read it, it makes sense what you are saying, but I also think that it
would be nice if everyone would explain his point of view so we can discuss and find
consensus.
I'm not using Moose at the moment, but here is why I said that having development
version of moose on the development version of Pharo is good:
Imagine that Pharo X is released with Bloc and there is super cool Roassal 3 that works on
Bloc. If Moose is following Pharo, then soon after that stable Moose Y is released with
cool version of Roassal 3. On the other hand if Moose is working only on stable version of
Pharo, then to get cool Roassal 3 on a stable Moose version you have to wait for longer.
Please note that libraries and frameworks used in my description can be anything, it was
just to make the point.
Stephan's example with Seaside is good. There is also more complexity because it runs
on multiple platforms, but for me it is always painful to load Seaside. I want to use
Pharo 5 because it has QA, but the stable version of Seaside still uses some deprecated
methods and has some classes missing. It works, but each time I load it I get warnings and
it is frustrated.
Cheers.
Uko
Sent from my iPad
On 18 Jul 2016, at 22:47, stepharo
<stepharo(a)free.fr> wrote:
No it does not. Pharo 60 is alpha. Moose does not have to use an alpha version of Pharo.
Soon we will restart to work on Moose for real and I do not want to work on alpha version
of Pharo.
Stef
Le 8/7/16 à 13:05, Yuriy Tymchuk a écrit :
I think that there is a misunderstanding because it's like saying that someone should
fork Pharo 5 because development moved to Pharo 6.
Soon moose 6 will be released on Pharo 5, so Synectique can move to it and run the stable
version.
Considering the resources that we have I think that it makes sense to have Alpha version
of Moose on the Alpha version of Pharo.
Uko
Sent from my iPhone
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On 08 Jul 2016, at 12:13, stepharo
<stepharo(a)free.fr> wrote:
But why Moose should be using an alpha version of Pharo?
Some people need stable versions of Moose, so moving to Pharo 60 is the best way to make
them fork.
I do not know what ussman thinks about that, but I do not think that it is wise to ship
Pharo60 to synectique clients
so if this is the case I will advise them to fork everything to be able to use Pharo 50.
Now people should not complain after that it is difficult to make people share what there
are doing.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
8 Jul
8 Jul
1:20 p.m.
Currently, moose provides two possibilities: stable for pharo release and
development for pharo alpha. We have builds for both on the jenkins.
On Fri, Jul 8, 2016 at 12:13 PM, stepharo <stepharo(a)free.fr> wrote:
But why Moose should be using an alpha version of
Pharo?
Some people need stable versions of Moose, so moving to Pharo 60 is the
best way to make them fork.
I do not know what ussman thinks about that, but I do not think that it is
wise to ship Pharo60 to synectique clients
so if this is the case I will advise them to fork everything to be able to
use Pharo 50.
Now people should not complain after that it is difficult to make people
share what there are doing.
Stef
Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
9 Jul
9 Jul
11:56 p.m.
Hi,
We will release Moose soon. The main open issue is the often crashing Roassal, and as
there was some new input recently, I decided to wait a bit for the release.
So, Moose 6.0 release will be on top of Pharo 5.0. After that, the development version of
Moose will move to Pharo 6.0.
Cheers,
Doru
On Jul 8, 2016, at 1:20 PM, Usman Bhatti
<usman.bhatti(a)gmail.com> wrote:
Currently, moose provides two possibilities: stable for pharo release and development for
pharo alpha. We have builds for both on the jenkins.
On Fri, Jul 8, 2016 at 12:13 PM, stepharo <stepharo(a)free.fr> wrote:
But why Moose should be using an alpha version of Pharo?
Some people need stable versions of Moose, so moving to Pharo 60 is the best way to make
them fork.
I do not know what ussman thinks about that, but I do not think that it is wise to ship
Pharo60 to synectique clients
so if this is the case I will advise them to fork everything to be able to use Pharo 50.
Now people should not complain after that it is difficult to make people share what there
are doing.
Stef
Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
Alexandre
_______________________________________________
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
--
www.tudorgirba.com
www.feenk.com
"Every thing has its own flow."
18 Jul
18 Jul
10:55 p.m.
Ok doru. I see that there are no real discussion possible. Sadly Moose
became more and more an ui experimentation platform
versus an analysis platform (this is long time ago that I did not see
new analyses beside MooseChef).
Late 2016, we will have an engineer to work on the core of Moose (meta
model and more) and I will have to think what we will do because
I do not think that I'm really welcomed in the Moose system anymore.
Each time I sent a mail I feel like an idiot telling something wrong.
It is ok and it is probably time for me to step back from Moose and
build something else with less strings attached.
Too bad I thought that Moose was to make sure that people can sell
product around it.
Stef
Hi,
We will release Moose soon. The main open issue is the often crashing Roassal, and as
there was some new input recently, I decided to wait a bit for the release.
So, Moose 6.0 release will be on top of Pharo 5.0. After that, the development version of
Moose will move to Pharo 6.0.
Cheers,
Doru
On Jul 8, 2016, at 1:20 PM, Usman Bhatti
<usman.bhatti(a)gmail.com> wrote:
Currently, moose provides two possibilities: stable for pharo release and development for
pharo alpha. We have builds for both on the jenkins.
On Fri, Jul 8, 2016 at 12:13 PM, stepharo <stepharo(a)free.fr> wrote:
But why Moose should be using an alpha version of Pharo?
Some people need stable versions of Moose, so moving to Pharo 60 is the best way to make
them fork.
I do not know what ussman thinks about that, but I do not think that it is wise to ship
Pharo60 to synectique clients
so if this is the case I will advise them to fork everything to be able to use Pharo 50.
Now people should not complain after that it is difficult to make people share what there
are doing.
Stef
Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
Alexandre
_______________________________________________
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
--
www.tudorgirba.com
www.feenk.com
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
19 Jul
19 Jul
1:32 a.m.
Hi Stef,
I am sorry you feel this way. I did not expedite you, only we had exactly these
conversations before.
Like now, the issue was that if we work on the last version of Pharo the code will be
unstable and we will get problems. It turns out that we did not. Where are the signs you
see this as being problematic?
In fact the problem is the opposite. Right now, Moose is unstable because we do not have
the infrastructure and man power to develop in Pharo 5 and 6 at the same time, and we get
conflicting changes especially given that GT are central to both Pharo and Moose. We had
the same issue last year. So, right now we are in consolidation, but afterwards, we have
to move on.
As for selling, if I understand correctly, Synectique builds on the version of Moose that
is stable (5.1), which was released about 1 year ago. Now, it is one year later and we
should release again.
I really do not see the problem.
Cheers,
Doru
On Jul 18, 2016, at 3:55 PM, stepharo
<stepharo(a)free.fr> wrote:
Ok doru. I see that there are no real discussion possible. Sadly Moose became more and
more an ui experimentation platform
versus an analysis platform (this is long time ago that I did not see new analyses beside
MooseChef).
Late 2016, we will have an engineer to work on the core of Moose (meta model and more)
and I will have to think what we will do because
I do not think that I'm really welcomed in the Moose system anymore. Each time I sent
a mail I feel like an idiot telling something wrong.
It is ok and it is probably time for me to step back from Moose and build something else
with less strings attached.
Too bad I thought that Moose was to make sure that people can sell product around it.
Stef
--
www.tudorgirba.com
www.feenk.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
Hi,
We will release Moose soon. The main open issue is the often crashing Roassal, and as
there was some new input recently, I decided to wait a bit for the release.
So, Moose 6.0 release will be on top of Pharo 5.0. After that, the development version of
Moose will move to Pharo 6.0.
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On Jul 8, 2016, at 1:20 PM, Usman Bhatti
<usman.bhatti(a)gmail.com> wrote:
Currently, moose provides two possibilities: stable for pharo release and development for
pharo alpha. We have builds for both on the jenkins.
On Fri, Jul 8, 2016 at 12:13 PM, stepharo <stepharo(a)free.fr> wrote:
But why Moose should be using an alpha version of Pharo?
Some people need stable versions of Moose, so moving to Pharo 60 is the best way to make
them fork.
I do not know what ussman thinks about that, but I do not think that it is wise to ship
Pharo60 to synectique clients
so if this is the case I will advise them to fork everything to be able to use Pharo 50.
Now people should not complain after that it is difficult to make people share what there
are doing.
Stef
Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
Alexandre
_______________________________________________
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
--
www.tudorgirba.com
www.feenk.com
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
8:30 a.m.
Le 19/7/16 à 01:32, Tudor Girba a écrit :
Hi Stef,
I am sorry you feel this way. I did not expedite you, only we had exactly these
conversations before.
You see when I sent a not funny and cool mail this is not for
fun and I
monitor myself. When the counter is getting
too high then it means that I should change because there is a mismatch
between me and others.
It can come from me or from others the result is the same: change.
Like now, the issue was that if we work on the last
version of Pharo the code will be unstable and we will get problems. It turns out that we
did not. Where are the signs you see this as being problematic?
Do you think that we
can ship a product with a VM that has hiccups?
Or that does not collect enough garbage?
In addition Synectique does not use any of the User Interface of Moose
(not GT at all - because clients found the interface not sexy and
because they also want light clients).
Net result:
- no roassal because it has no decent graph algo (so no advantage
over Javascript code)
- no GT
- Pharo as a server.
I'm not sure that there is something to learn from this but this is the
reality.
The sad part is that I'm not sure that even if we ask privately we will
get the real reasons because there is not need to hurt people.
In fact the problem is the opposite. Right now, Moose
is unstable because we do not have the infrastructure and man power to develop in Pharo 5
and 6 at the same time, and we get conflicting changes especially given that GT are
central to both Pharo and Moose. We had the same issue last year. So, right now we are in
consolidation, but afterwards, we have to move on.
As for selling, if I understand correctly, Synectique builds on the version of Moose that
is stable (5.1), which was released about 1 year ago. Now, it is one year later and we
should release again.
I really do not see the problem.
I would not sell products based on an alpha
version of Pharo because
people in alpha should have the freedom to break things
and take time to fix them. Now if other people do not care about such
aspects what can I say.
We will work on fame replacement and more deep things so we will see if
we can get a consensus inside moose
else it will be outside. We will try and if it does not work we will
work on our own core.
Stef
Cheers,
Doru
On Jul 18, 2016, at 3:55 PM, stepharo
<stepharo(a)free.fr> wrote:
Ok doru. I see that there are no real discussion possible. Sadly Moose became more and
more an ui experimentation platform
versus an analysis platform (this is long time ago that I did not see new analyses beside
MooseChef).
Late 2016, we will have an engineer to work on the core of Moose (meta model and more)
and I will have to think what we will do because
I do not think that I'm really welcomed in the Moose system anymore. Each time I sent
a mail I feel like an idiot telling something wrong.
It is ok and it is probably time for me to step back from Moose and build something else
with less strings attached.
Too bad I thought that Moose was to make sure that people can sell product around it.
Stef
--
www.tudorgirba.com
www.feenk.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Hi,
We will release Moose soon. The main open issue is the often crashing Roassal, and as
there was some new input recently, I decided to wait a bit for the release.
So, Moose 6.0 release will be on top of Pharo 5.0. After that, the development version of
Moose will move to Pharo 6.0.
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On Jul 8, 2016, at 1:20 PM, Usman Bhatti
<usman.bhatti(a)gmail.com> wrote:
Currently, moose provides two possibilities: stable for pharo release and development for
pharo alpha. We have builds for both on the jenkins.
On Fri, Jul 8, 2016 at 12:13 PM, stepharo <stepharo(a)free.fr> wrote:
But why Moose should be using an alpha version of Pharo?
Some people need stable versions of Moose, so moving to Pharo 60 is the best way to make
them fork.
I do not know what ussman thinks about that, but I do not think that it is wise to ship
Pharo60 to synectique clients
so if this is the case I will advise them to fork everything to be able to use Pharo 50.
Now people should not complain after that it is difficult to make people share what there
are doing.
Stef
Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
Hi!
Does the moose build uses Pharo 6? It does not look like…
How to make Moose loads in Pharo 6?
Alexandre
_______________________________________________
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
--
www.tudorgirba.com
www.feenk.com
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
11:38 a.m.
Hi,
I think we are talking about two different things.
The GT interface is not for people that want to click, but for people that want to
program. Not the same audience, and I would certainly not use it for products dedicated to
people that do not want to program. We need a better infrastructure for end-user products,
and what we have now is not enough. I think that is not a Moose problem, but a Pharo one,
and it can only change with Bloc/Brick.
Also, we are talking about the development version of Moose, not the stable one. The
development version is not meant to be stable (even if it turns out to be stable enough).
For the Moose 5.1/Pharo 4 version, we had a couple of patches that happen after the
release, and they got integrated in the respective configurations. I think that shows that
we can do that if we really need to.
About a Famix fork: could it be that you are referring to extensions to Famix that are
specific to the languages that you are parsing, and not for the common parts? If not, I
would love to hear where the issues are and how we can correct them, because I did not see
public issues that were not integrated in quite some time.
In any case, I am happy that you are interested in investing in the modeling parts (Fame
and Famix). For example, it would be great to have traits deeply used. I would be happy to
work with people in any direction. Just make it public and let’s solve real problems.
Cheers,
Doru
On Jul 19, 2016, at 12:30 AM, stepharo
<stepharo(a)free.fr> wrote:
Le 19/7/16 à 01:32, Tudor Girba a écrit :
--
www.tudorgirba.com
www.feenk.com
"Things happen when they happen,
not when you talk about them happening."
Hi Stef,
I am sorry you feel this way. I did not expedite you, only we had exactly these
conversations before.
You see when I sent a not funny and cool mail this is not for
fun and I monitor myself. When the counter is getting
too high then it means that I should change because there is a mismatch between me and
others.
It can come from me or from others the result is the same: change.
Like now, the issue was that if we work on the
last version of Pharo the code will be unstable and we will get problems. It turns out
that we did not. Where are the signs you see this as being problematic?
Do you
think that we can ship a product with a VM that has hiccups?
Or that does not collect enough garbage?
In addition Synectique does not use any of the User Interface of Moose (not GT at all -
because clients found the interface not sexy and because they also want light clients).
Net result:
- no roassal because it has no decent graph algo (so no advantage over Javascript
code)
- no GT
- Pharo as a server.
I'm not sure that there is something to learn from this but this is the reality.
The sad part is that I'm not sure that even if we ask privately we will get the real
reasons because there is not need to hurt people.
In fact the problem is the opposite. Right now,
Moose is unstable because we do not have the infrastructure and man power to develop in
Pharo 5 and 6 at the same time, and we get conflicting changes especially given that GT
are central to both Pharo and Moose. We had the same issue last year. So, right now we are
in consolidation, but afterwards, we have to move on.
As for selling, if I understand correctly, Synectique builds on the version of Moose that
is stable (5.1), which was released about 1 year ago. Now, it is one year later and we
should release again.
I really do not see the problem.
I would not sell products based on an alpha
version of Pharo because people in alpha should have the freedom to break things
and take time to fix them. Now if other people do not care about such aspects what can I
say.
We will work on fame replacement and more deep things so we will see if we can get a
consensus inside moose
else it will be outside. We will try and if it does not work we will work on our own
core.
Stef
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On Jul 18, 2016, at 3:55 PM, stepharo
<stepharo(a)free.fr> wrote:
Ok doru. I see that there are no real discussion possible. Sadly Moose became more and
more an ui experimentation platform
versus an analysis platform (this is long time ago that I did not see new analyses beside
MooseChef).
Late 2016, we will have an engineer to work on the core of Moose (meta model and more)
and I will have to think what we will do because
I do not think that I'm really welcomed in the Moose system anymore. Each time I sent
a mail I feel like an idiot telling something wrong.
It is ok and it is probably time for me to step back from Moose and build something else
with less strings attached.
Too bad I thought that Moose was to make sure that people can sell product around it.
Stef
--
www.tudorgirba.com
www.feenk.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Hi,
We will release Moose soon. The main open issue is the often crashing Roassal, and as
there was some new input recently, I decided to wait a bit for the release.
So, Moose 6.0 release will be on top of Pharo 5.0. After that, the development version of
Moose will move to Pharo 6.0.
Cheers,
Doru
> On Jul 8, 2016, at 1:20 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
>
> Currently, moose provides two possibilities: stable for pharo release and development
for pharo alpha. We have builds for both on the jenkins.
>
> On Fri, Jul 8, 2016 at 12:13 PM, stepharo <stepharo(a)free.fr> wrote:
> But why Moose should be using an alpha version of Pharo?
>
> Some people need stable versions of Moose, so moving to Pharo 60 is the best way to
make them fork.
>
> I do not know what ussman thinks about that, but I do not think that it is wise to
ship Pharo60 to synectique clients
>
> so if this is the case I will advise them to fork everything to be able to use Pharo
50.
>
> Now people should not complain after that it is difficult to make people share what
there are doing.
>
> Stef
>
>
> Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
> Hi!
>
> Does the moose build uses Pharo 6? It does not look like…
> How to make Moose loads in Pharo 6?
>
> Alexandre
>
> _______________________________________________
> 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
--
www.tudorgirba.com
www.feenk.com
"Every thing has its own flow."
_______________________________________________
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
1:52 p.m.
Le 19/7/16 à 11:38, Tudor Girba a écrit :
Hi,
I think we are talking about two different things.
The GT interface is not for people that want to click, but for people that want to
program. Not the same audience, and I would certainly not use it for products dedicated to
people that do not want to program. We need a better infrastructure for end-user products,
and what we have now is not enough. I think that is not a Moose problem, but a Pharo one,
and it can only change with Bloc/Brick.
Also, we are talking about the development version of Moose, not the stable one. The
development version is not meant to be stable (even if it turns out to be stable enough).
For the Moose 5.1/Pharo 4 version, we had a couple of patches that happen after the
release, and they got integrated in the respective configurations. I think that shows that
we can do that if we really need to.
About a Famix fork: could it be that you are referring to extensions to Famix that are
specific to the languages that you are parsing, and not for the common parts? If not, I
would love to hear where the issues are and how we can correct them, because I did not see
public issues that were not integrated in quite some time.
In any case, I am happy that you are interested in investing in the modeling parts (Fame
and Famix). For example, it would be great to have traits deeply used. I would be happy to
work with people in any direction. Just make it public and let’s solve real problems.
Ok noted. I was sure you would say that so we will see.
This was discussed some years ago on this mailing-list. Check emails of
nicolas and anne.
We will send a call for job with a description of tasks we want.
In a nutshell and from memory
- easier way to describe metamodels (probably based on platypus)
-- better handling relationships (union....)
- probably revisit the bootstrap of FAME because it is really arcane.
- use of slot for inverse FMmultivalue link
- using traits at the meta meta level
- see how we can integrate better with dynacase toolings
Stef
Cheers,
Doru
On Jul 19, 2016, at 12:30 AM, stepharo
<stepharo(a)free.fr> wrote:
Le 19/7/16 à 01:32, Tudor Girba a écrit :
--
www.tudorgirba.com
www.feenk.com
"Things happen when they happen,
not when you talk about them happening."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Hi Stef,
I am sorry you feel this way. I did not expedite you, only we had exactly these
conversations before.
You see when I sent a not funny and cool mail this is not for
fun and I monitor myself. When the counter is getting
too high then it means that I should change because there is a mismatch between me and
others.
It can come from me or from others the result is the same: change.
Like now, the issue was that if we work on the
last version of Pharo the code will be unstable and we will get problems. It turns out
that we did not. Where are the signs you see this as being problematic?
Do you
think that we can ship a product with a VM that has hiccups?
Or that does not collect enough garbage?
In addition Synectique does not use any of the User Interface of Moose (not GT at all -
because clients found the interface not sexy and because they also want light clients).
Net result:
- no roassal because it has no decent graph algo (so no advantage over Javascript
code)
- no GT
- Pharo as a server.
I'm not sure that there is something to learn from this but this is the reality.
The sad part is that I'm not sure that even if we ask privately we will get the real
reasons because there is not need to hurt people.
In fact the problem is the opposite. Right now,
Moose is unstable because we do not have the infrastructure and man power to develop in
Pharo 5 and 6 at the same time, and we get conflicting changes especially given that GT
are central to both Pharo and Moose. We had the same issue last year. So, right now we are
in consolidation, but afterwards, we have to move on.
As for selling, if I understand correctly, Synectique builds on the version of Moose that
is stable (5.1), which was released about 1 year ago. Now, it is one year later and we
should release again.
I really do not see the problem.
I would not sell products based on an alpha
version of Pharo because people in alpha should have the freedom to break things
and take time to fix them. Now if other people do not care about such aspects what can I
say.
We will work on fame replacement and more deep things so we will see if we can get a
consensus inside moose
else it will be outside. We will try and if it does not work we will work on our own
core.
Stef
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On Jul 18, 2016, at 3:55 PM, stepharo
<stepharo(a)free.fr> wrote:
Ok doru. I see that there are no real discussion possible. Sadly Moose became more and
more an ui experimentation platform
versus an analysis platform (this is long time ago that I did not see new analyses beside
MooseChef).
Late 2016, we will have an engineer to work on the core of Moose (meta model and more)
and I will have to think what we will do because
I do not think that I'm really welcomed in the Moose system anymore. Each time I sent
a mail I feel like an idiot telling something wrong.
It is ok and it is probably time for me to step back from Moose and build something else
with less strings attached.
Too bad I thought that Moose was to make sure that people can sell product around it.
Stef
> Hi,
>
> We will release Moose soon. The main open issue is the often crashing Roassal, and as
there was some new input recently, I decided to wait a bit for the release.
>
> So, Moose 6.0 release will be on top of Pharo 5.0. After that, the development
version of Moose will move to Pharo 6.0.
>
> Cheers,
> Doru
>
>
>> On Jul 8, 2016, at 1:20 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
>>
>> Currently, moose provides two possibilities: stable for pharo release and
development for pharo alpha. We have builds for both on the jenkins.
>>
>> On Fri, Jul 8, 2016 at 12:13 PM, stepharo <stepharo(a)free.fr> wrote:
>> But why Moose should be using an alpha version of Pharo?
>>
>> Some people need stable versions of Moose, so moving to Pharo 60 is the best way
to make them fork.
>>
>> I do not know what ussman thinks about that, but I do not think that it is wise
to ship Pharo60 to synectique clients
>>
>> so if this is the case I will advise them to fork everything to be able to use
Pharo 50.
>>
>> Now people should not complain after that it is difficult to make people share
what there are doing.
>>
>> Stef
>>
>>
>> Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
>> Hi!
>>
>> Does the moose build uses Pharo 6? It does not look like…
>> How to make Moose loads in Pharo 6?
>>
>> Alexandre
>>
>> _______________________________________________
>> 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
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Every thing has its own flow."
>
>
>
>
>
> _______________________________________________
> 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
--
www.tudorgirba.com
www.feenk.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
2:26 p.m.
Hi,
On Jul 19, 2016, at 5:52 AM, stepharo
<stepharo(a)free.fr> wrote:
Le 19/7/16 à 11:38, Tudor Girba a écrit :
Great.
Hi,
I think we are talking about two different things.
The GT interface is not for people that want to click, but for people that want to
program. Not the same audience, and I would certainly not use it for products dedicated to
people that do not want to program. We need a better infrastructure for end-user products,
and what we have now is not enough. I think that is not a Moose problem, but a Pharo one,
and it can only change with Bloc/Brick.
Also, we are talking about the development version of Moose, not the stable one. The
development version is not meant to be stable (even if it turns out to be stable enough).
For the Moose 5.1/Pharo 4 version, we had a couple of patches that happen after the
release, and they got integrated in the respective configurations. I think that shows that
we can do that if we really need to.
About a Famix fork: could it be that you are referring to extensions to Famix that are
specific to the languages that you are parsing, and not for the common parts? If not, I
would love to hear where the issues are and how we can correct them, because I did not see
public issues that were not integrated in quite some time.
In any case, I am happy that you are interested in investing in the modeling parts (Fame
and Famix). For example, it would be great to have traits deeply used. I would be happy to
work with people in any direction. Just make it public and let’s solve real problems.
Ok noted. I was sure you would say that so we will see.
This was discussed some years ago on this mailing-list. Check emails of nicolas and
anne.
We will send a call for job with a description of tasks we want. In a nutshell and from memory
- easier way to describe metamodels (probably based on platypus)
I think it is an interesting goal. I just want to keep as a goal the simplest mapping to
the Pharo code, too. Certainly, a separate DSL would be an interesting direction, but
another route here would be to have a better tool integration that allows us to map
meta-annotations to the code.
-- better handling relationships (union….)
Interesting. Do you have more details?
- probably revisit the bootstrap of FAME because it
is really arcane.
- use of slot for inverse FMmultivalue link
Yes.
- using traits at the meta meta level
Yes. And in Famix.
- see how we can integrate better with dynacase
toolings
Interesting. Could you detail that use case?
Cheers,
Doru
Stef
--
www.tudorgirba.com
www.feenk.com
"To utilize feedback, you first have to acquire it."
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On Jul 19, 2016, at 12:30 AM, stepharo
<stepharo(a)free.fr> wrote:
Le 19/7/16 à 01:32, Tudor Girba a écrit :
--
www.tudorgirba.com
www.feenk.com
"Things happen when they happen,
not when you talk about them happening."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Hi Stef,
I am sorry you feel this way. I did not expedite you, only we had exactly these
conversations before.
You see when I sent a not funny and cool mail this is not for
fun and I monitor myself. When the counter is getting
too high then it means that I should change because there is a mismatch between me and
others.
It can come from me or from others the result is the same: change.
Like now, the issue was that if we work on the
last version of Pharo the code will be unstable and we will get problems. It turns out
that we did not. Where are the signs you see this as being problematic?
Do you
think that we can ship a product with a VM that has hiccups?
Or that does not collect enough garbage?
In addition Synectique does not use any of the User Interface of Moose (not GT at all -
because clients found the interface not sexy and because they also want light clients).
Net result:
- no roassal because it has no decent graph algo (so no advantage over Javascript
code)
- no GT
- Pharo as a server.
I'm not sure that there is something to learn from this but this is the reality.
The sad part is that I'm not sure that even if we ask privately we will get the real
reasons because there is not need to hurt people.
In fact the problem is the opposite. Right now,
Moose is unstable because we do not have the infrastructure and man power to develop in
Pharo 5 and 6 at the same time, and we get conflicting changes especially given that GT
are central to both Pharo and Moose. We had the same issue last year. So, right now we are
in consolidation, but afterwards, we have to move on.
As for selling, if I understand correctly, Synectique builds on the version of Moose that
is stable (5.1), which was released about 1 year ago. Now, it is one year later and we
should release again.
I really do not see the problem.
I would not sell products based on an alpha
version of Pharo because people in alpha should have the freedom to break things
and take time to fix them. Now if other people do not care about such aspects what can I
say.
We will work on fame replacement and more deep things so we will see if we can get a
consensus inside moose
else it will be outside. We will try and if it does not work we will work on our own
core.
Stef
Cheers,
Doru
> On Jul 18, 2016, at 3:55 PM, stepharo <stepharo(a)free.fr> wrote:
>
> Ok doru. I see that there are no real discussion possible. Sadly Moose became more
and more an ui experimentation platform
>
> versus an analysis platform (this is long time ago that I did not see new analyses
beside MooseChef).
>
> Late 2016, we will have an engineer to work on the core of Moose (meta model and
more) and I will have to think what we will do because
>
> I do not think that I'm really welcomed in the Moose system anymore. Each time I
sent a mail I feel like an idiot telling something wrong.
>
> It is ok and it is probably time for me to step back from Moose and build something
else with less strings attached.
>
> Too bad I thought that Moose was to make sure that people can sell product around
it.
>
> Stef
>
>> Hi,
>>
>> We will release Moose soon. The main open issue is the often crashing Roassal,
and as there was some new input recently, I decided to wait a bit for the release.
>>
>> So, Moose 6.0 release will be on top of Pharo 5.0. After that, the development
version of Moose will move to Pharo 6.0.
>>
>> Cheers,
>> Doru
>>
>>
>>> On Jul 8, 2016, at 1:20 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
>>>
>>> Currently, moose provides two possibilities: stable for pharo release and
development for pharo alpha. We have builds for both on the jenkins.
>>>
>>> On Fri, Jul 8, 2016 at 12:13 PM, stepharo <stepharo(a)free.fr> wrote:
>>> But why Moose should be using an alpha version of Pharo?
>>>
>>> Some people need stable versions of Moose, so moving to Pharo 60 is the best
way to make them fork.
>>>
>>> I do not know what ussman thinks about that, but I do not think that it is
wise to ship Pharo60 to synectique clients
>>>
>>> so if this is the case I will advise them to fork everything to be able to
use Pharo 50.
>>>
>>> Now people should not complain after that it is difficult to make people
share what there are doing.
>>>
>>> Stef
>>>
>>>
>>> Le 29/6/16 à 00:24, Alexandre Bergel a écrit :
>>> Hi!
>>>
>>> Does the moose build uses Pharo 6? It does not look like…
>>> How to make Moose loads in Pharo 6?
>>>
>>> Alexandre
>>>
>>> _______________________________________________
>>> 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
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Every thing has its own flow."
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
--
www.tudorgirba.com
www.feenk.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
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 
10:22 p.m.
On Tue, Jul 19, 2016 at 2:26 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
DynaCase is a generic editor : https://dynacase.github.io/
This would be nice if MOOSE and DynaCase are more integrate in the future.
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
On Jul 19, 2016, at 5:52 AM, stepharo
<stepharo(a)free.fr> wrote:
Le 19/7/16 à 11:38, Tudor Girba a écrit :
Great.
Hi,
I think we are talking about two different things.
The GT interface is not for people that want to click, but for people that want to
program. Not the same audience, and I would certainly not use it for products dedicated to
people that do not want to program. We need a better infrastructure for end-user products,
and what we have now is not enough. I think that is not a Moose problem, but a Pharo one,
and it can only change with Bloc/Brick.
Also, we are talking about the development version of Moose, not the stable one. The
development version is not meant to be stable (even if it turns out to be stable enough).
For the Moose 5.1/Pharo 4 version, we had a couple of patches that happen after the
release, and they got integrated in the respective configurations. I think that shows that
we can do that if we really need to.
About a Famix fork: could it be that you are referring to extensions to Famix that are
specific to the languages that you are parsing, and not for the common parts? If not, I
would love to hear where the issues are and how we can correct them, because I did not see
public issues that were not integrated in quite some time.
In any case, I am happy that you are interested in investing in the modeling parts (Fame
and Famix). For example, it would be great to have traits deeply used. I would be happy to
work with people in any direction. Just make it public and let’s solve real problems.
Ok noted. I was sure you would say that so we will see.
This was discussed some years ago on this mailing-list. Check emails of nicolas and
anne.
We will send a call for job with a description of tasks we want. In a nutshell and from memory
- easier way to describe metamodels (probably based on platypus)
I think it is an interesting goal. I just want to keep as a goal the simplest mapping to
the Pharo code, too. Certainly, a separate DSL would be an interesting direction, but
another route here would be to have a better tool integration that allows us to map
meta-annotations to the code.
-- better handling relationships (union….)
Interesting. Do you have more details?
- probably revisit the bootstrap of FAME
because it is really arcane.
- use of slot for inverse FMmultivalue link
Yes.
- using traits at the meta meta level
Yes. And in Famix.
- see how we can integrate better with
dynacase toolings
Interesting. Could you detail that use case? 
6:58 p.m.
On Tue, Jul 19, 2016 at 7:52 PM, stepharo <stepharo(a)free.fr> wrote:
(a little off-topic but a minor business opportunity...)
If you are updating the metamodel, would you consider making the OMG Model
Driven Architecture (MDA) [1] compatibility loading from XMI files a first
class citizen.
To put this in perspective for just one industry...
Historically when electricity markets were provisioned by single government
owned entities, each network could be managed with unique and monolithic
software systems. In comparison, the trend today to deregulate electricity
markets requires a growing number of independent market participants to
interact, which in turn requires *standardisation* of the *system model*.
The U.S. Energy Independence and Security Act of 2007 (EISA) put the
National Institute of Standards and Technology (NIST) in charge of
coordinating development of protocols and *model standards* to achieve
interoperability of Smart Grid devices and systems. The U.S. Secretary
of Commerce and Secretary of Energy met with executives from Smart Grid
industries to commit to supporting NIST in this endeavour with a $3.4
billion in government grants and $4.7 billion from private companies. NIST
ran public workshops encompassing 1,500 individual Smart Grid stakeholders
to produce a document [2] defining sixteen Priority Action Plans of which
three encompassed the IEC 61970 Common Information Model (IEC-CIM) (refer
Table 2-2 [3]).
The market for Smart Grid-related hardware, software, and services was
forecast in 2009 to be $43 billion for the U.S. in 2014 and $171 billion
globally. There *has*** to be a market for helping energy utilities to
understand and convert their legacy software to the new interoperable
Standards, and to track the history of model revisions for which Moose
might be an appropriate tool. For example, [7] indicates about $140M in
research funding that at least touches IEC 61970.
Enterprise Architect is being quite smart about it - getting in bed with
standards organisations utilising MDA to produce industry information
models [4]. Thus *everyone* that wants to interoperate with anyone else in
these domains needs to use the International Standard, and EA is there
ready to help by providing a free viewer. Indeed the IEC-CIM is maintained
as a UML model [5] using EA, and the dozen IEC 61970 standards documents
are *generated from the model*. (btw buying the dozen or so IEC 61970
Standards Documents probably costs a few grand [5], but the CIM model is
free to download (see attached screen snapshot) for universities after
signing up to the CIM User Group [6])
** Except where I live the opportunities are not so great having one small
3GW grid with 4 main generation operators versus the European 1023GW grid
with 41 generation operators interconnected over 35 countries.
[1] http://www.omg.org/mda/
[2]
http://www.nist.gov/public_affairs/releases/upload/smartgrid_interoperabili…
[3]
http://files.openinworld.com/LEKtrek/BenjaminTerrenceCOMAN-LEKtrek-2013-08-…
[4] http://www.sparxsystems.com.au/partners/standards.html
[5] https://webstore.iec.ch/searchform&q=iec%2061970
[6] http://www.ucaiug.org/Pages/join.aspx
[7]
http://www.gridplus.eu/Documents/20130228_EEGI%20Roadmap%202013-2022_to%20p…
cheers -ben
Le 19/7/16 à 11:38, Tudor Girba a écrit :
>
> Hi,
>
> I think we are talking about two different things.
>
> The GT interface is not for people that want to click, but for people
that
> want to program. Not the same audience, and I
would certainly not use it
for
> products dedicated to people that do not want to
program. We need a
better
> infrastructure for end-user products, and what we
have now is not
enough. I
> think that is not a Moose problem, but a Pharo
one, and it can only
change
> with Bloc/Brick.
>
> Also, we are talking about the development version of Moose, not the
> stable one. The development version is not meant to be stable (even if it
> turns out to be stable enough). For the Moose 5.1/Pharo 4 version, we
had a
> couple of patches that happen after the release,
and they got integrated
in
> the respective configurations. I think that shows
that we can do that if
we
> really need to.
>
> About a Famix fork: could it be that you are referring to extensions to
> Famix that are specific to the languages that you are parsing, and not
for
> the common parts? If not, I would love to hear
where the issues are and
how
> we can correct them, because I did not see public
issues that were not
> integrated in quite some time.
>
> In any case, I am happy that you are interested in investing in the
> modeling parts (Fame and Famix). For example, it would be great to have
> traits deeply used. I would be happy to work with people in any
direction.
Just make it
public and let’s solve real problems.
Ok noted. I was sure you would say that so we will see.
This was discussed some years ago on this mailing-list. Check emails of
nicolas and anne.
We will send a call for job with a description of tasks we want.
In a nutshell and from memory
- easier way to describe metamodels (probably based on platypus)
-- better handling relationships (union....)
- probably revisit the bootstrap of FAME because it is really arcane.
- use of slot for inverse FMmultivalue link
- using traits at the meta meta level
- see how we can integrate better with dynacase toolings 
20 Jul
20 Jul
1:29 a.m.
Hi,
since I saw many times "Synectique" on the conversation I would like to
make the comments about my experience of Moose at Synectique.
For the stable and alpha version of Moose I don't think there is a
problem to get the moose stable on the Pharo stable and the Moose dev on
the Pharo dev.
It's true that sometimes we need some features that are not in the
stable but in the dev. For this I think that making Moose a sort of
meta-project grouping some little project would make easy to load a
specific version of what we need. For example we could use Moose stable
and load small dude dev after. But making branch as in Moose51 with
Monticello is a really bad idea. I will come back on this point later.
A bad point about Moose is that it make configurations really really
really hard. I spend days to fight with configurations. In Pharo 4 there
was bugs with the configurations and the configurations of Moose were
really hard to deal with.
A part of the problem comes from the branch to backport some features.
They messed up *a lot* with the configurations. This should not be
redone with Monticello. NEVER! We never end with the right commits, when
the configuration load. I can't count anymore the number of "The version
XXX was not found. Possible versions: #stable, #development,
#bleedingEdge, 1.0, 2.0, XXX, …".
Another problem is that there is 2 ConfigurationOfGlamourCore (or
Glamour? I don't remember) in two repositories… This cause a lot of bug
because they are not the same and they can't co-exist in the same image.
I got many errors because the wrong one was in the image and Metacello
could not find the right version.
The problem is increased when you add the fact that a lot of projects
have bad dependencies and load everything, glamour is in a *lot* of
configurations. I saw pure model project that loaded GlamourCore,
Glamour, Roassal, Merlin during the loading because everything depend on
everything.
This is the reason why we had a "fork" of Moose. And our configurations
depending on Moose51 are full of "spec postLoadDoIt: #hackScript" that
remove and reload some packages because we lost too many time on
configurations.
When we moved on the web we begun to build our tools in an image with
Moose and our old tools. This month I cut made the configurations to
load our web tools without the old UI. It worked at the first try!
Usually I spend days to get a working configuration.
This problem can be lessen with better defined dependencies (For example
on Moose group Core we get Roassal and Glamour… But if I only want the
model? Why am I forced to get the UI?). Not using branches in Monticello
anymore (*please*). Having *one* configuration in one repository for
each projects.
This was improved in Moose 6 with the ConfigurationOfFamix. This is a
first step but there is still dependencies problem. For example the
famix tests cannot be in the famix configuration because they depend on
Moose.
For the branches problem, moving to git when the tools will be ready can
improve that.
Another problem was that the metamodel is not practical to build good
tools. We have to hack a lot in Famix to build our tools. But everyone
know that and you already talked about hiring someone to work on this.
Since Synectique already gave his point of view on this I will not talk
more about this point.
About moving on the web, our major concerns was:
- To not have the configurations problem anymore
- To have good looking interfaces
- To build interfaces fast
- To get profit from all the good and stable JS libraries
- To deploy easily (It's fastest to deploy an headless server that
blocking everything as halo, debugger, spotter, etc in an image and to
install it on every computers)
In 1 week we can create a Tool that is good to look and easy to use when
we cannot do it in Pharo. Glamour is "smalltalk oriented", this is not
what we need for customers that are not smalltalkers.
For this point I think that Pharo will have improvements with Bloc/Brick
and Spec. But we cannot wait and we cannot contribute because we are 2
full time developers and 2 part time developers. We cannot make the
tools, fill the contracts AND make huge contributions to Pharo/Moose.
I try to make some small contributions on my free time but at Synectique
we don't have the time or the company will not survive. Moving to the
web speed up a lot our work and be get a better result. Much more
stability, more performent, easy to build, fast to build, easy to map JS
library…
I don't want to hurt anyone and I know that everyone work hard. I shared
my feeling for you to get the vision of someone using Moose in
production tools.
I hope that this can help you. There is a lot of work everywhere. For
example Moose with configurations, Famix and the model, UI frameworks
with the look and stability, Pharo with git and deployment. I hope that
I will see everything improve little by little. :)
I am sure that most problems will be resolved with time, if we choose to
not use anymore some things it's just because we don't have this time
and we don't have the man power to clean/improve everything.
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
7:12 a.m.
Hi Cyril,
Thanks a lot for the detailed email.
Please do not apologize because there is really nothing to apologize for. Moose is an open
project that welcomes any amount of effort and nobody should feel bad because the effort
did not meet whatever standard.
It’s better to look at the issue from a more positive perspective and describe the problem
as you face it (like you did here). Emails like these are the prerequisite for being able
to address your points at all.
If I understand correctly, an important problem is to be able to reuse parts
independently. We can address that one, so let’s work on this and finalize
ConfigurationOfFamix. What do you say?
Cheers,
Doru
On Jul 19, 2016, at 5:29 PM, Cyril Ferlicot D.
<cyril.ferlicot(a)gmail.com> wrote:
Hi,
since I saw many times "Synectique" on the conversation I would like to
make the comments about my experience of Moose at Synectique.
For the stable and alpha version of Moose I don't think there is a
problem to get the moose stable on the Pharo stable and the Moose dev on
the Pharo dev.
It's true that sometimes we need some features that are not in the
stable but in the dev. For this I think that making Moose a sort of
meta-project grouping some little project would make easy to load a
specific version of what we need. For example we could use Moose stable
and load small dude dev after. But making branch as in Moose51 with
Monticello is a really bad idea. I will come back on this point later.
A bad point about Moose is that it make configurations really really
really hard. I spend days to fight with configurations. In Pharo 4 there
was bugs with the configurations and the configurations of Moose were
really hard to deal with.
A part of the problem comes from the branch to backport some features.
They messed up *a lot* with the configurations. This should not be
redone with Monticello. NEVER! We never end with the right commits, when
the configuration load. I can't count anymore the number of "The version
XXX was not found. Possible versions: #stable, #development,
#bleedingEdge, 1.0, 2.0, XXX, …".
Another problem is that there is 2 ConfigurationOfGlamourCore (or
Glamour? I don't remember) in two repositories… This cause a lot of bug
because they are not the same and they can't co-exist in the same image.
I got many errors because the wrong one was in the image and Metacello
could not find the right version.
The problem is increased when you add the fact that a lot of projects
have bad dependencies and load everything, glamour is in a *lot* of
configurations. I saw pure model project that loaded GlamourCore,
Glamour, Roassal, Merlin during the loading because everything depend on
everything.
This is the reason why we had a "fork" of Moose. And our configurations
depending on Moose51 are full of "spec postLoadDoIt: #hackScript" that
remove and reload some packages because we lost too many time on
configurations.
When we moved on the web we begun to build our tools in an image with
Moose and our old tools. This month I cut made the configurations to
load our web tools without the old UI. It worked at the first try!
Usually I spend days to get a working configuration.
This problem can be lessen with better defined dependencies (For example
on Moose group Core we get Roassal and Glamour… But if I only want the
model? Why am I forced to get the UI?). Not using branches in Monticello
anymore (*please*). Having *one* configuration in one repository for
each projects.
This was improved in Moose 6 with the ConfigurationOfFamix. This is a
first step but there is still dependencies problem. For example the
famix tests cannot be in the famix configuration because they depend on
Moose.
For the branches problem, moving to git when the tools will be ready can
improve that.
Another problem was that the metamodel is not practical to build good
tools. We have to hack a lot in Famix to build our tools. But everyone
know that and you already talked about hiring someone to work on this.
Since Synectique already gave his point of view on this I will not talk
more about this point.
About moving on the web, our major concerns was:
- To not have the configurations problem anymore
- To have good looking interfaces
- To build interfaces fast
- To get profit from all the good and stable JS libraries
- To deploy easily (It's fastest to deploy an headless server that
blocking everything as halo, debugger, spotter, etc in an image and to
install it on every computers)
In 1 week we can create a Tool that is good to look and easy to use when
we cannot do it in Pharo. Glamour is "smalltalk oriented", this is not
what we need for customers that are not smalltalkers.
For this point I think that Pharo will have improvements with Bloc/Brick
and Spec. But we cannot wait and we cannot contribute because we are 2
full time developers and 2 part time developers. We cannot make the
tools, fill the contracts AND make huge contributions to Pharo/Moose.
I try to make some small contributions on my free time but at Synectique
we don't have the time or the company will not survive. Moving to the
web speed up a lot our work and be get a better result. Much more
stability, more performent, easy to build, fast to build, easy to map JS
library…
I don't want to hurt anyone and I know that everyone work hard. I shared
my feeling for you to get the vision of someone using Moose in
production tools.
I hope that this can help you. There is a lot of work everywhere. For
example Moose with configurations, Famix and the model, UI frameworks
with the look and stability, Pharo with git and deployment. I hope that
I will see everything improve little by little. :)
I am sure that most problems will be resolved with time, if we choose to
not use anymore some things it's just because we don't have this time
and we don't have the man power to clean/improve everything.
--
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
--
www.tudorgirba.com
www.feenk.com
"Be rather willing to give than demanding to get."
11:11 p.m.
Le 20/07/2016 à 07:12, Tudor Girba a écrit :
Hi Cyril,
Thanks a lot for the detailed email.
Please do not apologize because there is really nothing to apologize for. Moose is an
open project that welcomes any amount of effort and nobody should feel bad because the
effort did not meet whatever standard.
It’s better to look at the issue from a more positive perspective and describe the
problem as you face it (like you did here). Emails like these are the prerequisite for
being able to address your points at all.
If I understand correctly, an important problem is to be able to reuse parts
independently. We can address that one, so let’s work on this and finalize
ConfigurationOfFamix. What do you say?
Hi,
I think this is important to be able to reuse parts independently if you
want people building tools in top of Moose and if you want Moose to be
used in business.
Moose is big and I think most companies that want to work with Moose
will start to use all Moose to start, but later they will not need
everything. I think it's good to let users takes the part they needs. If
you make your own browsers, you don't need Glamour/Roassal/Merlin. If
you don't care about duplication then you don't have to be forced to get
Dude.
Another use case is: Imagine you don't want to slow you tool during the
generation of a MSE. You can have an image 1 with Moose that will call
an image 2 with the parser. Then the image 2 don't need Moose but only
the parser and FAMIX.
As I said, at Synectique we don't bring all moose anymore but only the
parts we need. And on our Jenkins we can see a lot of "Undeclared"
because everything depend on everything.
It's hard to clean it but if we do it slowly it will not impact Moose
and it will make thing easier for people wanted to work with it. I think
that Moose should be a sort of "Meta configuration" and all the part
could be load independently. We could have a CI job for each build to
check that they do not use undeclared classes/variables anymore. (For
example now, if you want only smalldude, you need Moose-Tests-Core and
Moose tests core depend on half the packages of Moose, at least).
For a platform that promote good modular and good code, this is bad
publicity. :)
I agree that the first step is to get a good ConfigurationOfFame and
ConfigurationOfFamix.
For the ConfigurationOfFamix I think the steps are:
- Clean cyclic dependencies
- Cleans the tests packages of FAMIX that are still in the Moose
configuration since they depend on Moose
- Remove all the problem we see in Jenkins logs:
https://ci.inria.fr/moose/job/Famix/PHARO=60,VERSION=development/21/console
- I also think that Famix should not have the importers directly and we
should have a ConfigurationOfFamixImporters.
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"Be rather willing to give than demanding to get."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
21 Jul
21 Jul
2:38 p.m.
Hi Cyril,
--
www.tudorgirba.com
www.feenk.com
"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."
On Jul 20, 2016, at 3:11 PM, Cyril Ferlicot D.
<cyril.ferlicot(a)gmail.com> wrote:
Le 20/07/2016 à 07:12, Tudor Girba a écrit :
Everyone agrees that we need to create better configurations, and there were multiple
calls for help in the past but until now nobody answered :).
But, I am happy that you want to invest time in this.
Hi Cyril,
Thanks a lot for the detailed email.
Please do not apologize because there is really nothing to apologize for. Moose is an
open project that welcomes any amount of effort and nobody should feel bad because the
effort did not meet whatever standard.
It’s better to look at the issue from a more positive perspective and describe the
problem as you face it (like you did here). Emails like these are the prerequisite for
being able to address your points at all.
If I understand correctly, an important problem is to be able to reuse parts
independently. We can address that one, so let’s work on this and finalize
ConfigurationOfFamix. What do you say?
Hi,
I think this is important to be able to reuse parts independently if you
want people building tools in top of Moose and if you want Moose to be
used in business.
Moose is big and I think most companies that want to work with Moose
will start to use all Moose to start, but later they will not need
everything. I think it's good to let users takes the part they needs. If
you make your own browsers, you don't need Glamour/Roassal/Merlin. If
you don't care about duplication then you don't have to be forced to get
Dude.
Another use case is: Imagine you don't want to slow you tool during the
generation of a MSE. You can have an image 1 with Moose that will call
an image 2 with the parser. Then the image 2 don't need Moose but only
the parser and FAMIX.
As I said, at Synectique we don't bring all moose anymore but only the
parts we need. And on our Jenkins we can see a lot of "Undeclared"
because everything depend on everything.
It's hard to clean it but if we do it slowly it will not impact Moose
and it will make thing easier for people wanted to work with it. I think
that Moose should be a sort of "Meta configuration" and all the part
could be load independently. We could have a CI job for each build to
check that they do not use undeclared classes/variables anymore. (For
example now, if you want only smalldude, you need Moose-Tests-Core and
Moose tests core depend on half the packages of Moose, at least).
For a platform that promote good modular and good code, this is bad
publicity. :)
I agree that the first step is to get a good
ConfigurationOfFame and
ConfigurationOfFamix.
For the ConfigurationOfFamix I think the steps are:
- Clean cyclic dependencies
Yes.
- Cleans the tests packages of FAMIX that are still in
the Moose
configuration since they depend on Moose
I do not understand this part. We should rename the importer and test packages to not have
Moose in the name, but Famix.
- Remove all the problem we see in Jenkins logs:
https://ci.inria.fr/moose/job/Famix/PHARO=60,VERSION=development/21/console
Ok.
- I also think that Famix should not have the
importers directly and we
should have a ConfigurationOfFamixImporters.
Agreed.
Doru
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"Be rather willing to give than demanding to get."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
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
2:43 p.m.
On 21/07/2016 14:38, Tudor Girba wrote:
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
Hi Cyril,
Everyone agrees that we need to create better configurations, and there were multiple
calls for help in the past but until now nobody answered :).
But, I am happy that you want to invest time in this.
Most of the Famix tests are still in the Moose configuration and not in
the Famix one. This is caused by the fact that Famix tests have
dependencies on Moose packages. We cannot launch the tests of Famix
without Moose for now.
This should be cleaned. Some dependencies need to be cut. Some things
that are in Moose's packages need to move on Famix. Maybe some packages
might need to be cut into smaller ones.
I agree that the first step is to get a good
ConfigurationOfFame and
ConfigurationOfFamix.
For the ConfigurationOfFamix I think the steps are:
- Clean cyclic dependencies
Yes.
- Cleans the tests packages of FAMIX that are
still in the Moose
configuration since they depend on Moose
I do not understand this part. We should rename the importer and test packages to not
have Moose in the name, but Famix.
- Remove all the problem we see in Jenkins logs:
https://ci.inria.fr/moose/job/Famix/PHARO=60,VERSION=development/21/console
Ok.
- I also think that Famix should not have the
importers directly and we
should have a ConfigurationOfFamixImporters.
Agreed.
Doru
--
www.tudorgirba.com
www.feenk.com
"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
3:32 p.m.
Hi,
On Jul 21, 2016, at 6:43 AM, Cyril Ferlicot Delbecque
<cyril.ferlicot(a)gmail.com> wrote:
On 21/07/2016 14:38, Tudor Girba wrote:
FAMIX depends on Moose-Core
Importers depend on FAMIX and Moose-Core
So, we will always have a dependency to Moose-Core.
Doru
Hi Cyril,
Everyone agrees that we need to create better configurations, and there were multiple
calls for help in the past but until now nobody answered :).
But, I am happy that you want to invest time in this.
Most of the Famix tests are still in the Moose configuration and not in
the Famix one. This is caused by the fact that Famix tests have
dependencies on Moose packages. We cannot launch the tests of Famix
without Moose for now. I agree that the first step is to get a good
ConfigurationOfFame and
ConfigurationOfFamix.
For the ConfigurationOfFamix I think the steps are:
- Clean cyclic dependencies
Yes.
- Cleans the tests packages of FAMIX that are
still in the Moose
configuration since they depend on Moose
I do not understand this part. We should rename the importer and test packages to not
have Moose in the name, but Famix.
This should be cleaned. Some dependencies need to be
cut. Some things
that are in Moose's packages need to move on Famix. Maybe some packages
might need to be cut into smaller ones.
--
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
--
www.tudorgirba.com
www.feenk.com
"We are all great at making mistakes."
- Remove all the problem we see in Jenkins logs:
https://ci.inria.fr/moose/job/Famix/PHARO=60,VERSION=development/21/console
Ok.
- I also think that Famix should not have the
importers directly and we
should have a ConfigurationOfFamixImporters.
Agreed.
Doru
--
www.tudorgirba.com
www.feenk.com
"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
4:04 p.m.
I think there is a problem calling MooseEntity and everything in the
Moose-Core package as Moose...
Basically, we should rename everything that concern the MetaModel as FAMIX
and so rename Moose-Core in FAMIX-Abstract for example.
Then we should split the actual Moose-Core in different packages such as
FAMIX-Importers...
Maybe we should talk about that at ESUG :-D
2016-07-21 15:32 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
Hi,
Most of the Famix tests are still in the Moose configuration and not in
the Famix one. This is caused by the fact that Famix tests have
dependencies on Moose packages. We cannot launch the tests of Famix
without Moose for now.
FAMIX depends on Moose-Core
Importers depend on FAMIX and Moose-Core
So, we will always have a dependency to Moose-Core.
Doru
--
www.tudorgirba.com
www.feenk.com
"We are all great at making mistakes."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
*Guillaume Larcheveque*
On Jul 21, 2016, at 6:43 AM, Cyril Ferlicot
Delbecque <
cyril.ferlicot(a)gmail.com> wrote:
On 21/07/2016 14:38, Tudor Girba wrote:
> Hi Cyril,
>
>
> Everyone agrees that we need to create better configurations, and there
were
multiple calls for help in the past but until now nobody answered :).
>
> But, I am happy that you want to invest time in this.
>
>
>> I agree that the first step is to get a good ConfigurationOfFame and
>> ConfigurationOfFamix.
>>
>> For the ConfigurationOfFamix I think the steps are:
>> - Clean cyclic dependencies
>
> Yes.
>
>> - Cleans the tests packages of FAMIX that are still in the Moose
>> configuration since they depend on Moose
>
> I do not understand this part. We should rename the importer and test
packages
to not have Moose in the name, but Famix.
This should be cleaned. Some dependencies need to
be cut. Some things
that are in Moose's packages need to move on Famix. Maybe some packages
might need to be cut into smaller ones.
>
>> - Remove all the problem we see in Jenkins logs:
>>
https://ci.inria.fr/moose/job/Famix/PHARO=60,VERSION=development/21/console
Ok.
--
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 - I also think that Famix should not have the
importers directly and we
should have a ConfigurationOfFamixImporters.
Agreed.
Doru
--
www.tudorgirba.com
www.feenk.com
"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
5:28 p.m.
Hi,
As Stéphane announced it, we have an engineer position for two years to modify FAME and
FAMIX to make them more easily adaptable… and to adapt existing tools to this new core. So
perhaps, somethings could be done in parallel, but in the opposite, perhaps, we should not
take too much time to modify the current version since we will rebuild a new one.
Anne
PS: I am writing the position description to send it to the list and audition interested
people in ESUG.
Le 21 juil. 2016 à 16:04, Guillaume Larcheveque
<guillaume.larcheveque(a)gmail.com> a écrit :
I think there is a problem calling MooseEntity and everything in the Moose-Core package
as Moose...
Basically, we should rename everything that concern the MetaModel as FAMIX and so rename
Moose-Core in FAMIX-Abstract for example.
Then we should split the actual Moose-Core in different packages such as
FAMIX-Importers...
Maybe we should talk about that at ESUG :-D
2016-07-21 15:32 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com
<mailto:tudor@tudorgirba.com>>:
Hi,
On Jul 21, 2016, at 6:43 AM, Cyril Ferlicot
Delbecque <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> wrote:
On 21/07/2016 14:38, Tudor Girba wrote:
FAMIX depends on Moose-Core
Importers depend on FAMIX and Moose-Core
So, we will always have a dependency to Moose-Core.
Doru
Hi Cyril,
Everyone agrees that we need to create better configurations, and there were multiple
calls for help in the past but until now nobody answered :).
But, I am happy that you want to invest time in this.
Most of the Famix tests are still in the Moose configuration and not in
the Famix one. This is caused by the fact that Famix tests have
dependencies on Moose packages. We cannot launch the tests of Famix
without Moose for now. I agree that the first step is to get a good
ConfigurationOfFame and
ConfigurationOfFamix.
For the ConfigurationOfFamix I think the steps are:
- Clean cyclic dependencies
Yes.
- Cleans the tests packages of FAMIX that are
still in the Moose
configuration since they depend on Moose
I do not understand this part. We should rename the importer and test packages to not
have Moose in the name, but Famix.
This should be cleaned. Some dependencies need to
be cut. Some things
that are in Moose's packages need to move on Famix. Maybe some packages
might need to be cut into smaller ones.
--
Cyril Ferlicot
http://www.synectique.eu <http://www.synectique.eu/>
165 Avenue Bretagne
Lille 59000 France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
--
www.tudorgirba.com <http://www.tudorgirba.com/>
www.feenk.com <http://www.feenk.com/>
"We are all great at making mistakes."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
--
Guillaume Larcheveque
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev - Remove all the problem we see in Jenkins logs:
https://ci.inria.fr/moose/job/Famix/PHARO=60,VERSION=development/21/console
<https://ci.inria.fr/moose/job/Famix/PHARO=60,VERSION=development/21/console>
Ok.
- I also think that Famix should not have the
importers directly and we
should have a ConfigurationOfFamixImporters.
Agreed.
Doru
--
www.tudorgirba.com <http://www.tudorgirba.com/>
www.feenk.com <http://www.feenk.com/>
"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
5:36 p.m.
On 21/07/2016 17:28, Anne Etien wrote:
Hi,
As Stéphane announced it, we have an engineer position for two years to
modify FAME and FAMIX to make them more easily adaptable… and to adapt
existing tools to this new core. So perhaps, somethings could be done in
parallel, but in the opposite, perhaps, we should not take too much time
to modify the current version since we will rebuild a new one.
Anne
PS: I am writing the position description to send it to the list and
audition interested people in ESUG.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi Anne,
I think that we should not wait to correct this kind of things because
most of the problems are not related to FAMIX but are general problems
of any project. If we have people that are willing to help cutting bad
dependencies and improving the configurations, that will let more time
to the engineer to work on the model itself.
I think it would be good at ESUG to make a sort of roadmap of the things
to do (for example I would like Moose-Core to be cut into
FAMIX-Importers, FAMIX-Presentation, FAMIX-Critics,
FAMIX-AbstractModel…). With that roadmap we could begin to clean and
when the engineer will be here he will know what to do next.
Thanks to RMoD for helping Moose to improve!
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
5:55 p.m.
Hi Cyril,
On Jul 21, 2016, at 9:36 AM, Cyril Ferlicot Delbecque
<cyril.ferlicot(a)gmail.com> wrote:
On 21/07/2016 17:28, Anne Etien wrote:
+1
Hi,
As Stéphane announced it, we have an engineer position for two years to
modify FAME and FAMIX to make them more easily adaptable… and to adapt
existing tools to this new core. So perhaps, somethings could be done in
parallel, but in the opposite, perhaps, we should not take too much time
to modify the current version since we will rebuild a new one.
Anne
PS: I am writing the position description to send it to the list and
audition interested people in ESUG.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi Anne,
I think that we should not wait to correct this kind of things because
most of the problems are not related to FAMIX but are general problems
of any project. If we have people that are willing to help cutting bad
dependencies and improving the configurations, that will let more time
to the engineer to work on the model itself.
I think it would be good at ESUG to make a sort of
roadmap of the things
to do (for example I would like Moose-Core to be cut into
FAMIX-Importers, FAMIX-Presentation, FAMIX-Critics,
FAMIX-AbstractModel…). With that roadmap we could begin to clean and
when the engineer will be here he will know what to do next.
Just to clarify. FAMIX is only one part of Moose that is about modeling code related
information. MooseCore is not about FAMIX, but about any other meta-models. Also, the
importers are about FAMIX, and they should be named like that.
Cheers,
Doru
Thanks to RMoD for helping Moose to improve!
--
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
--
www.tudorgirba.com
www.feenk.com
"To utilize feedback, you first have to acquire it."
3084
days inactive
3107
days old
31 comments
14 participants
participants (14)
-
Alexandre Bergel -
Anne Etien -
Ben Coman -
Cyril Ferlicot D. -
Cyril Ferlicot Delbecque
-
Esteban Lorenzano -
Guillaume Larcheveque -
Nicolas Anquetil -
Serge Stinckwich -
Stephan Eggermont -
stepharo -
Tudor Girba -
Usman Bhatti -
Yuriy Tymchuk