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(a)me.com&gt; >> Date: September 30, 2009 9:10:32 PM GMT+02:00 >> To: Stéphane Ducasse <stephane.ducasse(a)inria.fr&gt; >> Cc: Simon Denier <simon.denier(a)inria.fr&gt; >> 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(a)inria.fr&gt; >>>> Date: September 30, 2009 4:36:40 PM GMT+02:00 >>>> To: Simon Denier <Simon.Denier(a)inria.fr&gt; >>>> Cc: Related to the development of Moose and other related tools >>>> <moose-dev(a)iam.unibe.ch&gt;, Lukas Renggli <renggli(a)iam.unibe.ch&gt; >>>> Subject: [Moose-dev] Re: MooseLoader load does not load Fame ? >>>> Reply-To: Related to the development of Moose and other related tools >>>> <moose-dev(a)iam.unibe.ch&gt; >>>> >>>> >>>> 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(a)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(a)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(a)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(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 >>>>> >>>>> -- >>>>> Simon >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)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(a)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(a)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(a)gmail.com&gt;: > 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(a)gmail.com&gt;: >> 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(a)me.com&gt; >>>> Date: September 30, 2009 9:10:32 PM GMT+02:00 >>>> To: Stéphane Ducasse <stephane.ducasse(a)inria.fr&gt; >>>> Cc: Simon Denier <simon.denier(a)inria.fr&gt; >>>> 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(a)inria.fr&gt; >>>>>> Date: September 30, 2009 4:36:40 PM GMT+02:00 >>>>>> To: Simon Denier <Simon.Denier(a)inria.fr&gt; >>>>>> Cc: Related to the development of Moose and other related tools >>>>>> <moose-dev(a)iam.unibe.ch&gt;, Lukas Renggli <renggli(a)iam.unibe.ch&gt; >>>>>> Subject: [Moose-dev] Re: MooseLoader load does not load Fame ? >>>>>> Reply-To: Related to the development of Moose and other >>>>>> related tools >>>>>> <moose-dev(a)iam.unibe.ch&gt; >>>>>> >>>>>> >>>>>> 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(a)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(a)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(a)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(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 >>>>>>> >>>>>>> -- >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Simon >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev(a)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(a)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(a)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(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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

> 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(a)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 -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev