planning moose 4.7 and moving to Pharo 2.0

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

planning moose 4.7 and moving to Pharo 2.0

Tudor Girba-2
Hi,

We have to think about releasing Moose 4.7 and moving to Pharo 2.0.

There are several reasons why the move to 2.0 would make sense:
1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible.
2. The environment moved to RPackage entirely.
3. Pharo needs users.

Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points:

The most pressing ones are:
Issue 799: Editing code in Glamour must be faster
Issue 851: Create a stable version for Moose and all its subparts
Issue 853: ConfigurationOfMoose should be split to reflect core vs suite

Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker?

My idea is to target a release this year. Input is more than welcome :)

Cheers,
Doru

--

"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: planning moose 4.7 and moving to Pharo 2.0

Tudor Girba-2
Is there anyone interested in joining this effort?

Cheers,
Doru


On 15 Oct 2012, at 08:28, Tudor Girba <[hidden email]> wrote:

> Hi,
>
> We have to think about releasing Moose 4.7 and moving to Pharo 2.0.
>
> There are several reasons why the move to 2.0 would make sense:
> 1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible.
> 2. The environment moved to RPackage entirely.
> 3. Pharo needs users.
>
> Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points:
> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone%3D4.7
>
> The most pressing ones are:
> Issue 799: Editing code in Glamour must be faster
> Issue 851: Create a stable version for Moose and all its subparts
> Issue 853: ConfigurationOfMoose should be split to reflect core vs suite
>
> Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker?
>
> My idea is to target a release this year. Input is more than welcome :)
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

--
www.tudorgirba.com

"Quality cannot be an afterthought."


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

Re: planning moose 4.7 and moving to Pharo 2.0

abergel
In reply to this post by Tudor Girba-2
Yes, I am interested in this!
However the tasks you mentions are highly time consuming...

Alexandre


On Oct 15, 2012, at 3:28 AM, Tudor Girba <[hidden email]> wrote:

> Hi,
>
> We have to think about releasing Moose 4.7 and moving to Pharo 2.0.
>
> There are several reasons why the move to 2.0 would make sense:
> 1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible.
> 2. The environment moved to RPackage entirely.
> 3. Pharo needs users.
>
> Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points:
> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone%3D4.7
>
> The most pressing ones are:
> Issue 799: Editing code in Glamour must be faster
> Issue 851: Create a stable version for Moose and all its subparts
> Issue 853: ConfigurationOfMoose should be split to reflect core vs suite
>
> Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker?
>
> My idea is to target a release this year. Input is more than welcome :)
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: planning moose 4.7 and moving to Pharo 2.0

Tudor Girba-2
Hi,

On 16 Oct 2012, at 00:12, Alexandre Bergel <[hidden email]> wrote:

> Yes, I am interested in this!

Thanks.

> However the tasks you mentions are highly time consuming...

So, what does that mean? :)

Here is a possible start: take MooseReloader and see if you can reproduce the current image:
http://www.smalltalkhub.com/#!/~StephaneDucasse/MooseReloader



Doru


> Alexandre
>
>
> On Oct 15, 2012, at 3:28 AM, Tudor Girba <[hidden email]> wrote:
>
>> Hi,
>>
>> We have to think about releasing Moose 4.7 and moving to Pharo 2.0.
>>
>> There are several reasons why the move to 2.0 would make sense:
>> 1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible.
>> 2. The environment moved to RPackage entirely.
>> 3. Pharo needs users.
>>
>> Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points:
>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone%3D4.7
>>
>> The most pressing ones are:
>> Issue 799: Editing code in Glamour must be faster
>> Issue 851: Create a stable version for Moose and all its subparts
>> Issue 853: ConfigurationOfMoose should be split to reflect core vs suite
>>
>> Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker?
>>
>> My idea is to target a release this year. Input is more than welcome :)
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>> _______________________________________________
>> 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

"Next time you see your life passing by, say 'hi' and get to know her."




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

Re: planning moose 4.7 and moving to Pharo 2.0

Nicolas Anquetil
In reply to this post by abergel
On 16/10/12 00:12, Alexandre Bergel wrote:
> Yes, I am interested in this!
> However the tasks you mentions are highly time consuming...
that's what I was about to say too, there are only 3 issues, but they
are not small well defined bug to solve, it's enhancement maintenance at
its best.Issue

799: Editing code in Glamour must be faster
Issue 851: Create a stable version for Moose and all its subparts Issue
853: ConfigurationOfMoose should be split to reflect core vs suite

Things that require potentially months of effort ... (in my limited
understanding  at least)
not something that you can tackle until the end of the year

I have been willing to push moosechef for more than a year I think :-(
I will try to put some effort there

nicolas

> Alexandre
>
>
> On Oct 15, 2012, at 3:28 AM, Tudor Girba <[hidden email]> wrote:
>
>> Hi,
>>
>> We have to think about releasing Moose 4.7 and moving to Pharo 2.0.
>>
>> There are several reasons why the move to 2.0 would make sense:
>> 1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible.
>> 2. The environment moved to RPackage entirely.
>> 3. Pharo needs users.
>>
>> Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points:
>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone%3D4.7
>>
>> The most pressing ones are:
>> Issue 799: Editing code in Glamour must be faster
>> Issue 851: Create a stable version for Moose and all its subparts
>> Issue 853: ConfigurationOfMoose should be split to reflect core vs suite
>>
>> Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker?
>>
>> My idea is to target a release this year. Input is more than welcome :)
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "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: planning moose 4.7 and moving to Pharo 2.0

Tudor Girba-2
Hi,

On Tue, Oct 16, 2012 at 9:58 AM, Nicolas Anquetil <[hidden email]> wrote:
On 16/10/12 00:12, Alexandre Bergel wrote:
Yes, I am interested in this!
However the tasks you mentions are highly time consuming...
that's what I was about to say too, there are only 3 issues, but they are not small well defined bug to solve, it's enhancement maintenance at its best.Issue


799: Editing code in Glamour must be faster
Issue 851: Create a stable version for Moose and all its subparts Issue
853: ConfigurationOfMoose should be split to reflect core vs suite

Things that require potentially months of effort ... (in my limited understanding  at least)
not something that you can tackle until the end of the year

I think there is a misunderstanding. These three are rather small tasks. My guess is that they entail some 3 days each.
 
I have been willing to push moosechef for more than a year I think :-(
I will try to put some effort there

Great. This is indeed a large and vague task. Let's synchronize around it and create detailed tasks. Could you propose a small set?
 
Cheers,
Doru



nicolas


Alexandre


On Oct 15, 2012, at 3:28 AM, Tudor Girba <[hidden email]> wrote:

Hi,

We have to think about releasing Moose 4.7 and moving to Pharo 2.0.

There are several reasons why the move to 2.0 would make sense:
1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible.
2. The environment moved to RPackage entirely.
3. Pharo needs users.

Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points:
http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone%3D4.7

The most pressing ones are:
Issue 799:      Editing code in Glamour must be faster
Issue 851:      Create a stable version for Moose and all its subparts
Issue 853:      ConfigurationOfMoose should be split to reflect core vs suite

Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker?

My idea is to target a release this year. Input is more than welcome :)

Cheers,
Doru

--
www.tudorgirba.com

"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



--

"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: planning moose 4.7 and moving to Pharo 2.0

abergel
In reply to this post by Tudor Girba-2
Hi!

I am not sure how I can load using Reloader. I've tried:

Reloader new
        repositoryClass: MooseConfigurationRepository;
        reload: 3

What exactly should I provide as argument to reload: ?
MooseConfigurationRepository defines script1, script2 and script3.
I though that providing 3 will load script3.

Cheers,
Alexandre



On Oct 16, 2012, at 3:05 AM, Tudor Girba <[hidden email]> wrote:

> Hi,
>
> On 16 Oct 2012, at 00:12, Alexandre Bergel <[hidden email]> wrote:
>
>> Yes, I am interested in this!
>
> Thanks.
>
>> However the tasks you mentions are highly time consuming...
>
> So, what does that mean? :)
>
> Here is a possible start: take MooseReloader and see if you can reproduce the current image:
> http://www.smalltalkhub.com/#!/~StephaneDucasse/MooseReloader
>
>
>
> Doru
>
>
>> Alexandre
>>
>>
>> On Oct 15, 2012, at 3:28 AM, Tudor Girba <[hidden email]> wrote:
>>
>>> Hi,
>>>
>>> We have to think about releasing Moose 4.7 and moving to Pharo 2.0.
>>>
>>> There are several reasons why the move to 2.0 would make sense:
>>> 1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible.
>>> 2. The environment moved to RPackage entirely.
>>> 3. Pharo needs users.
>>>
>>> Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points:
>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone%3D4.7
>>>
>>> The most pressing ones are:
>>> Issue 799: Editing code in Glamour must be faster
>>> Issue 851: Create a stable version for Moose and all its subparts
>>> Issue 853: ConfigurationOfMoose should be split to reflect core vs suite
>>>
>>> Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker?
>>>
>>> My idea is to target a release this year. Input is more than welcome :)
>>>
>>> Cheers,
>>> Doru
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>>
>>> _______________________________________________
>>> 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
>
> "Next time you see your life passing by, say 'hi' and get to know her."
>
>
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: planning moose 4.7 and moving to Pharo 2.0

Stéphane Ducasse
In reply to this post by Tudor Girba-2

On Oct 15, 2012, at 8:28 AM, Tudor Girba wrote:

> Hi,
>
> We have to think about releasing Moose 4.7 and moving to Pharo 2.0.
>
> There are several reasons why the move to 2.0 would make sense:
> 1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible.

I passed the mail to igor ;D
He is really pushing athens in this moment.

> 2. The environment moved to RPackage entirely.
> 3. Pharo needs users.

oh yes!
>
> Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points:
> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone%3D4.7
>
> The most pressing ones are:
> Issue 799: Editing code in Glamour must be faster
> Issue 851: Create a stable version for Moose and all its subparts

With reloader, you can get a list of pair
        repository * package versions
that you can reload in 1.4.

I tried it for synectique. If you want I can do it for Moose itself (Moose was included in the synectique try).

> Issue 853: ConfigurationOfMoose should be split to reflect core vs suite

What do you mean?
What would be good is to revisit the configurations.

>
> Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker?
>
> My idea is to target a release this year. Input is more than welcome :)
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "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: planning moose 4.7 and moving to Pharo 2.0

Stéphane Ducasse
In reply to this post by abergel
       
        first you take a Moose version
        and you snapshot it, it will create a new script in MooseConfiguration.

        then you version the MooseConfiguration

        then in a 1.4 image you reload reloader and ask reloader to use the MooseConfiguration and to reload the script you created.

Stef

PS: by the end of the week SmalltalkHub will up port private and projects so we will be able to move reloader there and avoid to fork it.
Alex create an account on smalltalkhub and I will give you write access to reloader.



> Hi!
>
> I am not sure how I can load using Reloader. I've tried:
>
> Reloader new
> repositoryClass: MooseConfigurationRepository;
> reload: 3
>
> What exactly should I provide as argument to reload: ?
> MooseConfigurationRepository defines script1, script2 and script3.
> I though that providing 3 will load script3.
>
> Cheers,
> Alexandre
>
>
>
> On Oct 16, 2012, at 3:05 AM, Tudor Girba <[hidden email]> wrote:
>
>> Hi,
>>
>> On 16 Oct 2012, at 00:12, Alexandre Bergel <[hidden email]> wrote:
>>
>>> Yes, I am interested in this!
>>
>> Thanks.
>>
>>> However the tasks you mentions are highly time consuming...
>>
>> So, what does that mean? :)
>>
>> Here is a possible start: take MooseReloader and see if you can reproduce the current image:
>> http://www.smalltalkhub.com/#!/~StephaneDucasse/MooseReloader
>>
>>
>>
>> Doru
>>
>>
>>> Alexandre
>>>
>>>
>>> On Oct 15, 2012, at 3:28 AM, Tudor Girba <[hidden email]> wrote:
>>>
>>>> Hi,
>>>>
>>>> We have to think about releasing Moose 4.7 and moving to Pharo 2.0.
>>>>
>>>> There are several reasons why the move to 2.0 would make sense:
>>>> 1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible.
>>>> 2. The environment moved to RPackage entirely.
>>>> 3. Pharo needs users.
>>>>
>>>> Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points:
>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone%3D4.7
>>>>
>>>> The most pressing ones are:
>>>> Issue 799: Editing code in Glamour must be faster
>>>> Issue 851: Create a stable version for Moose and all its subparts
>>>> Issue 853: ConfigurationOfMoose should be split to reflect core vs suite
>>>>
>>>> Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker?
>>>>
>>>> My idea is to target a release this year. Input is more than welcome :)
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Every thing has its own flow"
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> "Next time you see your life passing by, say 'hi' and get to know her."
>>
>>
>>
>>
>> _______________________________________________
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: planning moose 4.7 and moving to Pharo 2.0

Tudor Girba-2
Alex, could you try this?

Doru

On Tue, Oct 16, 2012 at 4:03 PM, Stéphane Ducasse <[hidden email]> wrote:

        first you take a Moose version
        and you snapshot it, it will create a new script in MooseConfiguration.

        then you version the MooseConfiguration

        then in a 1.4 image you reload reloader and ask reloader to use the MooseConfiguration and to reload the script you created.

Stef

PS: by the end of the week SmalltalkHub will up port private and projects so we will be able to move reloader there and avoid to fork it.
Alex create an account on smalltalkhub and I will give you write access to reloader.



> Hi!
>
> I am not sure how I can load using Reloader. I've tried:
>
> Reloader new
>       repositoryClass: MooseConfigurationRepository;
>       reload: 3
>
> What exactly should I provide as argument to reload: ?
> MooseConfigurationRepository defines script1, script2 and script3.
> I though that providing 3 will load script3.
>
> Cheers,
> Alexandre
>
>
>
> On Oct 16, 2012, at 3:05 AM, Tudor Girba <[hidden email]> wrote:
>
>> Hi,
>>
>> On 16 Oct 2012, at 00:12, Alexandre Bergel <[hidden email]> wrote:
>>
>>> Yes, I am interested in this!
>>
>> Thanks.
>>
>>> However the tasks you mentions are highly time consuming...
>>
>> So, what does that mean? :)
>>
>> Here is a possible start: take MooseReloader and see if you can reproduce the current image:
>> http://www.smalltalkhub.com/#!/~StephaneDucasse/MooseReloader
>>
>>
>>
>> Doru
>>
>>
>>> Alexandre
>>>
>>>
>>> On Oct 15, 2012, at 3:28 AM, Tudor Girba <[hidden email]> wrote:
>>>
>>>> Hi,
>>>>
>>>> We have to think about releasing Moose 4.7 and moving to Pharo 2.0.
>>>>
>>>> There are several reasons why the move to 2.0 would make sense:
>>>> 1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible.
>>>> 2. The environment moved to RPackage entirely.
>>>> 3. Pharo needs users.
>>>>
>>>> Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points:
>>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone%3D4.7
>>>>
>>>> The most pressing ones are:
>>>> Issue 799: Editing code in Glamour must be faster
>>>> Issue 851: Create a stable version for Moose and all its subparts
>>>> Issue 853: ConfigurationOfMoose should be split to reflect core vs suite
>>>>
>>>> Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker?
>>>>
>>>> My idea is to target a release this year. Input is more than welcome :)
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Every thing has its own flow"
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> "Next time you see your life passing by, say 'hi' and get to know her."
>>
>>
>>
>>
>> _______________________________________________
>> 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



--

"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: planning moose 4.7 and moving to Pharo 2.0

abergel
I will try yes...

Alexandre


On Oct 17, 2012, at 5:27 AM, Tudor Girba <[hidden email]> wrote:

> Alex, could you try this?
>
> Doru
>
> On Tue, Oct 16, 2012 at 4:03 PM, Stéphane Ducasse <[hidden email]> wrote:
>
>         first you take a Moose version
>         and you snapshot it, it will create a new script in MooseConfiguration.
>
>         then you version the MooseConfiguration
>
>         then in a 1.4 image you reload reloader and ask reloader to use the MooseConfiguration and to reload the script you created.
>
> Stef
>
> PS: by the end of the week SmalltalkHub will up port private and projects so we will be able to move reloader there and avoid to fork it.
> Alex create an account on smalltalkhub and I will give you write access to reloader.
>
>
>
> > Hi!
> >
> > I am not sure how I can load using Reloader. I've tried:
> >
> > Reloader new
> >       repositoryClass: MooseConfigurationRepository;
> >       reload: 3
> >
> > What exactly should I provide as argument to reload: ?
> > MooseConfigurationRepository defines script1, script2 and script3.
> > I though that providing 3 will load script3.
> >
> > Cheers,
> > Alexandre
> >
> >
> >
> > On Oct 16, 2012, at 3:05 AM, Tudor Girba <[hidden email]> wrote:
> >
> >> Hi,
> >>
> >> On 16 Oct 2012, at 00:12, Alexandre Bergel <[hidden email]> wrote:
> >>
> >>> Yes, I am interested in this!
> >>
> >> Thanks.
> >>
> >>> However the tasks you mentions are highly time consuming...
> >>
> >> So, what does that mean? :)
> >>
> >> Here is a possible start: take MooseReloader and see if you can reproduce the current image:
> >> http://www.smalltalkhub.com/#!/~StephaneDucasse/MooseReloader
> >>
> >>
> >>
> >> Doru
> >>
> >>
> >>> Alexandre
> >>>
> >>>
> >>> On Oct 15, 2012, at 3:28 AM, Tudor Girba <[hidden email]> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> We have to think about releasing Moose 4.7 and moving to Pharo 2.0.
> >>>>
> >>>> There are several reasons why the move to 2.0 would make sense:
> >>>> 1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible.
> >>>> 2. The environment moved to RPackage entirely.
> >>>> 3. Pharo needs users.
> >>>>
> >>>> Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points:
> >>>> http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone%3D4.7
> >>>>
> >>>> The most pressing ones are:
> >>>> Issue 799: Editing code in Glamour must be faster
> >>>> Issue 851: Create a stable version for Moose and all its subparts
> >>>> Issue 853: ConfigurationOfMoose should be split to reflect core vs suite
> >>>>
> >>>> Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker?
> >>>>
> >>>> My idea is to target a release this year. Input is more than welcome :)
> >>>>
> >>>> Cheers,
> >>>> Doru
> >>>>
> >>>> --
> >>>> www.tudorgirba.com
> >>>>
> >>>> "Every thing has its own flow"
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>
> >> "Next time you see your life passing by, say 'hi' and get to know her."
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
>
> "Every thing has its own flow"
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: planning moose 4.7 and moving to Pharo 2.0

Nicolas Anquetil
In reply to this post by Tudor Girba-2
On 16/10/12 11:22, Tudor Girba wrote:
I have been willing to push moosechef for more than a year I think :-(
I will try to put some effort there

Great. This is indeed a large and vague task. Let's synchronize around it and create detailed tasks. Could you propose a small set?
 
Cheers,
Doru

I spent a lot of time today trying to figure this out with Moose.
Kind of "eat your own dog food" experience.
But with no success (with Moose alone).


So I went for something less radical, here are some numbers:

1- find all method protocols implementing Cook or navigation methods

(FAMIXNamedEntity withAllSubclasses flatCollectAsSet: [:c | c protocols]) select: [:s | s beginsWith: '*Famix-Extensions']
-> 5
(FAMIXNamedEntity withAllSubclasses flatCollectAsSet: [:c | c protocols]) select: [:s | s beginsWith: '*famix-extensions']
-> 29

+ select manually the relevant ones
-> 20
cookProtocols := {
'*famix-extensions-nav Potential Incoming Invocations' .
'*famix-extensions-cook-Private' .
'*famix-extensions-cook-SureOutgoingInvocations' .
'*famix-extensions-nav All Dependencies' .
'*famix-extensions-nav Static Dependencies' .
'*famix-extensions-cook-StaticAccesses' .
'*famix-extensions-nav All Incoming Invocations' .
'*famix-extensions-nav Sure Outgoing Dependencies' .
'*famix-extensions-nav Potential Outgoing Invocations' .
'*famix-extensions-invocations' .
'*famix-extensions-nav Sure Incoming Invocations' .
'*famix-extensions-NavPrivate' .
'*famix-extensions-nav All Outgoing Invocations' .
'*famix-extensions-nav Inheritance' .
'*famix-extensions-Invocations' .
'*famix-extensions-cook-SureIncomingInvocations' .
'*famix-extensions-nav Sure Incoming Dependencies' .
'*famix-extensions-nav Static Accesses' .
'*famix-extensions-nav Sure Outgoing Invocations' .
'*Famix-Extensions-navigation' }


2- find all the methods in these protocols
cookSelector := (cookProtocols flatCollectAsSet: [:p | (Smalltalk allClasses gather: [:e | (e methodsInProtocol: p) collect: [:m | m selector]])]).
-> 191

these are the potential methods we want to replace by MooseChef queries


3- build a moose model with packages Moose-* and Famix-*

4- look for all FamixMethods with the name of a cookSelector (extracted above step 2)
cookSelectorInMoose := MooseModel root allModels first allMethods select: [:fm | cookSelector includes: fm name]
-> 344

5- find all invoking methods (ignoring the one in cookSelectorInMoose)
(cookSelectorInMoose flatCollectAsSet: [:m | m queryAllIncomingInvocations opposites]) reject: [:m | cookSelectorInMoose includes:  m]
-> 358


6- just for fun, check which of the cookSelector are actually called by these last ones
((invokingCook flatCollectAsSet: [:m | m queryAllOutgoingInvocations opposites]) select: [:m | cookSelectorInMoose includes: m]) collectAsSet: [:m | m name]
-> 141

so apparently 50 cookSelectors are never invoked outside of "Cook"


nicolas

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

Re: planning moose 4.7 and moving to Pharo 2.0

Tudor Girba-2
Interesting. Nice custom analysis.

The next thing would be to detect the projects that actually do use Cook. I suspect that the largest client is DSM. Could you try this one?

Cheers,
Doru


On 18 Oct 2012, at 20:34, Nicolas Anquetil <[hidden email]> wrote:

> On 16/10/12 11:22, Tudor Girba wrote:
>> I have been willing to push moosechef for more than a year I think :-(
>> I will try to put some effort there
>>
>> Great. This is indeed a large and vague task. Let's synchronize around it and create detailed tasks. Could you propose a small set?
>>  
>> Cheers,
>> Doru
>
> I spent a lot of time today trying to figure this out with Moose.
> Kind of "eat your own dog food" experience.
> But with no success (with Moose alone).
>
>
> So I went for something less radical, here are some numbers:
>
> 1- find all method protocols implementing Cook or navigation methods
>
> (FAMIXNamedEntity withAllSubclasses flatCollectAsSet: [:c | c protocols]) select: [:s | s beginsWith: '*Famix-Extensions']
> -> 5
> (FAMIXNamedEntity withAllSubclasses flatCollectAsSet: [:c | c protocols]) select: [:s | s beginsWith: '*famix-extensions']
> -> 29
>
> + select manually the relevant ones
> -> 20
> cookProtocols := {
> '*famix-extensions-nav Potential Incoming Invocations' .
> '*famix-extensions-cook-Private' .
> '*famix-extensions-cook-SureOutgoingInvocations' .
> '*famix-extensions-nav All Dependencies' .
> '*famix-extensions-nav Static Dependencies' .
> '*famix-extensions-cook-StaticAccesses' .
> '*famix-extensions-nav All Incoming Invocations' .
> '*famix-extensions-nav Sure Outgoing Dependencies' .
> '*famix-extensions-nav Potential Outgoing Invocations' .
> '*famix-extensions-invocations' .
> '*famix-extensions-nav Sure Incoming Invocations' .
> '*famix-extensions-NavPrivate' .
> '*famix-extensions-nav All Outgoing Invocations' .
> '*famix-extensions-nav Inheritance' .
> '*famix-extensions-Invocations' .
> '*famix-extensions-cook-SureIncomingInvocations' .
> '*famix-extensions-nav Sure Incoming Dependencies' .
> '*famix-extensions-nav Static Accesses' .
> '*famix-extensions-nav Sure Outgoing Invocations' .
> '*Famix-Extensions-navigation' }
>
>
> 2- find all the methods in these protocols
> cookSelector := (cookProtocols flatCollectAsSet: [:p | (Smalltalk allClasses gather: [:e | (e methodsInProtocol: p) collect: [:m | m selector]])]).
> -> 191
>
> these are the potential methods we want to replace by MooseChef queries
>
>
> 3- build a moose model with packages Moose-* and Famix-*
>
> 4- look for all FamixMethods with the name of a cookSelector (extracted above step 2)
> cookSelectorInMoose := MooseModel root allModels first allMethods select: [:fm | cookSelector includes: fm name]
> -> 344
>
> 5- find all invoking methods (ignoring the one in cookSelectorInMoose)
> (cookSelectorInMoose flatCollectAsSet: [:m | m queryAllIncomingInvocations opposites]) reject: [:m | cookSelectorInMoose includes:  m]
> -> 358
>
>
> 6- just for fun, check which of the cookSelector are actually called by these last ones
> ((invokingCook flatCollectAsSet: [:m | m queryAllOutgoingInvocations opposites]) select: [:m | cookSelectorInMoose includes: m])     collectAsSet: [:m | m name]
> -> 141
>
> so apparently 50 cookSelectors are never invoked outside of "Cook"
>
>
> nicolas
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."


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

Re: planning moose 4.7 and moving to Pharo 2.0

Stéphane Ducasse
In reply to this post by Nicolas Anquetil
excellent!
I love that attitude :)

Stef
On Oct 18, 2012, at 8:34 PM, Nicolas Anquetil wrote:

> On 16/10/12 11:22, Tudor Girba wrote:
>> I have been willing to push moosechef for more than a year I think :-(
>> I will try to put some effort there
>>
>> Great. This is indeed a large and vague task. Let's synchronize around it and create detailed tasks. Could you propose a small set?
>>  
>> Cheers,
>> Doru
>
> I spent a lot of time today trying to figure this out with Moose.
> Kind of "eat your own dog food" experience.
> But with no success (with Moose alone).
>
>
> So I went for something less radical, here are some numbers:
>
> 1- find all method protocols implementing Cook or navigation methods
>
> (FAMIXNamedEntity withAllSubclasses flatCollectAsSet: [:c | c protocols]) select: [:s | s beginsWith: '*Famix-Extensions']
> -> 5
> (FAMIXNamedEntity withAllSubclasses flatCollectAsSet: [:c | c protocols]) select: [:s | s beginsWith: '*famix-extensions']
> -> 29
>
> + select manually the relevant ones
> -> 20
> cookProtocols := {
> '*famix-extensions-nav Potential Incoming Invocations' .
> '*famix-extensions-cook-Private' .
> '*famix-extensions-cook-SureOutgoingInvocations' .
> '*famix-extensions-nav All Dependencies' .
> '*famix-extensions-nav Static Dependencies' .
> '*famix-extensions-cook-StaticAccesses' .
> '*famix-extensions-nav All Incoming Invocations' .
> '*famix-extensions-nav Sure Outgoing Dependencies' .
> '*famix-extensions-nav Potential Outgoing Invocations' .
> '*famix-extensions-invocations' .
> '*famix-extensions-nav Sure Incoming Invocations' .
> '*famix-extensions-NavPrivate' .
> '*famix-extensions-nav All Outgoing Invocations' .
> '*famix-extensions-nav Inheritance' .
> '*famix-extensions-Invocations' .
> '*famix-extensions-cook-SureIncomingInvocations' .
> '*famix-extensions-nav Sure Incoming Dependencies' .
> '*famix-extensions-nav Static Accesses' .
> '*famix-extensions-nav Sure Outgoing Invocations' .
> '*Famix-Extensions-navigation' }
>
>
> 2- find all the methods in these protocols
> cookSelector := (cookProtocols flatCollectAsSet: [:p | (Smalltalk allClasses gather: [:e | (e methodsInProtocol: p) collect: [:m | m selector]])]).
> -> 191
>
> these are the potential methods we want to replace by MooseChef queries
>
>
> 3- build a moose model with packages Moose-* and Famix-*
>
> 4- look for all FamixMethods with the name of a cookSelector (extracted above step 2)
> cookSelectorInMoose := MooseModel root allModels first allMethods select: [:fm | cookSelector includes: fm name]
> -> 344
>
> 5- find all invoking methods (ignoring the one in cookSelectorInMoose)
> (cookSelectorInMoose flatCollectAsSet: [:m | m queryAllIncomingInvocations opposites]) reject: [:m | cookSelectorInMoose includes:  m]
> -> 358
>
>
> 6- just for fun, check which of the cookSelector are actually called by these last ones
> ((invokingCook flatCollectAsSet: [:m | m queryAllOutgoingInvocations opposites]) select: [:m | cookSelectorInMoose includes: m]) collectAsSet: [:m | m name]
> -> 141
>
> so apparently 50 cookSelectors are never invoked outside of "Cook"
>
>
> nicolas
> _______________________________________________
> 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