Hi, For the record, the way we load the latest version of Moose is to explicitly load the configurations we know about as being in the base Pharo image. Like this: ./pharo $JOB_NAME.image eval "Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTInspector'; package: 'ConfigurationOfGTInspectorCore'; package: 'ConfigurationOfGTSpotter'; package: 'ConfigurationOfGTPlayground'; package: 'ConfigurationOfGTPlaygroundCore'; package: 'ConfigurationOfGToolkit'; package: 'ConfigurationOfGToolkitCore'; package: 'ConfigurationOfGTEventRecorder'; load. Smalltalk snapshot: true andQuit: true." This is a horrible hack, and like any hack it backfires in time. It backfired now because we forgot about MooseAlgos being in the base Pharo image :). Cheers, Doru
On Apr 15, 2017, at 11:23 PM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
On 15/04/2017 23:16, Tudor Girba wrote:
Hi,
Ok, that is a better reason.
As far as I can tell, the baseline situation is not much better, is it?
Cheers, Doru
Yes.
If the process would have been the same for Pharo 7 than for Pharo 6 I would have suggest to unload the configurations after every update of a project using configuration.
Here, since the process will change I wait to see how the new process will look like. But I would like the configurations/baselines to be unload of Pharo to avoid this.
I would like to unload all the configurations of the image of Pharo 6 to remove a potential bug source of Pharo 6 for future users who would need an update of GlamourCore, a GT tool, Ston, UFFI or any other project having his configuration in the image.
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
-- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."