planning moose 4.7 and moving to Pharo 2.0

> 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"
>

> 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
>
>
> 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

> 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

> 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

>
> 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

> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>

> 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

> 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

> 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