Moose-dev July 2014

moose-dev@list.inf.unibe.ch

36 participants
143 discussions

Fixing configurationOfMoose
by stepharo 02 Jul '14

02 Jul '14

Hi with c. we are generating automatically configuration for Units and we are finding bugs in ConfigurationOfMoose (assembly). package: 'Moose-Hismo' with: [spec requires: 'Famix-Core']; package: 'Moose-HismoImporter'; => package: 'Moose-Hismo' with: [spec requires: 'Famix-Core']; package: 'Moose-HismoImporter' with: [spec requires: 'Moose-Hismo']; Same with Moose-Test-HismImporter we should fix it stef

1 0

Jenkins build became unstable: moose-5.0 #1799
by admin＠moosetechnology.org 02 Jul '14

02 Jul '14

See <https://ci.inria.fr/moose/job/moose-5.0/1799/>

1 0

access to roassal configuration
by stepharo 02 Jul '14

02 Jul '14

Hi alex the roassal configuration is old and the versions are outdated. If you give me access I will fix them nicely. Else I will fork it. Stef

3 8

Projects vs Dependencies View of Configuration
by stepharo 02 Jul '14

02 Jul '14

Orthogonally to the process open dev / release, we have the notion of two different uses of Configurations. I call them the Projects vs the Dependencies style. Let us look at these two uses. I will take an example that is not in Moose but we can see the exact same problems in Moose. There is a parallel with XMLSupport (a group loading XMLparser, writer, SIXX, Pastell.... and XMLParser, XMLWriter XMLSupport is a "Project" configuration: it is a convenient way to group and load (in particular it expresses dependencies to clients of XML) so the relation is not I load Sixx because I dependent on it. More I load it because I want to optionally offer it. XMLParser is a "Dependencies" configuration: to parse XML we need OrderedPreservingDictionary, Bitmap... if we do not load them we cannot get XMLParser working. Why this difference is important: When you want to build a tool using the XMLParser you do not want to get SIXX. pastell when you do not need it. Based on this analysis we see that PetitParser project, MooseIDE project are Projects while PetitParser (the package), MooseCore (the package) are dependencies configuration. Now the problem is that we do not have a simple way to express the dependencies at the level of a package. Because when coding the XMLParser package you would write that it depends on SIXX. Christophe is working on a prototype to get package dependencies expressed at the package level and he will present that at ESUG but this is not ready to use. Now we could (but this is a lot of work) add a configuration"Dependencies" to any package. These dependencies would be really simple. We already have that for Traverser, Merlin, RoelTyper and many others. This way we could have - Project configurations - Dependencies configurations Now I would like to see is do we do it? Would be good to have different names to identify these configurations clearly. Or at least have a description that clearly say it. Stef

3 10

refactoring moose-chef dependency traits
by Usman Bhatti 02 Jul '14

02 Jul '14

Name: Famix-Core-usmanbhatti.237 Author: usmanbhatti Time: 1 July 2014, 4:15:42.620954 pm UUID: a3822a71-e6f7-4d21-abc1-bab82b31b9dc Ancestors: Famix-Core-MirceaLungu.236 refactoring the common behavior to query dependencies in a paradigm agnostic way and creating a new trait to compute dependencies of object-oriented entities. This refactoring was necessary to reuse moose chef queries for non object oriented systems that do not have inheritance. Tests are green. usman

2 1

About roassal2
by stepharo 02 Jul '14

02 Jul '14

Hi alex Why Roassal depends on FuelMetalevel? - having the stable as a baseline is not nice because clients will cry big times. - there is no correct version and it would be good to use versionner to manage it and to release some versions from time to time. Now that roassal2 is out it is importnt that people can build on versions if they want. Typically Synectiquers should really pay attention to this "detail" - unique version is pure junk and looks like from a tutorial so I can clean it. - versionDevelopment: introduce a dependencies to FuelMetalevel. I do not have access to it but I can clean it fast. Else I will fork it. Stef

4 12

code completion?
by Alexandre Bergel 01 Jul '14

01 Jul '14

Apparently it is disabled. Is this intended? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 3

Re: Projects vs Dependencies View of Configuration
by Stephan Eggermont 01 Jul '14

01 Jul '14

>Now the problem is that we do not have a simple way to express the >dependencies at the level of a package. AFAIK, we can express that pretty good with groups and package requires in Metacello. Stephan

1 0

Re: Revert of configuration changes neeeded
by Stephan Eggermont 01 Jul '14

01 Jul '14

Stef wrote: >I fixed them and they should work. Thank you. Stephan

1 0

Re: Revert of configuration changes neeeded
by Stephan Eggermont 01 Jul '14

01 Jul '14

My assumption is that in changing configurations, we don't break older versions and versions for other platforms. Sometimes we only fix things for specific (newest) versions, but otherwise keep them intact. We've started looking at the changes made, and that principle is not respected. Please note that at the moment Versioner cannot reliably be used to version configurations that use platform tags. The change in ConfigurationOfXMLWriter broke the build. Diego reverted the change. Stephan

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev July 2014