Begin forwarded message:
From: Lukas Renggli renggli@me.com Date: September 30, 2009 9:10:32 PM GMT+02:00 To: Stéphane Ducasse stephane.ducasse@inria.fr Cc: Simon Denier simon.denier@inria.fr Subject: Re: [Moose-dev] Re: MooseLoader load does not load Fame ?
Please try again. There was something messed up dependencies. I think it should be fixed with the latest Gofer.
It certainly is not an issue with Monticello itself. I am using Gofer also with some older projects on Squeak 3.9.1
Lukas
On Sep 30, 2009, at 21:08 , Stéphane Ducasse wrote:
I'm not sure that this is related to that.
Stef
Begin forwarded message:
From: Simon Denier Simon.Denier@inria.fr Date: September 30, 2009 4:36:40 PM GMT+02:00 To: Simon Denier Simon.Denier@inria.fr Cc: Related to the development of Moose and other related tools <moose-dev@iam.unibe.ch
, Lukas Renggli renggli@iam.unibe.ch
Subject: [Moose-dev] Re: MooseLoader load does not load Fame ? Reply-To: Related to the development of Moose and other related tools moose-dev@iam.unibe.ch
On 30 sept. 2009, at 16:13, Simon Denier wrote:
it could be related to last changes in gofer
confirmed: works with gofer 48, not anymore with gofer 49 (fast multi package). Now there is a MC fix in the PharoInbox related to this so I guess that latest versions of gofer do not work without this fix.
On 30 sept. 2009, at 16:02, Alexandre Bergel wrote:
Squeaksource is up again. I tried, and I have the same problem than Jannik. I used a the last pharo-dev image available on the net. I used a 4.2.1 VM.
Cheers, Alexandre
On 30 Sep 2009, at 08:57, Tudor Girba wrote:
Hmm,
I am using the 4.2.1 VM. I will try with the 4.2.2 later this evening.
Can anyone else reproduce the problem in the meantime?
Cheers, Doru
On 30 Sep 2009, at 14:53, Laval Jannik wrote:
> I use a clean pharoCore 462 and a clean pharoDev 451. > With the last VM (4.2.2) > > > > On Sep 30, 2009, at 14:38 , Tudor Girba wrote: > >> Hi Jannik, >> >> I again cannot reproduce this problem :). I just loaded >> without a problem in pharo1.0-10451-BETAdev09.09.3. >> >> In which Pharo version did you try to load MooseLoader? >> >> Doru >> >> >> On 30 Sep 2009, at 14:13, Laval Jannik wrote: >> >>> "MooseLoader load" does not work. >>> It makes a warning: >>> " >>> This package depends on the following classes: >>> FMImporter >>> FMPragmaProcessor >>> FM3PropertyDescription >>> FM3MetaDescription >>> FMDomainCodeGenerator >>> MOViewRenderer >>> You must resolve these dependencies before you will be able >>> to load these definitions: >>> FM3MetaDescription>>allComplexAttributes >>> FM3MetaDescription>>allPrimitiveAttributes >>> FM3MetaDescription>>complexAttributes >>> FM3MetaDescription>>primitiveAttributes >>> FM3PropertyDescription>>compiledMethod >>> FameGetterGenerator >>> FameGetterGenerator>>instvarNameFor: >>> FameGetterGenerator>>methodNameFor: >>> FameGetterGenerator>>oppositeNameFor: >>> FameGetterGenerator>>visitClass: >>> FameGetterGenerator>>visitDictionaryProperty: >>> FameGetterGenerator>>visitManyProperty: >>> FameGetterGenerator>>visitOneProperty: >>> FameGetterGenerator>>visitOppositeDictionaryProperty: >>> FameGetterGenerator>>visitOppositeManyProperty: >>> FameGetterGenerator>>visitOppositeOneProperty: >>> MOViewRenderer>>edgesDsm:from:to: >>> MSEImporter >>> MSEImporter>>endDocument >>> MSEPragmaProcessor >>> MSEPragmaProcessor>>processClass: >>> >>> >>> Select Proceed to continue, or close this window to cancel >>> the operation. >>> " >>> >>> So Fame is not loaded. >>> >>> Is there a bug in Flair/Gofer ? >>> >>> >>> >>> --- >>> Jannik Laval >>> PhD Student - Rmod Team - INRIA >>> Certified Project Management Associate (IPMA) >>> http://www.jannik-laval.eu >>> http://rmod.lille.inria.fr >>> --- >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Beauty is where we see it." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > --- > Jannik Laval > PhD Student - Rmod Team - INRIA > Certified Project Management Associate (IPMA) > http://www.jannik-laval.eu > http://rmod.lille.inria.fr > --- > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > 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 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
-- Simon
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli http://www.lukas-renggli.ch
Ok, I can now reproduce the problem and it is still there :(.
Cheers, Doru
On 30 Sep 2009, at 21:14, Stéphane Ducasse wrote:
Begin forwarded message:
From: Lukas Renggli renggli@me.com Date: September 30, 2009 9:10:32 PM GMT+02:00 To: Stéphane Ducasse stephane.ducasse@inria.fr Cc: Simon Denier simon.denier@inria.fr Subject: Re: [Moose-dev] Re: MooseLoader load does not load Fame ?
Please try again. There was something messed up dependencies. I think it should be fixed with the latest Gofer.
It certainly is not an issue with Monticello itself. I am using Gofer also with some older projects on Squeak 3.9.1
Lukas
On Sep 30, 2009, at 21:08 , Stéphane Ducasse wrote:
I'm not sure that this is related to that.
Stef
Begin forwarded message:
From: Simon Denier Simon.Denier@inria.fr Date: September 30, 2009 4:36:40 PM GMT+02:00 To: Simon Denier Simon.Denier@inria.fr Cc: Related to the development of Moose and other related tools <moose-dev@iam.unibe.ch
, Lukas Renggli renggli@iam.unibe.ch
Subject: [Moose-dev] Re: MooseLoader load does not load Fame ? Reply-To: Related to the development of Moose and other related tools moose-dev@iam.unibe.ch
On 30 sept. 2009, at 16:13, Simon Denier wrote:
it could be related to last changes in gofer
confirmed: works with gofer 48, not anymore with gofer 49 (fast multi package). Now there is a MC fix in the PharoInbox related to this so I guess that latest versions of gofer do not work without this fix.
On 30 sept. 2009, at 16:02, Alexandre Bergel wrote:
Squeaksource is up again. I tried, and I have the same problem than Jannik. I used a the last pharo-dev image available on the net. I used a 4.2.1 VM.
Cheers, Alexandre
On 30 Sep 2009, at 08:57, Tudor Girba wrote:
> Hmm, > > I am using the 4.2.1 VM. I will try with the 4.2.2 later this > evening. > > Can anyone else reproduce the problem in the meantime? > > Cheers, > Doru > > > On 30 Sep 2009, at 14:53, Laval Jannik wrote: > >> I use a clean pharoCore 462 and a clean pharoDev 451. >> With the last VM (4.2.2) >> >> >> >> On Sep 30, 2009, at 14:38 , Tudor Girba wrote: >> >>> Hi Jannik, >>> >>> I again cannot reproduce this problem :). I just loaded >>> without a problem in pharo1.0-10451-BETAdev09.09.3. >>> >>> In which Pharo version did you try to load MooseLoader? >>> >>> Doru >>> >>> >>> On 30 Sep 2009, at 14:13, Laval Jannik wrote: >>> >>>> "MooseLoader load" does not work. >>>> It makes a warning: >>>> " >>>> This package depends on the following classes: >>>> FMImporter >>>> FMPragmaProcessor >>>> FM3PropertyDescription >>>> FM3MetaDescription >>>> FMDomainCodeGenerator >>>> MOViewRenderer >>>> You must resolve these dependencies before you will be able >>>> to load these definitions: >>>> FM3MetaDescription>>allComplexAttributes >>>> FM3MetaDescription>>allPrimitiveAttributes >>>> FM3MetaDescription>>complexAttributes >>>> FM3MetaDescription>>primitiveAttributes >>>> FM3PropertyDescription>>compiledMethod >>>> FameGetterGenerator >>>> FameGetterGenerator>>instvarNameFor: >>>> FameGetterGenerator>>methodNameFor: >>>> FameGetterGenerator>>oppositeNameFor: >>>> FameGetterGenerator>>visitClass: >>>> FameGetterGenerator>>visitDictionaryProperty: >>>> FameGetterGenerator>>visitManyProperty: >>>> FameGetterGenerator>>visitOneProperty: >>>> FameGetterGenerator>>visitOppositeDictionaryProperty: >>>> FameGetterGenerator>>visitOppositeManyProperty: >>>> FameGetterGenerator>>visitOppositeOneProperty: >>>> MOViewRenderer>>edgesDsm:from:to: >>>> MSEImporter >>>> MSEImporter>>endDocument >>>> MSEPragmaProcessor >>>> MSEPragmaProcessor>>processClass: >>>> >>>> >>>> Select Proceed to continue, or close this window to cancel >>>> the operation. >>>> " >>>> >>>> So Fame is not loaded. >>>> >>>> Is there a bug in Flair/Gofer ? >>>> >>>> >>>> >>>> --- >>>> Jannik Laval >>>> PhD Student - Rmod Team - INRIA >>>> Certified Project Management Associate (IPMA) >>>> http://www.jannik-laval.eu >>>> http://rmod.lille.inria.fr >>>> --- >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Beauty is where we see it." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> --- >> Jannik Laval >> PhD Student - Rmod Team - INRIA >> Certified Project Management Associate (IPMA) >> http://www.jannik-laval.eu >> http://rmod.lille.inria.fr >> --- >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> 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 > 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
-- Simon
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli http://www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Can somebody tell me what the problem exactly is? I can reproduce it too, but I don't know the packages. Is a wrong dependency loaded? Is a dependency missing?
Where is FMImport located for example? Isn't it included in the following package list?
#('OB-Shout' 'Shout.3.15-damiencassou.73' 'Mondrian' 'MooseAlgos' 'MondrianPaintings' 'Nile-Base' 'Fame' 'Hashtable' 'CollectionExtensions' 'Moose-Core' 'Famix-Core' 'Famix-Implementation' 'Famix-Smalltalk-' 'Famix-Java' 'Famix-Extensions' 'Famix-File' 'Moose-Hismo' 'Famix-SourceAnchor' 'Moose-GenericImporter' 'Moose-SmalltalkImporter' 'Moose-SmalltalkImporterTests' 'Moose-MonticelloImporter' 'Glamour-Helpers' 'Glamour-Squeak' 'Glamour-Core' 'Glamour-Presentations' 'Glamour-Browsers' 'Glamour-Scripting' 'Glamour-Tests' 'Momo' 'Glamour-Morphic' 'Glamour-Examples' 'Announcements' 'OB-Shout' 'Shout.3.15-damiencassou.73' 'Mondrian' 'MooseAlgos' 'MondrianPaintings' 'Moose-Finder' 'Moose-LAN' 'Moose-ReferenceModel' 'Moose-Test-PackageOne' 'Moose-Test-PackageTwo' 'Famix-LANTests' 'Moose-ModelTest' 'Famix-Test' 'MooseKGB-TestFamix3' 'Moose-KGB-P4FullInteracted' 'Moose-KGB-P6InteractedReferee' 'Moose-KGB-P5FullReferee' 'Moose-KGB-P1FullReferencer' 'Moose-KGB-P2InteractedReferencerReferee' 'Moose-KGB-P3InteractedReferencer' 'Moose-KGB-P7ReferencerReferee' 'Moose-KGB-P8FullReferencer' 'Moose-KGB-P9FullReferencer' 'Moose-KGB-P10InteractedReferee' 'Moose-KGB-P11FullReferee' 'Moose-KGB-P12FullReferencer' 'Moose-KGB-P13FullReferencer' 'Moose-KGB-P14FullReferee' 'Moose-KGB-PExtensions' 'OB-Shout' 'Shout.3.15-damiencassou.73' 'Mondrian' 'MooseAlgos' 'MondrianPaintings' 'Moose-MondrianScripts' 'DSMAll')
Lukas
2009/10/1 Tudor Girba tudor.girba@gmail.com:
Ok, I can now reproduce the problem and it is still there :(.
Cheers, Doru
On 30 Sep 2009, at 21:14, Stéphane Ducasse wrote:
Begin forwarded message:
From: Lukas Renggli renggli@me.com Date: September 30, 2009 9:10:32 PM GMT+02:00 To: Stéphane Ducasse stephane.ducasse@inria.fr Cc: Simon Denier simon.denier@inria.fr Subject: Re: [Moose-dev] Re: MooseLoader load does not load Fame ?
Please try again. There was something messed up dependencies. I think it should be fixed with the latest Gofer.
It certainly is not an issue with Monticello itself. I am using Gofer also with some older projects on Squeak 3.9.1
Lukas
On Sep 30, 2009, at 21:08 , Stéphane Ducasse wrote:
I'm not sure that this is related to that.
Stef
Begin forwarded message:
From: Simon Denier Simon.Denier@inria.fr Date: September 30, 2009 4:36:40 PM GMT+02:00 To: Simon Denier Simon.Denier@inria.fr Cc: Related to the development of Moose and other related tools moose-dev@iam.unibe.ch, Lukas Renggli renggli@iam.unibe.ch Subject: [Moose-dev] Re: MooseLoader load does not load Fame ? Reply-To: Related to the development of Moose and other related tools moose-dev@iam.unibe.ch
On 30 sept. 2009, at 16:13, Simon Denier wrote:
it could be related to last changes in gofer
confirmed: works with gofer 48, not anymore with gofer 49 (fast multi package). Now there is a MC fix in the PharoInbox related to this so I guess that latest versions of gofer do not work without this fix.
On 30 sept. 2009, at 16:02, Alexandre Bergel wrote:
> Squeaksource is up again. I tried, and I have the same problem than > Jannik. I used a the last pharo-dev image available on the net. I used a > 4.2.1 VM. > > Cheers, > Alexandre > > On 30 Sep 2009, at 08:57, Tudor Girba wrote: > >> Hmm, >> >> I am using the 4.2.1 VM. I will try with the 4.2.2 later this >> evening. >> >> Can anyone else reproduce the problem in the meantime? >> >> Cheers, >> Doru >> >> >> On 30 Sep 2009, at 14:53, Laval Jannik wrote: >> >>> I use a clean pharoCore 462 and a clean pharoDev 451. >>> With the last VM (4.2.2) >>> >>> >>> >>> On Sep 30, 2009, at 14:38 , Tudor Girba wrote: >>> >>>> Hi Jannik, >>>> >>>> I again cannot reproduce this problem :). I just loaded without a >>>> problem in pharo1.0-10451-BETAdev09.09.3. >>>> >>>> In which Pharo version did you try to load MooseLoader? >>>> >>>> Doru >>>> >>>> >>>> On 30 Sep 2009, at 14:13, Laval Jannik wrote: >>>> >>>>> "MooseLoader load" does not work. >>>>> It makes a warning: >>>>> " >>>>> This package depends on the following classes: >>>>> FMImporter >>>>> FMPragmaProcessor >>>>> FM3PropertyDescription >>>>> FM3MetaDescription >>>>> FMDomainCodeGenerator >>>>> MOViewRenderer >>>>> You must resolve these dependencies before you will be able to >>>>> load these definitions: >>>>> FM3MetaDescription>>allComplexAttributes >>>>> FM3MetaDescription>>allPrimitiveAttributes >>>>> FM3MetaDescription>>complexAttributes >>>>> FM3MetaDescription>>primitiveAttributes >>>>> FM3PropertyDescription>>compiledMethod >>>>> FameGetterGenerator >>>>> FameGetterGenerator>>instvarNameFor: >>>>> FameGetterGenerator>>methodNameFor: >>>>> FameGetterGenerator>>oppositeNameFor: >>>>> FameGetterGenerator>>visitClass: >>>>> FameGetterGenerator>>visitDictionaryProperty: >>>>> FameGetterGenerator>>visitManyProperty: >>>>> FameGetterGenerator>>visitOneProperty: >>>>> FameGetterGenerator>>visitOppositeDictionaryProperty: >>>>> FameGetterGenerator>>visitOppositeManyProperty: >>>>> FameGetterGenerator>>visitOppositeOneProperty: >>>>> MOViewRenderer>>edgesDsm:from:to: >>>>> MSEImporter >>>>> MSEImporter>>endDocument >>>>> MSEPragmaProcessor >>>>> MSEPragmaProcessor>>processClass: >>>>> >>>>> >>>>> Select Proceed to continue, or close this window to cancel the >>>>> operation. >>>>> " >>>>> >>>>> So Fame is not loaded. >>>>> >>>>> Is there a bug in Flair/Gofer ? >>>>> >>>>> >>>>> >>>>> --- >>>>> Jannik Laval >>>>> PhD Student - Rmod Team - INRIA >>>>> Certified Project Management Associate (IPMA) >>>>> http://www.jannik-laval.eu >>>>> http://rmod.lille.inria.fr >>>>> --- >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Beauty is where we see it." >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> --- >>> Jannik Laval >>> PhD Student - Rmod Team - INRIA >>> Certified Project Management Associate (IPMA) >>> http://www.jannik-laval.eu >>> http://rmod.lille.inria.fr >>> --- >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> 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 >> 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
-- Simon
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli http://www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
These are the actual versions that Gofer tries to load. Is there anything obvious wrong there?
#('OB-Shout-cwp.2.mcz' 'Shout.3.15-damiencassou.73.mcz' 'MondrianPaintings-tg.16.mcz' 'MooseAlgos-simon_denier.1.mcz' 'MondrianPaintings-tg.16.mcz' 'Nile-Base-cyrille_delaunay.76.mcz' 'FameUtil-akuhn.5.mcz' 'Hashtable-pmm.30.mcz' 'CollectionExtensions-simon_denier.14.mcz' 'Moose-Core-simon_denier.166.mcz' 'Famix-Core-simon_denier.94.mcz' 'Famix-Implementation-simon_denier.49.mcz' 'Famix-Smalltalk-tg.32.mcz' 'Famix-Java-tg.6.mcz' 'Famix-Extensions-tg.63.mcz' 'Famix-File-tg.17.mcz' 'Moose-Hismo-simon_denier.24.mcz' 'Famix-SourceAnchor-simon_denier.13.mcz' 'Moose-GenericImporter-jannik_laval.28.mcz' 'Moose-SmalltalkImporterTests-tg.5.mcz' 'Moose-SmalltalkImporterTests-tg.5.mcz' 'Moose-MonticelloImporter-simon_denier.10.mcz' 'Glamour-Helpers-tg.11.mcz' 'Glamour-Squeak-tg.7.mcz' 'Glamour-Core-tg.38.mcz' 'Glamour-Presentations-tg.33.mcz' 'Glamour-Browsers-tg.11.mcz' 'Glamour-Scripting-tg.31.mcz' 'Glamour-Tests-tg.32.mcz' 'Momo-alain_plantec.6.mcz' 'Glamour-Morphic-tg.134.mcz' 'Glamour-Examples-tg.49.mcz' 'Announcements-tg.11.mcz' 'OB-Shout-cwp.2.mcz' 'Shout.3.15-damiencassou.73.mcz' 'MondrianPaintings-tg.16.mcz' 'MooseAlgos-simon_denier.1.mcz' 'MondrianPaintings-tg.16.mcz' 'Moose-Finder-tg.83.mcz' 'Moose-LANTests-pv.7.mcz' 'Moose-ReferenceModel-stephane_ducasse.ducasse.15.mcz' 'Moose-Test-PackageOne-stephane.ducasse.2.mcz' 'Moose-Test-PackageTwo-simon_denier.ducasse.3.mcz' 'Famix-LANTests-tg.26.mcz' 'Moose-ModelTest-tg.40.mcz' 'Famix-Test-tg.6.mcz' 'MooseKGB-TestFamix3-tg.14.mcz' 'Moose-KGB-P4FullInteracted-jannik_laval.1.mcz' 'Moose-KGB-P6InteractedReferee-jannik_laval.1.mcz' 'Moose-KGB-P5FullReferee-jannik_laval.1.mcz' 'Moose-KGB-P1FullReferencer-jannik_laval.1.mcz' 'Moose-KGB-P2InteractedReferencerReferee-jannik_laval.1.mcz' 'Moose-KGB-P3InteractedReferencer-jannik_laval.1.mcz' 'Moose-KGB-P7ReferencerReferee-jannik_laval.1.mcz' 'Moose-KGB-P8FullReferencer-jannik_laval.1.mcz' 'Moose-KGB-P9FullReferencer-jannik_laval.1.mcz' 'Moose-KGB-P10InteractedReferee-jannik_laval.1.mcz' 'Moose-KGB-P11FullReferee-jannik_laval.1.mcz' 'Moose-KGB-P12FullReferencer-jannik_laval.1.mcz' 'Moose-KGB-P13FullReferencer-jannik_laval.1.mcz' 'Moose-KGB-P14FullReferee-jannik_laval.1.mcz' 'Moose-KGB-PExtensions-jannik_laval.1.mcz' 'OB-Shout-cwp.2.mcz' 'Shout.3.15-damiencassou.73.mcz' 'MondrianPaintings-tg.16.mcz' 'MooseAlgos-simon_denier.1.mcz' 'MondrianPaintings-tg.16.mcz' 'Moose-MondrianScripts-tg.50.mcz' 'DSMAll-jannik_laval.77.mcz')
2009/10/1 Lukas Renggli renggli@gmail.com:
Can somebody tell me what the problem exactly is? I can reproduce it too, but I don't know the packages. Is a wrong dependency loaded? Is a dependency missing?
Where is FMImport located for example? Isn't it included in the following package list?
#('OB-Shout' 'Shout.3.15-damiencassou.73' 'Mondrian' 'MooseAlgos' 'MondrianPaintings' 'Nile-Base' 'Fame' 'Hashtable' 'CollectionExtensions' 'Moose-Core' 'Famix-Core' 'Famix-Implementation' 'Famix-Smalltalk-' 'Famix-Java' 'Famix-Extensions' 'Famix-File' 'Moose-Hismo' 'Famix-SourceAnchor' 'Moose-GenericImporter' 'Moose-SmalltalkImporter' 'Moose-SmalltalkImporterTests' 'Moose-MonticelloImporter' 'Glamour-Helpers' 'Glamour-Squeak' 'Glamour-Core' 'Glamour-Presentations' 'Glamour-Browsers' 'Glamour-Scripting' 'Glamour-Tests' 'Momo' 'Glamour-Morphic' 'Glamour-Examples' 'Announcements' 'OB-Shout' 'Shout.3.15-damiencassou.73' 'Mondrian' 'MooseAlgos' 'MondrianPaintings' 'Moose-Finder' 'Moose-LAN' 'Moose-ReferenceModel' 'Moose-Test-PackageOne' 'Moose-Test-PackageTwo' 'Famix-LANTests' 'Moose-ModelTest' 'Famix-Test' 'MooseKGB-TestFamix3' 'Moose-KGB-P4FullInteracted' 'Moose-KGB-P6InteractedReferee' 'Moose-KGB-P5FullReferee' 'Moose-KGB-P1FullReferencer' 'Moose-KGB-P2InteractedReferencerReferee' 'Moose-KGB-P3InteractedReferencer' 'Moose-KGB-P7ReferencerReferee' 'Moose-KGB-P8FullReferencer' 'Moose-KGB-P9FullReferencer' 'Moose-KGB-P10InteractedReferee' 'Moose-KGB-P11FullReferee' 'Moose-KGB-P12FullReferencer' 'Moose-KGB-P13FullReferencer' 'Moose-KGB-P14FullReferee' 'Moose-KGB-PExtensions' 'OB-Shout' 'Shout.3.15-damiencassou.73' 'Mondrian' 'MooseAlgos' 'MondrianPaintings' 'Moose-MondrianScripts' 'DSMAll')
Lukas
2009/10/1 Tudor Girba tudor.girba@gmail.com:
Ok, I can now reproduce the problem and it is still there :(.
Cheers, Doru
On 30 Sep 2009, at 21:14, Stéphane Ducasse wrote:
Begin forwarded message:
From: Lukas Renggli renggli@me.com Date: September 30, 2009 9:10:32 PM GMT+02:00 To: Stéphane Ducasse stephane.ducasse@inria.fr Cc: Simon Denier simon.denier@inria.fr Subject: Re: [Moose-dev] Re: MooseLoader load does not load Fame ?
Please try again. There was something messed up dependencies. I think it should be fixed with the latest Gofer.
It certainly is not an issue with Monticello itself. I am using Gofer also with some older projects on Squeak 3.9.1
Lukas
On Sep 30, 2009, at 21:08 , Stéphane Ducasse wrote:
I'm not sure that this is related to that.
Stef
Begin forwarded message:
From: Simon Denier Simon.Denier@inria.fr Date: September 30, 2009 4:36:40 PM GMT+02:00 To: Simon Denier Simon.Denier@inria.fr Cc: Related to the development of Moose and other related tools moose-dev@iam.unibe.ch, Lukas Renggli renggli@iam.unibe.ch Subject: [Moose-dev] Re: MooseLoader load does not load Fame ? Reply-To: Related to the development of Moose and other related tools moose-dev@iam.unibe.ch
On 30 sept. 2009, at 16:13, Simon Denier wrote:
> > it could be related to last changes in gofer
confirmed: works with gofer 48, not anymore with gofer 49 (fast multi package). Now there is a MC fix in the PharoInbox related to this so I guess that latest versions of gofer do not work without this fix.
> > > On 30 sept. 2009, at 16:02, Alexandre Bergel wrote: > >> Squeaksource is up again. I tried, and I have the same problem than >> Jannik. I used a the last pharo-dev image available on the net. I used a >> 4.2.1 VM. >> >> Cheers, >> Alexandre >> >> On 30 Sep 2009, at 08:57, Tudor Girba wrote: >> >>> Hmm, >>> >>> I am using the 4.2.1 VM. I will try with the 4.2.2 later this >>> evening. >>> >>> Can anyone else reproduce the problem in the meantime? >>> >>> Cheers, >>> Doru >>> >>> >>> On 30 Sep 2009, at 14:53, Laval Jannik wrote: >>> >>>> I use a clean pharoCore 462 and a clean pharoDev 451. >>>> With the last VM (4.2.2) >>>> >>>> >>>> >>>> On Sep 30, 2009, at 14:38 , Tudor Girba wrote: >>>> >>>>> Hi Jannik, >>>>> >>>>> I again cannot reproduce this problem :). I just loaded without a >>>>> problem in pharo1.0-10451-BETAdev09.09.3. >>>>> >>>>> In which Pharo version did you try to load MooseLoader? >>>>> >>>>> Doru >>>>> >>>>> >>>>> On 30 Sep 2009, at 14:13, Laval Jannik wrote: >>>>> >>>>>> "MooseLoader load" does not work. >>>>>> It makes a warning: >>>>>> " >>>>>> This package depends on the following classes: >>>>>> FMImporter >>>>>> FMPragmaProcessor >>>>>> FM3PropertyDescription >>>>>> FM3MetaDescription >>>>>> FMDomainCodeGenerator >>>>>> MOViewRenderer >>>>>> You must resolve these dependencies before you will be able to >>>>>> load these definitions: >>>>>> FM3MetaDescription>>allComplexAttributes >>>>>> FM3MetaDescription>>allPrimitiveAttributes >>>>>> FM3MetaDescription>>complexAttributes >>>>>> FM3MetaDescription>>primitiveAttributes >>>>>> FM3PropertyDescription>>compiledMethod >>>>>> FameGetterGenerator >>>>>> FameGetterGenerator>>instvarNameFor: >>>>>> FameGetterGenerator>>methodNameFor: >>>>>> FameGetterGenerator>>oppositeNameFor: >>>>>> FameGetterGenerator>>visitClass: >>>>>> FameGetterGenerator>>visitDictionaryProperty: >>>>>> FameGetterGenerator>>visitManyProperty: >>>>>> FameGetterGenerator>>visitOneProperty: >>>>>> FameGetterGenerator>>visitOppositeDictionaryProperty: >>>>>> FameGetterGenerator>>visitOppositeManyProperty: >>>>>> FameGetterGenerator>>visitOppositeOneProperty: >>>>>> MOViewRenderer>>edgesDsm:from:to: >>>>>> MSEImporter >>>>>> MSEImporter>>endDocument >>>>>> MSEPragmaProcessor >>>>>> MSEPragmaProcessor>>processClass: >>>>>> >>>>>> >>>>>> Select Proceed to continue, or close this window to cancel the >>>>>> operation. >>>>>> " >>>>>> >>>>>> So Fame is not loaded. >>>>>> >>>>>> Is there a bug in Flair/Gofer ? >>>>>> >>>>>> >>>>>> >>>>>> --- >>>>>> Jannik Laval >>>>>> PhD Student - Rmod Team - INRIA >>>>>> Certified Project Management Associate (IPMA) >>>>>> http://www.jannik-laval.eu >>>>>> http://rmod.lille.inria.fr >>>>>> --- >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev@iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Beauty is where we see it." >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> --- >>>> Jannik Laval >>>> PhD Student - Rmod Team - INRIA >>>> Certified Project Management Associate (IPMA) >>>> http://www.jannik-laval.eu >>>> http://rmod.lille.inria.fr >>>> --- >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch >>>> 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 >>> 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 > > -- > Simon > > >
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli http://www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli http://www.lukas-renggli.ch
Hi Lukas,
The problem is caused be the failure to load Fame.
In the list of packages you have 'Fame', but in the list of what Gofer tries to load there isn't any Fame.
Thanks for looking into this, Doru
On 1 Oct 2009, at 09:02, Lukas Renggli wrote:
These are the actual versions that Gofer tries to load. Is there anything obvious wrong there?
#('OB-Shout-cwp.2.mcz' 'Shout.3.15-damiencassou.73.mcz' 'MondrianPaintings-tg.16.mcz' 'MooseAlgos-simon_denier.1.mcz' 'MondrianPaintings-tg.16.mcz' 'Nile-Base-cyrille_delaunay.76.mcz' 'FameUtil-akuhn.5.mcz' 'Hashtable-pmm.30.mcz' 'CollectionExtensions-simon_denier.14.mcz' 'Moose-Core-simon_denier.166.mcz' 'Famix-Core-simon_denier.94.mcz' 'Famix-Implementation-simon_denier.49.mcz' 'Famix-Smalltalk-tg.32.mcz' 'Famix-Java-tg.6.mcz' 'Famix-Extensions-tg.63.mcz' 'Famix-File-tg.17.mcz' 'Moose-Hismo-simon_denier.24.mcz' 'Famix-SourceAnchor-simon_denier.13.mcz' 'Moose-GenericImporter-jannik_laval.28.mcz' 'Moose-SmalltalkImporterTests-tg.5.mcz' 'Moose-SmalltalkImporterTests-tg.5.mcz' 'Moose-MonticelloImporter-simon_denier.10.mcz' 'Glamour-Helpers-tg.11.mcz' 'Glamour-Squeak-tg.7.mcz' 'Glamour-Core-tg.38.mcz' 'Glamour-Presentations-tg.33.mcz' 'Glamour-Browsers-tg.11.mcz' 'Glamour-Scripting-tg.31.mcz' 'Glamour-Tests-tg.32.mcz' 'Momo-alain_plantec.6.mcz' 'Glamour-Morphic-tg.134.mcz' 'Glamour-Examples-tg.49.mcz' 'Announcements-tg.11.mcz' 'OB-Shout-cwp.2.mcz' 'Shout.3.15-damiencassou.73.mcz' 'MondrianPaintings-tg.16.mcz' 'MooseAlgos-simon_denier.1.mcz' 'MondrianPaintings-tg.16.mcz' 'Moose-Finder-tg.83.mcz' 'Moose-LANTests-pv.7.mcz' 'Moose-ReferenceModel-stephane_ducasse.ducasse.15.mcz' 'Moose-Test-PackageOne-stephane.ducasse.2.mcz' 'Moose-Test-PackageTwo-simon_denier.ducasse.3.mcz' 'Famix-LANTests-tg.26.mcz' 'Moose-ModelTest-tg.40.mcz' 'Famix-Test-tg.6.mcz' 'MooseKGB-TestFamix3-tg.14.mcz' 'Moose-KGB-P4FullInteracted-jannik_laval.1.mcz' 'Moose-KGB-P6InteractedReferee-jannik_laval.1.mcz' 'Moose-KGB-P5FullReferee-jannik_laval.1.mcz' 'Moose-KGB-P1FullReferencer-jannik_laval.1.mcz' 'Moose-KGB-P2InteractedReferencerReferee-jannik_laval.1.mcz' 'Moose-KGB-P3InteractedReferencer-jannik_laval.1.mcz' 'Moose-KGB-P7ReferencerReferee-jannik_laval.1.mcz' 'Moose-KGB-P8FullReferencer-jannik_laval.1.mcz' 'Moose-KGB-P9FullReferencer-jannik_laval.1.mcz' 'Moose-KGB-P10InteractedReferee-jannik_laval.1.mcz' 'Moose-KGB-P11FullReferee-jannik_laval.1.mcz' 'Moose-KGB-P12FullReferencer-jannik_laval.1.mcz' 'Moose-KGB-P13FullReferencer-jannik_laval.1.mcz' 'Moose-KGB-P14FullReferee-jannik_laval.1.mcz' 'Moose-KGB-PExtensions-jannik_laval.1.mcz' 'OB-Shout-cwp.2.mcz' 'Shout.3.15-damiencassou.73.mcz' 'MondrianPaintings-tg.16.mcz' 'MooseAlgos-simon_denier.1.mcz' 'MondrianPaintings-tg.16.mcz' 'Moose-MondrianScripts-tg.50.mcz' 'DSMAll-jannik_laval.77.mcz')
2009/10/1 Lukas Renggli renggli@gmail.com:
Can somebody tell me what the problem exactly is? I can reproduce it too, but I don't know the packages. Is a wrong dependency loaded? Is a dependency missing?
Where is FMImport located for example? Isn't it included in the following package list?
#('OB-Shout' 'Shout.3.15-damiencassou.73' 'Mondrian' 'MooseAlgos' 'MondrianPaintings' 'Nile-Base' 'Fame' 'Hashtable' 'CollectionExtensions' 'Moose-Core' 'Famix-Core' 'Famix-Implementation' 'Famix-Smalltalk-' 'Famix-Java' 'Famix-Extensions' 'Famix-File' 'Moose-Hismo' 'Famix-SourceAnchor' 'Moose-GenericImporter' 'Moose-SmalltalkImporter' 'Moose-SmalltalkImporterTests' 'Moose-MonticelloImporter' 'Glamour-Helpers' 'Glamour-Squeak' 'Glamour-Core' 'Glamour-Presentations' 'Glamour-Browsers' 'Glamour-Scripting' 'Glamour-Tests' 'Momo' 'Glamour-Morphic' 'Glamour-Examples' 'Announcements' 'OB-Shout' 'Shout.3.15-damiencassou.73' 'Mondrian' 'MooseAlgos' 'MondrianPaintings' 'Moose-Finder' 'Moose-LAN' 'Moose-ReferenceModel' 'Moose-Test-PackageOne' 'Moose-Test- PackageTwo' 'Famix-LANTests' 'Moose-ModelTest' 'Famix-Test' 'MooseKGB-TestFamix3' 'Moose-KGB-P4FullInteracted' 'Moose-KGB-P6InteractedReferee' 'Moose-KGB-P5FullReferee' 'Moose-KGB-P1FullReferencer' 'Moose-KGB-P2InteractedReferencerReferee' 'Moose-KGB-P3InteractedReferencer' 'Moose-KGB-P7ReferencerReferee' 'Moose-KGB-P8FullReferencer' 'Moose-KGB-P9FullReferencer' 'Moose-KGB-P10InteractedReferee' 'Moose-KGB-P11FullReferee' 'Moose-KGB-P12FullReferencer' 'Moose-KGB-P13FullReferencer' 'Moose-KGB-P14FullReferee' 'Moose-KGB-PExtensions' 'OB-Shout' 'Shout.3.15-damiencassou.73' 'Mondrian' 'MooseAlgos' 'MondrianPaintings' 'Moose-MondrianScripts' 'DSMAll')
Lukas
2009/10/1 Tudor Girba tudor.girba@gmail.com:
Ok, I can now reproduce the problem and it is still there :(.
Cheers, Doru
On 30 Sep 2009, at 21:14, Stéphane Ducasse wrote:
Begin forwarded message:
From: Lukas Renggli renggli@me.com Date: September 30, 2009 9:10:32 PM GMT+02:00 To: Stéphane Ducasse stephane.ducasse@inria.fr Cc: Simon Denier simon.denier@inria.fr Subject: Re: [Moose-dev] Re: MooseLoader load does not load Fame ?
Please try again. There was something messed up dependencies. I think it should be fixed with the latest Gofer.
It certainly is not an issue with Monticello itself. I am using Gofer also with some older projects on Squeak 3.9.1
Lukas
On Sep 30, 2009, at 21:08 , Stéphane Ducasse wrote:
I'm not sure that this is related to that.
Stef
Begin forwarded message:
> From: Simon Denier Simon.Denier@inria.fr > Date: September 30, 2009 4:36:40 PM GMT+02:00 > To: Simon Denier Simon.Denier@inria.fr > Cc: Related to the development of Moose and other related tools > moose-dev@iam.unibe.ch, Lukas Renggli renggli@iam.unibe.ch > Subject: [Moose-dev] Re: MooseLoader load does not load Fame ? > Reply-To: Related to the development of Moose and other > related tools > moose-dev@iam.unibe.ch > > > On 30 sept. 2009, at 16:13, Simon Denier wrote: > >> >> it could be related to last changes in gofer > > confirmed: works with gofer 48, not anymore with gofer 49 > (fast multi > package). Now there is a MC fix in the PharoInbox related to > this so I guess > that latest versions of gofer do not work without this fix. > >> >> >> On 30 sept. 2009, at 16:02, Alexandre Bergel wrote: >> >>> Squeaksource is up again. I tried, and I have the same >>> problem than >>> Jannik. I used a the last pharo-dev image available on the >>> net. I used a >>> 4.2.1 VM. >>> >>> Cheers, >>> Alexandre >>> >>> On 30 Sep 2009, at 08:57, Tudor Girba wrote: >>> >>>> Hmm, >>>> >>>> I am using the 4.2.1 VM. I will try with the 4.2.2 later this >>>> evening. >>>> >>>> Can anyone else reproduce the problem in the meantime? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 30 Sep 2009, at 14:53, Laval Jannik wrote: >>>> >>>>> I use a clean pharoCore 462 and a clean pharoDev 451. >>>>> With the last VM (4.2.2) >>>>> >>>>> >>>>> >>>>> On Sep 30, 2009, at 14:38 , Tudor Girba wrote: >>>>> >>>>>> Hi Jannik, >>>>>> >>>>>> I again cannot reproduce this problem :). I just loaded >>>>>> without a >>>>>> problem in pharo1.0-10451-BETAdev09.09.3. >>>>>> >>>>>> In which Pharo version did you try to load MooseLoader? >>>>>> >>>>>> Doru >>>>>> >>>>>> >>>>>> On 30 Sep 2009, at 14:13, Laval Jannik wrote: >>>>>> >>>>>>> "MooseLoader load" does not work. >>>>>>> It makes a warning: >>>>>>> " >>>>>>> This package depends on the following classes: >>>>>>> FMImporter >>>>>>> FMPragmaProcessor >>>>>>> FM3PropertyDescription >>>>>>> FM3MetaDescription >>>>>>> FMDomainCodeGenerator >>>>>>> MOViewRenderer >>>>>>> You must resolve these dependencies before you will be >>>>>>> able to >>>>>>> load these definitions: >>>>>>> FM3MetaDescription>>allComplexAttributes >>>>>>> FM3MetaDescription>>allPrimitiveAttributes >>>>>>> FM3MetaDescription>>complexAttributes >>>>>>> FM3MetaDescription>>primitiveAttributes >>>>>>> FM3PropertyDescription>>compiledMethod >>>>>>> FameGetterGenerator >>>>>>> FameGetterGenerator>>instvarNameFor: >>>>>>> FameGetterGenerator>>methodNameFor: >>>>>>> FameGetterGenerator>>oppositeNameFor: >>>>>>> FameGetterGenerator>>visitClass: >>>>>>> FameGetterGenerator>>visitDictionaryProperty: >>>>>>> FameGetterGenerator>>visitManyProperty: >>>>>>> FameGetterGenerator>>visitOneProperty: >>>>>>> FameGetterGenerator>>visitOppositeDictionaryProperty: >>>>>>> FameGetterGenerator>>visitOppositeManyProperty: >>>>>>> FameGetterGenerator>>visitOppositeOneProperty: >>>>>>> MOViewRenderer>>edgesDsm:from:to: >>>>>>> MSEImporter >>>>>>> MSEImporter>>endDocument >>>>>>> MSEPragmaProcessor >>>>>>> MSEPragmaProcessor>>processClass: >>>>>>> >>>>>>> >>>>>>> Select Proceed to continue, or close this window to >>>>>>> cancel the >>>>>>> operation. >>>>>>> " >>>>>>> >>>>>>> So Fame is not loaded. >>>>>>> >>>>>>> Is there a bug in Flair/Gofer ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> --- >>>>>>> Jannik Laval >>>>>>> PhD Student - Rmod Team - INRIA >>>>>>> Certified Project Management Associate (IPMA) >>>>>>> http://www.jannik-laval.eu >>>>>>> http://rmod.lille.inria.fr >>>>>>> --- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev@iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Beauty is where we see it." >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev@iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> --- >>>>> Jannik Laval >>>>> PhD Student - Rmod Team - INRIA >>>>> Certified Project Management Associate (IPMA) >>>>> http://www.jannik-laval.eu >>>>> http://rmod.lille.inria.fr >>>>> --- >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev@iam.unibe.ch >>>>> 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 >>>> 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 >> >> -- >> Simon >> >> >> > > -- > Simon > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli http://www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli http://www.lukas-renggli.ch
-- Lukas Renggli http://www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
The problem is caused be the failure to load Fame.
Ok, now I understand. This is your fault, because you have overlapping package names.
If you give the prefix 'Fame' then any of the packages 'Fame', 'FameLabs' and 'FameUtil' is picked at random. Previously it only has worked by chance, as the sorting was implemented slightly different (I sorted the complete repository, not just the versions in question).
The latest version of Gofer should fix the problem. I added another hack to the algorithm figuring out the version to load. If there are exact package matches, the prefix matches are removed. That solves this problem, and I hope it does not introduce new ones. In any case you should consider renaming/removing these Fame packages, because they are not cleanly loadable anyway.
Lukas
On 1 oct. 2009, at 09:40, Lukas Renggli wrote:
The problem is caused be the failure to load Fame.
Ok, now I understand. This is your fault, because you have overlapping package names.
OK I see, then we will have more problem with Mondrian (Mondrian / MondrianPaintings).
Repackaging Moose is envisaged, but it's not gonna be very easy. By the way, I tried the 'rename package' refactoring and it didnt quite work as expected: it creates a new package with the name, but classes (and class extensions) remain in the old package. Also it does some tricks in Monticello so that the new package seems to appear as a version with ancestors (it seems a bit magic to me, but perhaps MC supports package renaming)
If you give the prefix 'Fame' then any of the packages 'Fame', 'FameLabs' and 'FameUtil' is picked at random. Previously it only has worked by chance, as the sorting was implemented slightly different (I sorted the complete repository, not just the versions in question).
The latest version of Gofer should fix the problem. I added another hack to the algorithm figuring out the version to load. If there are exact package matches, the prefix matches are removed. That solves this problem, and I hope it does not introduce new ones. In any case you should consider renaming/removing these Fame packages, because they are not cleanly loadable anyway.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Repackaging Moose is envisaged, but it's not gonna be very easy. By the way, I tried the 'rename package' refactoring and it didnt quite work as expected: it creates a new package with the name, but classes (and class extensions) remain in the old package. Also it does some tricks in Monticello so that the new package seems to appear as a version with ancestors (it seems a bit magic to me, but perhaps MC supports package renaming)
I don't know of such a refactoring, where is that? MC definitely does not support package renaming.
In Seaside we use the following code. It automates most of the tasks required to rename a package. However, as all the other Montciello tools, it will give unexpected results when used on a bogus package structure. It could work if you rename the packages with the longest name (the innermost in the set of entities) first, and then continue with the shorter ones.
WADevelopment class>>renamePackage: oldPackageName to: newPackageName "self renamePackage: 'Seaside-Squeak-Development-Core' to: 'Seaside-Pharo-Development-Core'" | oldPackage newPackage oldWorkingCopy newWorkingCopy | oldPackage := PackageInfo named: oldPackageName. newPackage := PackageInfo named: newPackageName. " rename system categories " oldPackage systemCategories do: [ :oldCategory | | newCategory | newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size. Smalltalk organization renameCategory: oldCategory toBe: newPackage systemCategoryPrefix , newCategory ]. " rename method categories " oldPackage extensionClasses do: [ :extensionClass | (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol | | newProtocol | newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size. extensionClass organization renameCategory: oldProtocol toBe: newPackage methodCategoryPrefix , newProtocol ] ]. " update monticello packages " oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName). newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName). newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true. " test is all methos have been caught " oldPackage methods isEmpty ifTrue: [ oldWorkingCopy unload. PackageOrganizer default unregisterPackage: oldPackage ] ifFalse: [ self error: 'Some code entities remain in the old package, please migrate manually.' ]
If you give the prefix 'Fame' then any of the packages 'Fame', 'FameLabs' and 'FameUtil' is picked at random. Previously it only has worked by chance, as the sorting was implemented slightly different (I sorted the complete repository, not just the versions in question).
The latest version of Gofer should fix the problem. I added another hack to the algorithm figuring out the version to load. If there are exact package matches, the prefix matches are removed. That solves this problem, and I hope it does not introduce new ones. In any case you should consider renaming/removing these Fame packages, because they are not cleanly loadable anyway.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
But we do not load FameUtils? do we so why this would have an impact. MC loads any package name Fame*
The more I know about this package hack the more I hate it.
Stef
On Oct 1, 2009, at 9:40 AM, Lukas Renggli wrote:
The problem is caused be the failure to load Fame.
Ok, now I understand. This is your fault, because you have overlapping package names.
If you give the prefix 'Fame' then any of the packages 'Fame', 'FameLabs' and 'FameUtil' is picked at random. Previously it only has worked by chance, as the sorting was implemented slightly different (I sorted the complete repository, not just the versions in question).
The latest version of Gofer should fix the problem. I added another hack to the algorithm figuring out the version to load. If there are exact package matches, the prefix matches are removed. That solves this problem, and I hope it does not introduce new ones. In any case you should consider renaming/removing these Fame packages, because they are not cleanly loadable anyway.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
But we do not load FameUtils? do we so why this would have an impact.
The magic 'latest' version tricks have their drawbacks.
Gofer checks prefixes, so if you tell it to load a package named Fame the packages Fame and FameUtil both match. Now when ordering according to numbers to get the 'latest' version, it matters how the two packages are ordered against each other. Before Gofer just had a collection of strings, where Fame and FameUtil were ordered against the number. Since Fame had a higher number the Fame package was picked:
#( Fame.1 FameUtils.1 Fame.2 FameUtils.2 Fame.3 Fame.4 ) --> Fame.4 (ok)
Recently I introduced version objects that know how to sort themselves. Suddenly the list was sorted with more knowledge and Gofer ended up with a sorting like this and picked FameUtils:
#( Fame.1 Fame.2 Fame.3 Fame.4 FameUtils.1 FameUtils.2 ) --> FameUtils.2 (wrong)
Now this is only a problem for badly named package names that overlap. And it could be easily fixed in Gofer by selecting only the versions that have the shortest package name:
#( Fame.1 Fame.2 Fame.3 Fame.4 ) --> Fame.4 (ok)
The ugly thing is that the hacks in Gofer start to accumulate and it is very difficult to change anything, because suddenly everybody starts to complain.
I am right now working on a better matching model for exact/inexact/prefix versions, so that you can write a spec saying how your packages are exactly named. That should solve many of the problems. Until then I suggest that you do not just randomly load the latest version of Gofer from my working repository, but use a fixed version. Gofer-lr.58 for example seems to work with your code, but it does not work well with Seaside packages.
Lukas
First I think that to let you change Gofer we should not load the latest version of Gofer but one that this released.
Second and more important. Now I'm really sad because I have the impression we will to encode this stupid naming conventions even in the package model else when people will save the code they will not be able to load it just because we relay on fucking pattern matching. Lukas could we ban that? Could gofer not match prefix. This is not a feature this is a model bug. We should not let this hacks polute everything. Else I can tell you that people will define package the way we defined them and this will break. It would be good to fix that now.
Stef
But we do not load FameUtils? do we so why this would have an impact.
The magic 'latest' version tricks have their drawbacks.
Gofer checks prefixes, so if you tell it to load a package named Fame the packages Fame and FameUtil both match. Now when ordering according to numbers to get the 'latest' version, it matters how the two packages are ordered against each other. Before Gofer just had a collection of strings, where Fame and FameUtil were ordered against the number. Since Fame had a higher number the Fame package was picked:
#( Fame.1 FameUtils.1 Fame.2 FameUtils.2 Fame.3 Fame.4 ) --> Fame.4 (ok)
Recently I introduced version objects that know how to sort themselves. Suddenly the list was sorted with more knowledge and Gofer ended up with a sorting like this and picked FameUtils:
#( Fame.1 Fame.2 Fame.3 Fame.4 FameUtils.1 FameUtils.2 ) --> FameUtils.2 (wrong)
Now this is only a problem for badly named package names that overlap. And it could be easily fixed in Gofer by selecting only the versions that have the shortest package name:
#( Fame.1 Fame.2 Fame.3 Fame.4 ) --> Fame.4 (ok)
The ugly thing is that the hacks in Gofer start to accumulate and it is very difficult to change anything, because suddenly everybody starts to complain.
I am right now working on a better matching model for exact/inexact/prefix versions, so that you can write a spec saying how your packages are exactly named. That should solve many of the problems. Until then I suggest that you do not just randomly load the latest version of Gofer from my working repository, but use a fixed version. Gofer-lr.58 for example seems to work with your code, but it does not work well with Seaside packages.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Lukas Renggli -
Simon Denier -
Stéphane Ducasse -
Tudor Girba