Version number for Moose

> Hi!
>
> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>
> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>
> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
> It still contains:
> spec
> project: 'MooseAlgos for Moose' with: '2.2';
> project: 'PetitParser for Moose' with: 'default';
> project: 'DSM for Moose' with: 'default';
> project: 'Glamour for Moose' with: '2.1';
> project: 'Mondrian for Moose' with: 'default';
> project: 'SmallDude for Moose' with: 'default';
> project: 'Merlin' with: '1.0';
> project: 'RPackage' with: 'default'.
>
> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>
> Alexandre
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Another important topic. Now that each version of moose will be made explicit.
> How do we integrate them in Hudson?
>
> If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.
>
> Cheers,
> Alexandre
>
>
> On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:
>
>> Hi!
>>
>> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>>
>> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>>
>> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
>> It still contains:
>> spec
>> project: 'MooseAlgos for Moose' with: '2.2';
>> project: 'PetitParser for Moose' with: 'default';
>> project: 'DSM for Moose' with: 'default';
>> project: 'Glamour for Moose' with: '2.1';
>> project: 'Mondrian for Moose' with: 'default';
>> project: 'SmallDude for Moose' with: 'default';
>> project: 'Merlin' with: '1.0';
>> project: 'RPackage' with: 'default'.
>>
>> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>>
>> Alexandre
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

>
>
> On 17 Feb 2011, at 16:24, Alexandre Bergel wrote:
>
>> Another important topic. Now that each version of moose will be made explicit.
>> How do we integrate them in Hudson?
>>
>> If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.
>>
>> Cheers,
>> Alexandre
>>
>>
>> On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:
>>
>>> Hi!
>>>
>>> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>>>
>>> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>>>
>>> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
>>> It still contains:
>>> spec
>>> project: 'MooseAlgos for Moose' with: '2.2';
>>> project: 'PetitParser for Moose' with: 'default';
>>> project: 'DSM for Moose' with: 'default';
>>> project: 'Glamour for Moose' with: '2.1';
>>> project: 'Mondrian for Moose' with: 'default';
>>> project: 'SmallDude for Moose' with: 'default';
>>> project: 'Merlin' with: '1.0';
>>> project: 'RPackage' with: 'default'.
>>>
>>> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>>>
>>> Alexandre
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "One cannot do more than one can do."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

>
> Ok, we're in sync.
>
>> For the versioning, we should be able to start from the default of Moose and from there create actual versions recursively in all contained packages.
>
> Indeed. But how to achieve this?
> Who should have the responsibility of creating a new version of dependent packages? The author of the package I guess. MetacelloBrowser is a better replacement than Monticello.
> I will continue to produce versions of each dependent packages in the meantime.
>
> Having a complete trace of each version of several software will open new doors for analysis...

>
> Alexandre
>
>>
>>
>> On 17 Feb 2011, at 16:24, Alexandre Bergel wrote:
>>
>>> Another important topic. Now that each version of moose will be made explicit.
>>> How do we integrate them in Hudson?
>>>
>>> If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>
>>> On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:
>>>
>>>> Hi!
>>>>
>>>> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>>>>
>>>> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>>>>
>>>> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
>>>> It still contains:
>>>> spec
>>>> project: 'MooseAlgos for Moose' with: '2.2';
>>>> project: 'PetitParser for Moose' with: 'default';
>>>> project: 'DSM for Moose' with: 'default';
>>>> project: 'Glamour for Moose' with: '2.1';
>>>> project: 'Mondrian for Moose' with: 'default';
>>>> project: 'SmallDude for Moose' with: 'default';
>>>> project: 'Merlin' with: '1.0';
>>>> project: 'RPackage' with: 'default'.
>>>>
>>>> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>>>>
>>>> Alexandre
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "One cannot do more than one can do."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

>> Ok, we're in sync.
>>
>>> For the versioning, we should be able to start from the default of Moose and from there create actual versions recursively in all contained packages.
>>
>> Indeed. But how to achieve this?
>> Who should have the responsibility of creating a new version of dependent packages? The author of the package I guess. MetacelloBrowser is a better replacement than Monticello.
>> I will continue to produce versions of each dependent packages in the meantime.
>>
>> Having a complete trace of each version of several software will open new doors for analysis...
>
> :)
> I remember saying that a lot :)
> and I was sad that we could not use moose evolution.
>
>>
>> Alexandre
>>
>>>
>>>
>>> On 17 Feb 2011, at 16:24, Alexandre Bergel wrote:
>>>
>>>> Another important topic. Now that each version of moose will be made explicit.
>>>> How do we integrate them in Hudson?
>>>>
>>>> If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>
>>>> On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>>>>>
>>>>> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>>>>>
>>>>> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
>>>>> It still contains:
>>>>> spec
>>>>> project: 'MooseAlgos for Moose' with: '2.2';
>>>>> project: 'PetitParser for Moose' with: 'default';
>>>>> project: 'DSM for Moose' with: 'default';
>>>>> project: 'Glamour for Moose' with: '2.1';
>>>>> project: 'Mondrian for Moose' with: 'default';
>>>>> project: 'SmallDude for Moose' with: 'default';
>>>>> project: 'Merlin' with: '1.0';
>>>>> project: 'RPackage' with: 'default'.
>>>>>
>>>>> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>>>>>
>>>>> Alexandre
>>>>>
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "One cannot do more than one can do."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> 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

>>>> Actual versions should never depend on baselines because we want them to be reloadable in 10 years.
>>
>> I did not get what you mean because the versions should import the baseline?
>
> A baseline configuration is just a set of packages, without actual versions. I said that we should not depend on a baseline configuration in an actual version because then we depend on the latest version.
>
> Doru
>
>
>
>>> Ok, we're in sync.
>>>
>>>> For the versioning, we should be able to start from the default of Moose and from there create actual versions recursively in all contained packages.
>>>
>>> Indeed. But how to achieve this?
>>> Who should have the responsibility of creating a new version of dependent packages? The author of the package I guess. MetacelloBrowser is a better replacement than Monticello.
>>> I will continue to produce versions of each dependent packages in the meantime.
>>>
>>> Having a complete trace of each version of several software will open new doors for analysis...
>>
>> :)
>> I remember saying that a lot :)
>> and I was sad that we could not use moose evolution.
>>
>>>
>>> Alexandre
>>>
>>>>
>>>>
>>>> On 17 Feb 2011, at 16:24, Alexandre Bergel wrote:
>>>>
>>>>> Another important topic. Now that each version of moose will be made explicit.
>>>>> How do we integrate them in Hudson?
>>>>>
>>>>> If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.
>>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>
>>>>> On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>>>>>>
>>>>>> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>>>>>>
>>>>>> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
>>>>>> It still contains:
>>>>>> spec
>>>>>> project: 'MooseAlgos for Moose' with: '2.2';
>>>>>> project: 'PetitParser for Moose' with: 'default';
>>>>>> project: 'DSM for Moose' with: 'default';
>>>>>> project: 'Glamour for Moose' with: '2.1';
>>>>>> project: 'Mondrian for Moose' with: 'default';
>>>>>> project: 'SmallDude for Moose' with: 'default';
>>>>>> project: 'Merlin' with: '1.0';
>>>>>> project: 'RPackage' with: 'default'.
>>>>>>
>>>>>> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>>>>>>
>>>>>> Alexandre
>>>>>>
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "One cannot do more than one can do."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> 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
>
> --
> www.tudorgirba.com
>
> "Not knowing how to do something is not an argument for how it cannot be done."
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> I still do not get it.
> For me a baseline is a baseline (set of package name with the required information.
> So a version depends on a baseline and specifies specific version information.
> So a version depends on baselines. and you just say the inverse so I'm totally confused.
>
>>>>> Actual versions should never depend on baselines because we want them to be reloadable in 10 years.
>>>
>>> I did not get what you mean because the versions should import the baseline?
>>
>> A baseline configuration is just a set of packages, without actual versions. I said that we should not depend on a baseline configuration in an actual version because then we depend on the latest version.
>>
>> Doru
>>
>>
>>
>>>> Ok, we're in sync.
>>>>
>>>>> For the versioning, we should be able to start from the default of Moose and from there create actual versions recursively in all contained packages.
>>>>
>>>> Indeed. But how to achieve this?
>>>> Who should have the responsibility of creating a new version of dependent packages? The author of the package I guess. MetacelloBrowser is a better replacement than Monticello.
>>>> I will continue to produce versions of each dependent packages in the meantime.
>>>>
>>>> Having a complete trace of each version of several software will open new doors for analysis...
>>>
>>> :)
>>> I remember saying that a lot :)
>>> and I was sad that we could not use moose evolution.
>>>
>>>>
>>>> Alexandre
>>>>
>>>>>
>>>>>
>>>>> On 17 Feb 2011, at 16:24, Alexandre Bergel wrote:
>>>>>
>>>>>> Another important topic. Now that each version of moose will be made explicit.
>>>>>> How do we integrate them in Hudson?
>>>>>>
>>>>>> If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.
>>>>>>
>>>>>> Cheers,
>>>>>> Alexandre
>>>>>>
>>>>>>
>>>>>> On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:
>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>>>>>>>
>>>>>>> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>>>>>>>
>>>>>>> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
>>>>>>> It still contains:
>>>>>>> spec
>>>>>>> project: 'MooseAlgos for Moose' with: '2.2';
>>>>>>> project: 'PetitParser for Moose' with: 'default';
>>>>>>> project: 'DSM for Moose' with: 'default';
>>>>>>> project: 'Glamour for Moose' with: '2.1';
>>>>>>> project: 'Mondrian for Moose' with: 'default';
>>>>>>> project: 'SmallDude for Moose' with: 'default';
>>>>>>> project: 'Merlin' with: '1.0';
>>>>>>> project: 'RPackage' with: 'default'.
>>>>>>>
>>>>>>> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>>>>>>>
>>>>>>> Alexandre
>>>>>>>
>>>>>>> --
>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "One cannot do more than one can do."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> 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
>>
>> --
>> www.tudorgirba.com
>>
>> "Not knowing how to do something is not an argument for how it cannot be done."
>>
>>
>> _______________________________________________
>> 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