Hi,

On 16 Oct 2012, at 00:12, Alexandre Bergel alexandre.bergel@me.com 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 tudor@tudorgirba.com 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%...

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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

---

Moose-dev mailing list Moose-dev@iam.unibe.ch 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."

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 tudor@tudorgirba.com wrote:

...

Hi,

On 16 Oct 2012, at 00:12, Alexandre Bergel alexandre.bergel@me.com 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 tudor@tudorgirba.com 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%...

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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

---

Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

I will try yes...

Alexandre

On Oct 17, 2012, at 5:27 AM, Tudor Girba tudor@tudorgirba.com wrote:

Alex, could you try this?

Doru

On Tue, Oct 16, 2012 at 4:03 PM, Stéphane Ducasse stephane.ducasse@inria.fr 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 tudor@tudorgirba.com wrote:

...

Hi,

On 16 Oct 2012, at 00:12, Alexandre Bergel alexandre.bergel@me.com 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 tudor@tudorgirba.com 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%...

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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

---

Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com

"Every thing has its own flow"

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi,

On Tue, Oct 16, 2012 at 9:58 AM, Nicolas Anquetil <Nicolas.Anquetil@inria.fr

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 tudor@tudorgirba.com 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.7http://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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/**mailman/listinfo/moose-devhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev

______________________________**_________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/**mailman/listinfo/moose-devhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev

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 Nicolas.Anquetil@inria.fr 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 Moose-dev@iam.unibe.ch 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."