Hi!
Does the moose build uses Pharo 6? It does not look like… How to make Moose loads in Pharo 6?
Alexandre
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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@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@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."
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
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 :
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@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@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.
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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@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.
On 19 Jul 2016, at 00:09, Stephan Eggermont stephan@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
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@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
On 08 Jul 2016, at 12:13, stepharo stepharo@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@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@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@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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
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@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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@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.
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@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@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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
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@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@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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@free.fr wrote:
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@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@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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Things happen when they happen, not when you talk about them happening."
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@free.fr wrote:
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@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@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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Things happen when they happen, not when you talk about them happening."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi,
On Jul 19, 2016, at 5:52 AM, stepharo stepharo@free.fr wrote:
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.
Great.
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
Cheers, Doru
On Jul 19, 2016, at 12:30 AM, stepharo stepharo@free.fr wrote:
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@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@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@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@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Things happen when they happen, not when you talk about them happening."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
On Tue, Jul 19, 2016 at 2:26 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
On Jul 19, 2016, at 5:52 AM, stepharo stepharo@free.fr wrote:
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.
Great.
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?
DynaCase is a generic editor : https://dynacase.github.io/ This would be nice if MOOSE and DynaCase are more integrate in the future.
On Tue, Jul 19, 2016 at 7:52 PM, stepharo stepharo@free.fr wrote:
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
(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_interoperabilit... [3] http://files.openinworld.com/LEKtrek/BenjaminTerrenceCOMAN-LEKtrek-2013-08-2... [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%20pr...
cheers -ben
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.
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@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
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@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."
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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi Cyril,
On Jul 20, 2016, at 3:11 PM, Cyril Ferlicot D. cyril.ferlicot@gmail.com wrote:
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. :)
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.
- 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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
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.
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.
- 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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi,
On Jul 21, 2016, at 6:43 AM, Cyril Ferlicot Delbecque cyril.ferlicot@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.
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
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.
- 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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@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."
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@tudorgirba.com:
Hi,
On Jul 21, 2016, at 6:43 AM, Cyril Ferlicot Delbecque <
cyril.ferlicot@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.
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
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.
- 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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@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."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@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@tudorgirba.com mailto:tudor@tudorgirba.com>: Hi,
On Jul 21, 2016, at 6:43 AM, Cyril Ferlicot Delbecque <cyril.ferlicot@gmail.com mailto:cyril.ferlicot@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.
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
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 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@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
-- Cyril Ferlicot
http://www.synectique.eu http://www.synectique.eu/
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@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!
Hi Cyril,
On Jul 21, 2016, at 9:36 AM, Cyril Ferlicot Delbecque cyril.ferlicot@gmail.com wrote:
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@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.
+1
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
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@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."
-
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