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(a)tudorgirba.com> wrote: -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Alex, could you try this? Doru On Tue, Oct 16, 2012 at 4:03 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr > > 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(a)tudorgirba.com> > > >> Hi, > >> > >> On 16 Oct 2012, at 00:12, Alexandre Bergel <alexandre.bergel(a)me.com> > >> > >>> 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(a)tudorgirba.com> >>> > >>>> 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(a)iam.unibe.ch > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev(a)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(a)iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- www.tudorgirba.com "Every thing has its own flow"

On 16/10/12 00:12, Alexandre Bergel wrote: 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

On 16/10/12 11:22, Tudor Girba wrote: 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

excellent! I love that attitude :) Stef On Oct 18, 2012, at 8:34 PM, Nicolas Anquetil wrote: