Moose on Pharo 5

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

Re: Moose on Pharo 5

Tudor Girba-2
Thanks a lot!

Doru

On Mon, May 18, 2015 at 1:47 AM, Andrei Chis <[hidden email]> wrote:
Hi,

A few more steps towards releasing moose 5.1:

- create version 5.1 for ConfigurationOfMoose
- updated
     ConfigurationOfMooseAlgos 
     ConfigurationOfFame 
     ConfigurationOfRoassal2
     ConfigurationOfMerlin
     ConfigurationOfDeepTraversal

- the jenkins job for moose5.1 now loads #stable
- created a new job that loads moose #development on pharo 5

Still to do:

ConfigurationOfSmallDude seems strange
- check again that all packages in GT-* are up to date
- fix moose5.0 build
   - for some strange reason monticello decides to load Glamour 3.3.0 instead of Glamour 3.0.6 when loading moose #stable in Pharo 3
- there is a strange issue with ConfigurationOfRubric and monticello.


Cheers,
Andrei



On Mon, May 11, 2015 at 10:42 PM, Alexandre Bergel <[hidden email]> wrote:
Hi!

I see a lot of negative comments recently. In any company that produces a sizable software system there is at least one person dedicated to versioning, building, and packaging. 
Unfortunately, the setting used by Moose is still far from optimal. It would be nice to improve this, and this has to be done with a positive energy.

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 11, 2015, at 10:36 AM, Tudor Girba <[hidden email]> wrote:

Hi,

Perhaps something was not clear.

I did not say that everyone should work on the latest Moose. We go through the (painful) trouble of creating stable versions exactly because we want to offer the alternative of depending on something that does not change.

But, if someone wants support this will be provided on the latest Moose because this is where the development activity is. This will happen on the latest Pharo because especially now that GT is adopted in Pharo, the development effort is too close to be practical to support two different branches. Before Moose 5.0 we tried for a while to maintain GT for both Pharo 3 and deal with changes in Pharo 4 and we do not want to go through this again. This might change if the tool support changes.

Now, if someone wants to backport changes to an older Moose version, we can put in place a separate repository that can host those backported changes.

Cheers,
Tudor



On Mon, May 11, 2015 at 4:22 PM, Nicolas Anquetil <[hidden email]> wrote:

Just to explain,

we try to make a living by building on top of Moose
we try to adapt it to the lambda Cobol developper that may not be interested in learning a new syntax

So the simplest change in Moose can sometimes break everything for us.
As Usman explained, we cannot test again each morning every single feature we already implemented for every language we support.

So having a bleeding edge Moose for us is not a solution

nicolas


On 11/05/2015 11:12, Usman Bhatti wrote:
Hi,

In Synectique's case, we had several problems working with Bleeding edge of Moose:

1/ changes to the API
2/ changes that lead to performance problems
3/ when depending on bleeding edge of Pharo always testing the combo Pharo + Moose

The first one is important because one does not want to spend resources adapting to inadvertent changes. And it is easy to handle as one can always depend on a given version number (not a stable because it is moving and may create surprises that are less frequent than the bleeding edge).

Regarding changes that lead to performance issues, someone must test with real cases and evaluate. Depending on the version number works fine here too.

We would not have needed to create our own configuration if we could downgrade PetitParser but apparently, that is not possible and hence the easier solution was to create our own configuration. 

The ConfigurationOfSynectiqueMoose is just an assembly of existing versions of the components in Moose (these versions are published publicly). We just loading by hand:
-> SmallDude because it has a dependency on ConfigurationOfMoose
-> GT-Toolkit and PetitSQL because there were paths leading to PetitParser #development.
 
As for Moose depending on the bleeding edge of Pharo, it is risky business because when demoing or delivering a new version to a client, the red square of death is difficult to justify. With the stable version, we at least know where not to click :p. But one is not testing new combinations (coming from Pharo + Moose) in production.

But if there are alternate solutions in our eco-system that enable the use of bleeding edge in production that shield the users from inadvertent changes, it'll be nice to know.

regards,

Usman






On Thu, May 7, 2015 at 11:03 PM, Tudor Girba <[hidden email]> wrote:
Hi,

Yes, I think we have a different point of view on what Moose is.

I do not expect people to fork, but if they do, I would expect them to do it in a public place and help us maintain the configuration(s). For example, we could have:
- a Moose/Moose51 repository 
- commit packages with new patches for Moose 5.1 only there, and 
- modify the #stable version corresponding configurations to load those new packages.

This is doable. Would that be Ok?

Cheers,
Doru





On Wed, May 6, 2015 at 9:43 PM, stepharo <[hidden email]> wrote:
Just a question.
Do you expect people needing to have stable version to fork and work in their corners?
I do not get why Moose dev should systematically be under the bleeding edge of Pharo.
I probably do not understand what Moose is.

Stef

Le 5/5/15 19:17, Tudor Girba a écrit :
Please do not do this until we release. The reason is that this will generate more commits that will be specific to pharo 5, like the current substring problem in get inspector.

The goal is to release this or next week, and then we move to pharo 5.

Cheers,
Doru

--

"Every thing has its own flow"

On 05 May 2015, at 19:52, Alexandre Bergel <[hidden email]> wrote:

Anyone who has access to the CI can do this?

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 5, 2015, at 8:59 AM, Andrei Chis <[hidden email]> wrote:

Hi Alexandre,

Right now now we're updating configurations and fixing the remaining issues to be able to release moose 5.1
We can in parallel start a build for Pharo 5 but we do not have to much time to invest in it (apart from starting it) until we release.

Cheers,
Andrei

On Tue, May 5, 2015 at 3:52 PM, Alexandre Bergel <[hidden email]> wrote:
Hi!

Is there any plan to move on Pharo 5?
Can someone trigger a build?

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"

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

Re: Moose on Pharo 5

abergel
Yes thanks Andrei!

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 18, 2015, at 6:52 AM, Tudor Girba <[hidden email]> wrote:

Thanks a lot!

Doru

On Mon, May 18, 2015 at 1:47 AM, Andrei Chis <[hidden email]> wrote:
Hi,

A few more steps towards releasing moose 5.1:

- create version 5.1 for ConfigurationOfMoose
- updated
     ConfigurationOfMooseAlgos 
     ConfigurationOfFame 
     ConfigurationOfRoassal2
     ConfigurationOfMerlin
     ConfigurationOfDeepTraversal

- the jenkins job for moose5.1 now loads #stable
- created a new job that loads moose #development on pharo 5

Still to do:

ConfigurationOfSmallDude seems strange
- check again that all packages in GT-* are up to date
- fix moose5.0 build
   - for some strange reason monticello decides to load Glamour 3.3.0 instead of Glamour 3.0.6 when loading moose #stable in Pharo 3
- there is a strange issue with ConfigurationOfRubric and monticello.


Cheers,
Andrei



On Mon, May 11, 2015 at 10:42 PM, Alexandre Bergel <[hidden email]> wrote:
Hi!

I see a lot of negative comments recently. In any company that produces a sizable software system there is at least one person dedicated to versioning, building, and packaging. 
Unfortunately, the setting used by Moose is still far from optimal. It would be nice to improve this, and this has to be done with a positive energy.

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 11, 2015, at 10:36 AM, Tudor Girba <[hidden email]> wrote:

Hi,

Perhaps something was not clear.

I did not say that everyone should work on the latest Moose. We go through the (painful) trouble of creating stable versions exactly because we want to offer the alternative of depending on something that does not change.

But, if someone wants support this will be provided on the latest Moose because this is where the development activity is. This will happen on the latest Pharo because especially now that GT is adopted in Pharo, the development effort is too close to be practical to support two different branches. Before Moose 5.0 we tried for a while to maintain GT for both Pharo 3 and deal with changes in Pharo 4 and we do not want to go through this again. This might change if the tool support changes.

Now, if someone wants to backport changes to an older Moose version, we can put in place a separate repository that can host those backported changes.

Cheers,
Tudor



On Mon, May 11, 2015 at 4:22 PM, Nicolas Anquetil <[hidden email]> wrote:

Just to explain,

we try to make a living by building on top of Moose
we try to adapt it to the lambda Cobol developper that may not be interested in learning a new syntax

So the simplest change in Moose can sometimes break everything for us.
As Usman explained, we cannot test again each morning every single feature we already implemented for every language we support.

So having a bleeding edge Moose for us is not a solution

nicolas


On 11/05/2015 11:12, Usman Bhatti wrote:
Hi,

In Synectique's case, we had several problems working with Bleeding edge of Moose:

1/ changes to the API
2/ changes that lead to performance problems
3/ when depending on bleeding edge of Pharo always testing the combo Pharo + Moose

The first one is important because one does not want to spend resources adapting to inadvertent changes. And it is easy to handle as one can always depend on a given version number (not a stable because it is moving and may create surprises that are less frequent than the bleeding edge).

Regarding changes that lead to performance issues, someone must test with real cases and evaluate. Depending on the version number works fine here too.

We would not have needed to create our own configuration if we could downgrade PetitParser but apparently, that is not possible and hence the easier solution was to create our own configuration. 

The ConfigurationOfSynectiqueMoose is just an assembly of existing versions of the components in Moose (these versions are published publicly). We just loading by hand:
-> SmallDude because it has a dependency on ConfigurationOfMoose
-> GT-Toolkit and PetitSQL because there were paths leading to PetitParser #development.
 
As for Moose depending on the bleeding edge of Pharo, it is risky business because when demoing or delivering a new version to a client, the red square of death is difficult to justify. With the stable version, we at least know where not to click :p. But one is not testing new combinations (coming from Pharo + Moose) in production.

But if there are alternate solutions in our eco-system that enable the use of bleeding edge in production that shield the users from inadvertent changes, it'll be nice to know.

regards,

Usman






On Thu, May 7, 2015 at 11:03 PM, Tudor Girba <[hidden email]> wrote:
Hi,

Yes, I think we have a different point of view on what Moose is.

I do not expect people to fork, but if they do, I would expect them to do it in a public place and help us maintain the configuration(s). For example, we could have:
- a Moose/Moose51 repository 
- commit packages with new patches for Moose 5.1 only there, and 
- modify the #stable version corresponding configurations to load those new packages.

This is doable. Would that be Ok?

Cheers,
Doru





On Wed, May 6, 2015 at 9:43 PM, stepharo <[hidden email]> wrote:
Just a question.
Do you expect people needing to have stable version to fork and work in their corners?
I do not get why Moose dev should systematically be under the bleeding edge of Pharo.
I probably do not understand what Moose is.

Stef

Le 5/5/15 19:17, Tudor Girba a écrit :
Please do not do this until we release. The reason is that this will generate more commits that will be specific to pharo 5, like the current substring problem in get inspector.

The goal is to release this or next week, and then we move to pharo 5.

Cheers,
Doru

--

"Every thing has its own flow"

On 05 May 2015, at 19:52, Alexandre Bergel <[hidden email]> wrote:

Anyone who has access to the CI can do this?

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 5, 2015, at 8:59 AM, Andrei Chis <[hidden email]> wrote:

Hi Alexandre,

Right now now we're updating configurations and fixing the remaining issues to be able to release moose 5.1
We can in parallel start a build for Pharo 5 but we do not have to much time to invest in it (apart from starting it) until we release.

Cheers,
Andrei

On Tue, May 5, 2015 at 3:52 PM, Alexandre Bergel <[hidden email]> wrote:
Hi!

Is there any plan to move on Pharo 5?
Can someone trigger a build?

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


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

Re: Moose on Pharo 5

Andrei Chis
In reply to this post by Andrei Chis


On Mon, May 18, 2015 at 1:47 AM, Andrei Chis <[hidden email]> wrote:
Hi,

A few more steps towards releasing moose 5.1:

- create version 5.1 for ConfigurationOfMoose
- updated
     ConfigurationOfMooseAlgos 
     ConfigurationOfFame 
     ConfigurationOfRoassal2
     ConfigurationOfMerlin
     ConfigurationOfDeepTraversal

- the jenkins job for moose5.1 now loads #stable
- created a new job that loads moose #development on pharo 5

Still to do:

ConfigurationOfSmallDude seems strange

- fixed
 
- check again that all packages in GT-* are up to date

- fixed
 
- fix moose5.0 build
   - for some strange reason monticello decides to load Glamour 3.3.0 instead of Glamour 3.0.6 when loading moose #stable in Pharo 3

The build is now green.
The initial issue is still there. I just removed some versions from ConfigurationOfGlamour
 
- there is a strange issue with ConfigurationOfRubric and monticello.

I still have no idea what is the cause of this bug, but Rubric gets updated correctly. So I would not say it's a show stopper.

So I think we can release.

Cheers,
Andrei

 


Cheers,
Andrei



On Mon, May 11, 2015 at 10:42 PM, Alexandre Bergel <[hidden email]> wrote:
Hi!

I see a lot of negative comments recently. In any company that produces a sizable software system there is at least one person dedicated to versioning, building, and packaging. 
Unfortunately, the setting used by Moose is still far from optimal. It would be nice to improve this, and this has to be done with a positive energy.

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 11, 2015, at 10:36 AM, Tudor Girba <[hidden email]> wrote:

Hi,

Perhaps something was not clear.

I did not say that everyone should work on the latest Moose. We go through the (painful) trouble of creating stable versions exactly because we want to offer the alternative of depending on something that does not change.

But, if someone wants support this will be provided on the latest Moose because this is where the development activity is. This will happen on the latest Pharo because especially now that GT is adopted in Pharo, the development effort is too close to be practical to support two different branches. Before Moose 5.0 we tried for a while to maintain GT for both Pharo 3 and deal with changes in Pharo 4 and we do not want to go through this again. This might change if the tool support changes.

Now, if someone wants to backport changes to an older Moose version, we can put in place a separate repository that can host those backported changes.

Cheers,
Tudor



On Mon, May 11, 2015 at 4:22 PM, Nicolas Anquetil <[hidden email]> wrote:

Just to explain,

we try to make a living by building on top of Moose
we try to adapt it to the lambda Cobol developper that may not be interested in learning a new syntax

So the simplest change in Moose can sometimes break everything for us.
As Usman explained, we cannot test again each morning every single feature we already implemented for every language we support.

So having a bleeding edge Moose for us is not a solution

nicolas


On 11/05/2015 11:12, Usman Bhatti wrote:
Hi,

In Synectique's case, we had several problems working with Bleeding edge of Moose:

1/ changes to the API
2/ changes that lead to performance problems
3/ when depending on bleeding edge of Pharo always testing the combo Pharo + Moose

The first one is important because one does not want to spend resources adapting to inadvertent changes. And it is easy to handle as one can always depend on a given version number (not a stable because it is moving and may create surprises that are less frequent than the bleeding edge).

Regarding changes that lead to performance issues, someone must test with real cases and evaluate. Depending on the version number works fine here too.

We would not have needed to create our own configuration if we could downgrade PetitParser but apparently, that is not possible and hence the easier solution was to create our own configuration. 

The ConfigurationOfSynectiqueMoose is just an assembly of existing versions of the components in Moose (these versions are published publicly). We just loading by hand:
-> SmallDude because it has a dependency on ConfigurationOfMoose
-> GT-Toolkit and PetitSQL because there were paths leading to PetitParser #development.
 
As for Moose depending on the bleeding edge of Pharo, it is risky business because when demoing or delivering a new version to a client, the red square of death is difficult to justify. With the stable version, we at least know where not to click :p. But one is not testing new combinations (coming from Pharo + Moose) in production.

But if there are alternate solutions in our eco-system that enable the use of bleeding edge in production that shield the users from inadvertent changes, it'll be nice to know.

regards,

Usman






On Thu, May 7, 2015 at 11:03 PM, Tudor Girba <[hidden email]> wrote:
Hi,

Yes, I think we have a different point of view on what Moose is.

I do not expect people to fork, but if they do, I would expect them to do it in a public place and help us maintain the configuration(s). For example, we could have:
- a Moose/Moose51 repository 
- commit packages with new patches for Moose 5.1 only there, and 
- modify the #stable version corresponding configurations to load those new packages.

This is doable. Would that be Ok?

Cheers,
Doru





On Wed, May 6, 2015 at 9:43 PM, stepharo <[hidden email]> wrote:
Just a question.
Do you expect people needing to have stable version to fork and work in their corners?
I do not get why Moose dev should systematically be under the bleeding edge of Pharo.
I probably do not understand what Moose is.

Stef

Le 5/5/15 19:17, Tudor Girba a écrit :
Please do not do this until we release. The reason is that this will generate more commits that will be specific to pharo 5, like the current substring problem in get inspector.

The goal is to release this or next week, and then we move to pharo 5.

Cheers,
Doru

--

"Every thing has its own flow"

On 05 May 2015, at 19:52, Alexandre Bergel <[hidden email]> wrote:

Anyone who has access to the CI can do this?

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 5, 2015, at 8:59 AM, Andrei Chis <[hidden email]> wrote:

Hi Alexandre,

Right now now we're updating configurations and fixing the remaining issues to be able to release moose 5.1
We can in parallel start a build for Pharo 5 but we do not have to much time to invest in it (apart from starting it) until we release.

Cheers,
Andrei

On Tue, May 5, 2015 at 3:52 PM, Alexandre Bergel <[hidden email]> wrote:
Hi!

Is there any plan to move on Pharo 5?
Can someone trigger a build?

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




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

Re: Moose on Pharo 5

abergel
Go go go!

> On May 19, 2015, at 4:38 AM, Andrei Chis <[hidden email]> wrote:
>
> So I think we can release.
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




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

Re: Moose on Pharo 5

Blondeau Vincent
In reply to this post by Andrei Chis

Hi,

 

Will we be able to push some patches/features to the 5.1 version of Moose easily ?

 

Cheers,

Vincent

 

De : [hidden email] [mailto:[hidden email]] De la part de Andrei Chis
Envoyé : mardi 19 mai 2015 10:39
À : Moose-related development
Objet : [Moose-dev] Re: Moose on Pharo 5

 

 

 

On Mon, May 18, 2015 at 1:47 AM, Andrei Chis <[hidden email]> wrote:

Hi,

 

A few more steps towards releasing moose 5.1:

 

- create version 5.1 for ConfigurationOfMoose

- updated

     ConfigurationOfMooseAlgos 

     ConfigurationOfFame 

     ConfigurationOfRoassal2

     ConfigurationOfMerlin

     ConfigurationOfDeepTraversal

 

- the jenkins job for moose5.1 now loads #stable

- created a new job that loads moose #development on pharo 5

 

Still to do:

 

- ConfigurationOfSmallDude seems strange

 

- fixed

 

- check again that all packages in GT-* are up to date

 

- fixed

 

- fix moose5.0 build

   - for some strange reason monticello decides to load Glamour 3.3.0 instead of Glamour 3.0.6 when loading moose #stable in Pharo 3

 

The build is now green.

The initial issue is still there. I just removed some versions from ConfigurationOfGlamour

 

- there is a strange issue with ConfigurationOfRubric and monticello.

 

I still have no idea what is the cause of this bug, but Rubric gets updated correctly. So I would not say it's a show stopper.

 

So I think we can release.

 

Cheers,

Andrei

 

 

 

 

Cheers,

Andrei

 

 

 

On Mon, May 11, 2015 at 10:42 PM, Alexandre Bergel <[hidden email]> wrote:

Hi!

 

I see a lot of negative comments recently. In any company that produces a sizable software system there is at least one person dedicated to versioning, building, and packaging. 

Unfortunately, the setting used by Moose is still far from optimal. It would be nice to improve this, and this has to be done with a positive energy.

 

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

 

On May 11, 2015, at 10:36 AM, Tudor Girba <[hidden email]> wrote:

 

Hi,

 

Perhaps something was not clear.

 

I did not say that everyone should work on the latest Moose. We go through the (painful) trouble of creating stable versions exactly because we want to offer the alternative of depending on something that does not change.

 

But, if someone wants support this will be provided on the latest Moose because this is where the development activity is. This will happen on the latest Pharo because especially now that GT is adopted in Pharo, the development effort is too close to be practical to support two different branches. Before Moose 5.0 we tried for a while to maintain GT for both Pharo 3 and deal with changes in Pharo 4 and we do not want to go through this again. This might change if the tool support changes.

 

Now, if someone wants to backport changes to an older Moose version, we can put in place a separate repository that can host those backported changes.

 

Cheers,

Tudor

 

 

 

On Mon, May 11, 2015 at 4:22 PM, Nicolas Anquetil <[hidden email]> wrote:


Just to explain,

we try to make a living by building on top of Moose
we try to adapt it to the lambda Cobol developper that may not be interested in learning a new syntax

So the simplest change in Moose can sometimes break everything for us.
As Usman explained, we cannot test again each morning every single feature we already implemented for every language we support.

So having a bleeding edge Moose for us is not a solution

nicolas

 

On 11/05/2015 11:12, Usman Bhatti wrote:

Hi,

 

In Synectique's case, we had several problems working with Bleeding edge of Moose:

 

1/ changes to the API

2/ changes that lead to performance problems

3/ when depending on bleeding edge of Pharo always testing the combo Pharo + Moose

 

The first one is important because one does not want to spend resources adapting to inadvertent changes. And it is easy to handle as one can always depend on a given version number (not a stable because it is moving and may create surprises that are less frequent than the bleeding edge).

 

Regarding changes that lead to performance issues, someone must test with real cases and evaluate. Depending on the version number works fine here too.

 

We would not have needed to create our own configuration if we could downgrade PetitParser but apparently, that is not possible and hence the easier solution was to create our own configuration. 

 

The ConfigurationOfSynectiqueMoose is just an assembly of existing versions of the components in Moose (these versions are published publicly). We just loading by hand:

-> SmallDude because it has a dependency on ConfigurationOfMoose

-> GT-Toolkit and PetitSQL because there were paths leading to PetitParser #development.

 

As for Moose depending on the bleeding edge of Pharo, it is risky business because when demoing or delivering a new version to a client, the red square of death is difficult to justify. With the stable version, we at least know where not to click :p. But one is not testing new combinations (coming from Pharo + Moose) in production.

 

But if there are alternate solutions in our eco-system that enable the use of bleeding edge in production that shield the users from inadvertent changes, it'll be nice to know.

 

regards,

 

Usman

 

 

 

 

 

 

On Thu, May 7, 2015 at 11:03 PM, Tudor Girba <[hidden email]> wrote:

Hi,

 

Yes, I think we have a different point of view on what Moose is.

 

I do not expect people to fork, but if they do, I would expect them to do it in a public place and help us maintain the configuration(s). For example, we could have:

- a Moose/Moose51 repository 

- commit packages with new patches for Moose 5.1 only there, and 

- modify the #stable version corresponding configurations to load those new packages.

 

This is doable. Would that be Ok?

 

Cheers,

Doru

 

 

 

 

 

On Wed, May 6, 2015 at 9:43 PM, stepharo <[hidden email]> wrote:

Just a question.
Do you expect people needing to have stable version to fork and work in their corners?
I do not get why Moose dev should systematically be under the bleeding edge of Pharo.
I probably do not understand what Moose is.

Stef

Le 5/5/15 19:17, Tudor Girba a écrit :

Please do not do this until we release. The reason is that this will generate more commits that will be specific to pharo 5, like the current substring problem in get inspector.

 

The goal is to release this or next week, and then we move to pharo 5.

 

Cheers,

Doru

--

 

"Every thing has its own flow"


On 05 May 2015, at 19:52, Alexandre Bergel <[hidden email]> wrote:

Anyone who has access to the CI can do this?

 

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

 

On May 5, 2015, at 8:59 AM, Andrei Chis <[hidden email]> wrote:

 

Hi Alexandre,

 

Right now now we're updating configurations and fixing the remaining issues to be able to release moose 5.1

We can in parallel start a build for Pharo 5 but we do not have to much time to invest in it (apart from starting it) until we release.

 

Cheers,

Andrei

 

On Tue, May 5, 2015 at 3:52 PM, Alexandre Bergel <[hidden email]> wrote:

Hi!

Is there any plan to move on Pharo 5?
Can someone trigger a build?

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



 

--

 

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



 

--

 

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

 




Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

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

Re: Moose on Pharo 5

Tudor Girba-2
Hi,

The plan is to create a Moose/Moose51 repository and have all Moose 5.1 specific patches committed there. When a new version is wanted, the #stable ConfigrationOfMoose for Pharo 4 will be updated with the new packages by the one that needs that version.

For example, suppose that after the release of 5.1, you need a patch in Moose-Core:
- You publish a new Moose-Core in Moose/Moose51
- You create a version511 in ConfigurationOfMoose
- You change the #stable to point to that version

Would that be Ok?

Cheers,
Doru


On Tue, May 19, 2015 at 1:45 PM, Blondeau Vincent <[hidden email]> wrote:

Hi,

 

Will we be able to push some patches/features to the 5.1 version of Moose easily ?

 

Cheers,

Vincent

 

De : [hidden email] [mailto:[hidden email]] De la part de Andrei Chis
Envoyé : mardi 19 mai 2015 10:39
À : Moose-related development
Objet : [Moose-dev] Re: Moose on Pharo 5

 

 

 

On Mon, May 18, 2015 at 1:47 AM, Andrei Chis <[hidden email]> wrote:

Hi,

 

A few more steps towards releasing moose 5.1:

 

- create version 5.1 for ConfigurationOfMoose

- updated

     ConfigurationOfMooseAlgos 

     ConfigurationOfFame 

     ConfigurationOfRoassal2

     ConfigurationOfMerlin

     ConfigurationOfDeepTraversal

 

- the jenkins job for moose5.1 now loads #stable

- created a new job that loads moose #development on pharo 5

 

Still to do:

 

- ConfigurationOfSmallDude seems strange

 

- fixed

 

- check again that all packages in GT-* are up to date

 

- fixed

 

- fix moose5.0 build

   - for some strange reason monticello decides to load Glamour 3.3.0 instead of Glamour 3.0.6 when loading moose #stable in Pharo 3

 

The build is now green.

The initial issue is still there. I just removed some versions from ConfigurationOfGlamour

 

- there is a strange issue with ConfigurationOfRubric and monticello.

 

I still have no idea what is the cause of this bug, but Rubric gets updated correctly. So I would not say it's a show stopper.

 

So I think we can release.

 

Cheers,

Andrei

 

 

 

 

Cheers,

Andrei

 

 

 

On Mon, May 11, 2015 at 10:42 PM, Alexandre Bergel <[hidden email]> wrote:

Hi!

 

I see a lot of negative comments recently. In any company that produces a sizable software system there is at least one person dedicated to versioning, building, and packaging. 

Unfortunately, the setting used by Moose is still far from optimal. It would be nice to improve this, and this has to be done with a positive energy.

 

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

 

On May 11, 2015, at 10:36 AM, Tudor Girba <[hidden email]> wrote:

 

Hi,

 

Perhaps something was not clear.

 

I did not say that everyone should work on the latest Moose. We go through the (painful) trouble of creating stable versions exactly because we want to offer the alternative of depending on something that does not change.

 

But, if someone wants support this will be provided on the latest Moose because this is where the development activity is. This will happen on the latest Pharo because especially now that GT is adopted in Pharo, the development effort is too close to be practical to support two different branches. Before Moose 5.0 we tried for a while to maintain GT for both Pharo 3 and deal with changes in Pharo 4 and we do not want to go through this again. This might change if the tool support changes.

 

Now, if someone wants to backport changes to an older Moose version, we can put in place a separate repository that can host those backported changes.

 

Cheers,

Tudor

 

 

 

On Mon, May 11, 2015 at 4:22 PM, Nicolas Anquetil <[hidden email]> wrote:


Just to explain,

we try to make a living by building on top of Moose
we try to adapt it to the lambda Cobol developper that may not be interested in learning a new syntax

So the simplest change in Moose can sometimes break everything for us.
As Usman explained, we cannot test again each morning every single feature we already implemented for every language we support.

So having a bleeding edge Moose for us is not a solution

nicolas

 

On 11/05/2015 11:12, Usman Bhatti wrote:

Hi,

 

In Synectique's case, we had several problems working with Bleeding edge of Moose:

 

1/ changes to the API

2/ changes that lead to performance problems

3/ when depending on bleeding edge of Pharo always testing the combo Pharo + Moose

 

The first one is important because one does not want to spend resources adapting to inadvertent changes. And it is easy to handle as one can always depend on a given version number (not a stable because it is moving and may create surprises that are less frequent than the bleeding edge).

 

Regarding changes that lead to performance issues, someone must test with real cases and evaluate. Depending on the version number works fine here too.

 

We would not have needed to create our own configuration if we could downgrade PetitParser but apparently, that is not possible and hence the easier solution was to create our own configuration. 

 

The ConfigurationOfSynectiqueMoose is just an assembly of existing versions of the components in Moose (these versions are published publicly). We just loading by hand:

-> SmallDude because it has a dependency on ConfigurationOfMoose

-> GT-Toolkit and PetitSQL because there were paths leading to PetitParser #development.

 

As for Moose depending on the bleeding edge of Pharo, it is risky business because when demoing or delivering a new version to a client, the red square of death is difficult to justify. With the stable version, we at least know where not to click :p. But one is not testing new combinations (coming from Pharo + Moose) in production.

 

But if there are alternate solutions in our eco-system that enable the use of bleeding edge in production that shield the users from inadvertent changes, it'll be nice to know.

 

regards,

 

Usman

 

 

 

 

 

 

On Thu, May 7, 2015 at 11:03 PM, Tudor Girba <[hidden email]> wrote:

Hi,

 

Yes, I think we have a different point of view on what Moose is.

 

I do not expect people to fork, but if they do, I would expect them to do it in a public place and help us maintain the configuration(s). For example, we could have:

- a Moose/Moose51 repository 

- commit packages with new patches for Moose 5.1 only there, and 

- modify the #stable version corresponding configurations to load those new packages.

 

This is doable. Would that be Ok?

 

Cheers,

Doru

 

 

 

 

 

On Wed, May 6, 2015 at 9:43 PM, stepharo <[hidden email]> wrote:

Just a question.
Do you expect people needing to have stable version to fork and work in their corners?
I do not get why Moose dev should systematically be under the bleeding edge of Pharo.
I probably do not understand what Moose is.

Stef

Le 5/5/15 19:17, Tudor Girba a écrit :

Please do not do this until we release. The reason is that this will generate more commits that will be specific to pharo 5, like the current substring problem in get inspector.

 

The goal is to release this or next week, and then we move to pharo 5.

 

Cheers,

Doru

--

 

"Every thing has its own flow"


On 05 May 2015, at 19:52, Alexandre Bergel <[hidden email]> wrote:

Anyone who has access to the CI can do this?

 

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

 

On May 5, 2015, at 8:59 AM, Andrei Chis <[hidden email]> wrote:

 

Hi Alexandre,

 

Right now now we're updating configurations and fixing the remaining issues to be able to release moose 5.1

We can in parallel start a build for Pharo 5 but we do not have to much time to invest in it (apart from starting it) until we release.

 

Cheers,

Andrei

 

On Tue, May 5, 2015 at 3:52 PM, Alexandre Bergel <[hidden email]> wrote:

Hi!

Is there any plan to move on Pharo 5?
Can someone trigger a build?

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



 

--

 

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



 

--

 

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

 




Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"

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

Re: Moose on Pharo 5

Blondeau Vincent

Why not.

But how can I change the repository in the ConfigurationOfMoose because for now everything will be in Moose/Moose and in the future some packages will be in Moose/Moose and in Moose/Moose5.1.

Moreover I should put the patch in the 5.2 version or all the patchs in Moose/Moose5.1 will be ported to Moose 5.2 ?

And what about external projects like Fame or Moose Algos ? Do I need to commit in Moose/Moose5.1 too ?

 

Vincent

 

 

De : [hidden email] [mailto:[hidden email]] De la part de Tudor Girba
Envoyé : mardi 19 mai 2015 14:07
À : Moose-related development
Objet : [Moose-dev] Re: Moose on Pharo 5

 

Hi,

 

The plan is to create a Moose/Moose51 repository and have all Moose 5.1 specific patches committed there. When a new version is wanted, the #stable ConfigrationOfMoose for Pharo 4 will be updated with the new packages by the one that needs that version.

 

For example, suppose that after the release of 5.1, you need a patch in Moose-Core:

- You publish a new Moose-Core in Moose/Moose51

- You create a version511 in ConfigurationOfMoose

- You change the #stable to point to that version

 

Would that be Ok?

 

Cheers,

Doru

 

 

On Tue, May 19, 2015 at 1:45 PM, Blondeau Vincent <[hidden email]> wrote:

Hi,

 

Will we be able to push some patches/features to the 5.1 version of Moose easily ?

 

Cheers,

Vincent

 

De : [hidden email] [mailto:[hidden email]] De la part de Andrei Chis
Envoyé : mardi 19 mai 2015 10:39
À : Moose-related development
Objet : [Moose-dev] Re: Moose on Pharo 5

 

 

 

On Mon, May 18, 2015 at 1:47 AM, Andrei Chis <[hidden email]> wrote:

Hi,

 

A few more steps towards releasing moose 5.1:

 

- create version 5.1 for ConfigurationOfMoose

- updated

     ConfigurationOfMooseAlgos 

     ConfigurationOfFame 

     ConfigurationOfRoassal2

     ConfigurationOfMerlin

     ConfigurationOfDeepTraversal

 

- the jenkins job for moose5.1 now loads #stable

- created a new job that loads moose #development on pharo 5

 

Still to do:

 

- ConfigurationOfSmallDude seems strange

 

- fixed

 

- check again that all packages in GT-* are up to date

 

- fixed

 

- fix moose5.0 build

   - for some strange reason monticello decides to load Glamour 3.3.0 instead of Glamour 3.0.6 when loading moose #stable in Pharo 3

 

The build is now green.

The initial issue is still there. I just removed some versions from ConfigurationOfGlamour

 

- there is a strange issue with ConfigurationOfRubric and monticello.

 

I still have no idea what is the cause of this bug, but Rubric gets updated correctly. So I would not say it's a show stopper.

 

So I think we can release.

 

Cheers,

Andrei

 

 

 

 

Cheers,

Andrei

 

 

 

On Mon, May 11, 2015 at 10:42 PM, Alexandre Bergel <[hidden email]> wrote:

Hi!

 

I see a lot of negative comments recently. In any company that produces a sizable software system there is at least one person dedicated to versioning, building, and packaging. 

Unfortunately, the setting used by Moose is still far from optimal. It would be nice to improve this, and this has to be done with a positive energy.

 

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

 

On May 11, 2015, at 10:36 AM, Tudor Girba <[hidden email]> wrote:

 

Hi,

 

Perhaps something was not clear.

 

I did not say that everyone should work on the latest Moose. We go through the (painful) trouble of creating stable versions exactly because we want to offer the alternative of depending on something that does not change.

 

But, if someone wants support this will be provided on the latest Moose because this is where the development activity is. This will happen on the latest Pharo because especially now that GT is adopted in Pharo, the development effort is too close to be practical to support two different branches. Before Moose 5.0 we tried for a while to maintain GT for both Pharo 3 and deal with changes in Pharo 4 and we do not want to go through this again. This might change if the tool support changes.

 

Now, if someone wants to backport changes to an older Moose version, we can put in place a separate repository that can host those backported changes.

 

Cheers,

Tudor

 

 

 

On Mon, May 11, 2015 at 4:22 PM, Nicolas Anquetil <[hidden email]> wrote:


Just to explain,

we try to make a living by building on top of Moose
we try to adapt it to the lambda Cobol developper that may not be interested in learning a new syntax

So the simplest change in Moose can sometimes break everything for us.
As Usman explained, we cannot test again each morning every single feature we already implemented for every language we support.

So having a bleeding edge Moose for us is not a solution

nicolas

 

On 11/05/2015 11:12, Usman Bhatti wrote:

Hi,

 

In Synectique's case, we had several problems working with Bleeding edge of Moose:

 

1/ changes to the API

2/ changes that lead to performance problems

3/ when depending on bleeding edge of Pharo always testing the combo Pharo + Moose

 

The first one is important because one does not want to spend resources adapting to inadvertent changes. And it is easy to handle as one can always depend on a given version number (not a stable because it is moving and may create surprises that are less frequent than the bleeding edge).

 

Regarding changes that lead to performance issues, someone must test with real cases and evaluate. Depending on the version number works fine here too.

 

We would not have needed to create our own configuration if we could downgrade PetitParser but apparently, that is not possible and hence the easier solution was to create our own configuration. 

 

The ConfigurationOfSynectiqueMoose is just an assembly of existing versions of the components in Moose (these versions are published publicly). We just loading by hand:

-> SmallDude because it has a dependency on ConfigurationOfMoose

-> GT-Toolkit and PetitSQL because there were paths leading to PetitParser #development.

 

As for Moose depending on the bleeding edge of Pharo, it is risky business because when demoing or delivering a new version to a client, the red square of death is difficult to justify. With the stable version, we at least know where not to click :p. But one is not testing new combinations (coming from Pharo + Moose) in production.

 

But if there are alternate solutions in our eco-system that enable the use of bleeding edge in production that shield the users from inadvertent changes, it'll be nice to know.

 

regards,

 

Usman

 

 

 

 

 

 

On Thu, May 7, 2015 at 11:03 PM, Tudor Girba <[hidden email]> wrote:

Hi,

 

Yes, I think we have a different point of view on what Moose is.

 

I do not expect people to fork, but if they do, I would expect them to do it in a public place and help us maintain the configuration(s). For example, we could have:

- a Moose/Moose51 repository 

- commit packages with new patches for Moose 5.1 only there, and 

- modify the #stable version corresponding configurations to load those new packages.

 

This is doable. Would that be Ok?

 

Cheers,

Doru

 

 

 

 

 

On Wed, May 6, 2015 at 9:43 PM, stepharo <[hidden email]> wrote:

Just a question.
Do you expect people needing to have stable version to fork and work in their corners?
I do not get why Moose dev should systematically be under the bleeding edge of Pharo.
I probably do not understand what Moose is.

Stef

Le 5/5/15 19:17, Tudor Girba a écrit :

Please do not do this until we release. The reason is that this will generate more commits that will be specific to pharo 5, like the current substring problem in get inspector.

 

The goal is to release this or next week, and then we move to pharo 5.

 

Cheers,

Doru

--

 

"Every thing has its own flow"


On 05 May 2015, at 19:52, Alexandre Bergel <[hidden email]> wrote:

Anyone who has access to the CI can do this?

 

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

 

On May 5, 2015, at 8:59 AM, Andrei Chis <[hidden email]> wrote:

 

Hi Alexandre,

 

Right now now we're updating configurations and fixing the remaining issues to be able to release moose 5.1

We can in parallel start a build for Pharo 5 but we do not have to much time to invest in it (apart from starting it) until we release.

 

Cheers,

Andrei

 

On Tue, May 5, 2015 at 3:52 PM, Alexandre Bergel <[hidden email]> wrote:

Hi!

Is there any plan to move on Pharo 5?
Can someone trigger a build?

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



 

--

 

"Every thing has its own flow"


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

 

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



 

--

 

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

 

 



Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



 

--

 

"Every thing has its own flow"




Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
12