Moose on Pharo 5
Locked
12
12
 
|
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 |
|
|
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! _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Anyone who has access to the CI can do this?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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,
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In the meantime I updated all configurations for the gtools (spotter/inspector/playground/debugger) to have a stable version for pharo 4. Also updated the configurations of petit parser and petit sql. I'll try to go though the remaining configurations these days. I'll revert now the commit that caused the substring issue in the inspector as it's kind of annoying. Cheers, Andrei On Tue, May 5, 2015 at 7:17 PM, Tudor Girba <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Ok. Fixed the issue with the substring in the inspector. Now all tests are green in the moose build (#development version for Pharo 4). I also made the tests from the gtoolkit build run in the moose build. This tests that all available examples from the image create without any exception. Given that there are a lot of examples, especially for Roassal, the build time for increased from 5 to 13 minutes. Cheers, Andrei On Tue, May 5, 2015 at 7:28 PM, Andrei Chis <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
Sounds like a good plan!
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Andrei Chis
Great job! Perhaps for the case when we have multiple examples, we could run only some of them randomly on every run for the smoke tests. What do you think? Doru On Tue, May 5, 2015 at 9:38 PM, Andrei Chis <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
For now 13 minutes does not seem such a long time for the whole moose build. If the time increases even more we could have some strategy for selecting examples. Still testing all examples is also nice, as long as it does not take forever. Cheers, Andrei On Tue, May 5, 2015 at 10:02 PM, Tudor Girba <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Regarding the remaining configurations that are accessed from ConfigurationOfMoose The following need to be updated (apart from ConfigurationOfMoose): ConfigurationOfMooseAlgos ConfigurationOfFame ConfigurationOfSmallDude ConfigurationOfRoassal2 ConfigurationOfMerlin The following configurations are ok and do not need to be changed: ConfigurationOfMetanool ConfigurationOfHashTable ConfigurationOfRoelTyper Was there some script to get a list of all configurations that should be checked? Cheers, Andrei On Tue, May 5, 2015 at 10:08 PM, Andrei Chis <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
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 :
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> 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 I do not know because I do not really understand your solution. What I hope to do is to be able to release Moose with versions and that Moose could be released every month. We will see that with christophe ppm. Now not having versions (or may be there are released moose versions based on exact version number) and a nearly systematic way to work on alpha of Pharo is clearly the best way to have most of the risk when you need stability. (And I do not talk about people having to change all the roassal code in the middle like olivier for his paper on artefact). And you should understand that people from RMOD are not complaining to me. I think that some of them just do not use recent versions of Moose take one and stay with it. Now I'm curious to know if we can rebuild an old Moose image. So this means that people should not use an image automatically built (I sincerly hope that I'm wrong here). I did not talk recently to synectiquers but they do probably the same and I understand them. Stef _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> So this means that people should not use an image automatically built (I sincerly hope that I'm wrong here).
Why this? I personally always download the last version of Moose from jenkins. Works well, except when time to time the Moose image is based on an old version of Pharo. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by stepharo
Hi Stef,
On Sat, May 9, 2015 at 2:58 PM, stepharo <[hidden email]> wrote:
What I hope to do is to be able to release Moose with versions and that Moose could be released every month. I would have no problem releasing Moose every month. In fact, I argue that we should release it every day when the build is green. Except that Moose 5.0 was released on Pharo 3 in December, and since then (5 months) nobody issued a request of change on that release. It either means that people are happy with that version, or that they are Ok with using the latest Moose which happened to be developed on top of the development version of Pharo. To ensure that the process that stresses the latest version works, I use the latest Moose in production every day (even for tools that are used by others). But, if someone is using an older Moose and they need a patch, we can create a repository for these patches (e.g., Moose/Moose51), and we just modify the stable version of the configuration to load the patched packages from this repository. This would give people a simple way to provide these patches, and we would keep Moose/Moose for the head development. We will see that with christophe ppm. I am certainly looking forward to it. Now not having versions (or may be there are released moose versions based on exact version number) and Moose 5.0 is a version. And Moose 5.1 will be another version. And you should understand that people from RMOD are not complaining to me. I think that some of them just do not use That is an option that people can choose. It's not ideal for the rest of us, but I am happy it works for them. Now I'm curious to know if we can rebuild an old Moose image. Yes, you are basically wrong. Up to Moose 4.9, we had a snapshot and hardcoded versions. This proved to be not maintainable in the longer term. For example, when someone needed to fix something in one of the deeply nested projects (like Rubric), it was not clear which versions should be updated. So, starting with Moose 5.0, we moved to only having #stable of moose to depend on other #stable of all other configurations. This is much cheaper to maintain. However, it also implies a small variability. We could still do a snapshot together with the #stable version, but in practice it proved to not be needed. The Moose 5.0 job ensures exactly that: I did not talk recently to synectiquers but they do probably the same and I understand them. What should they do? Cheers, Doru
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
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:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |