Remove all Configurations in the Pharo 6 release?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Remove all Configurations in the Pharo 6 release?

Pavel Krivanek-3
Hi,

in Pharo 7 all configurations will be removed and replaced with the baselines. The bootstrapped image itself does not load the configurations at all. Most of them is now outdated and old versions of configurations in the standard Pharo image can cause problems for users of newer versions semi-internal packages (like Moose-Algos).

So we, me and Cyril think that we should remove all current Configurations from the image just before the Pharo 6 release. Do you see any disadvantages of this step?

Cheers,
-- Pavel
Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

Andrei Chis
Isn't it a bit too late for such a change? Might break projects that expect configurations to be present.

Cheers,
Andrei

On Fri, Apr 14, 2017 at 1:07 PM, Pavel Krivanek <[hidden email]> wrote:
Hi,

in Pharo 7 all configurations will be removed and replaced with the baselines. The bootstrapped image itself does not load the configurations at all. Most of them is now outdated and old versions of configurations in the standard Pharo image can cause problems for users of newer versions semi-internal packages (like Moose-Algos).

So we, me and Cyril think that we should remove all current Configurations from the image just before the Pharo 6 release. Do you see any disadvantages of this step?

Cheers,
-- Pavel

Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

CyrilFerlicot
On 14/04/2017 12:52, Andrei Chis wrote:
> Isn't it a bit too late for such a change? Might break projects that
> expect configurations to be present.
>

Is there such projects?

For me it seems really bad to get a project depending on his configuration.

> Cheers,
> Andrei
>


--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

Andrei Chis


On Apr 14, 2017 13:55, "Cyril Ferlicot D." <[hidden email]> wrote:
On 14/04/2017 12:52, Andrei Chis wrote:
> Isn't it a bit too late for such a change? Might break projects that
> expect configurations to be present.
>

Is there such projects?

I know some that use the GT related ones.


For me it seems really bad to get a project depending on his configuration.

I definetly agree. Just doing it so early to the release will most likely lead to side effects.

Cheers,
Andrei


> Cheers,
> Andrei
>


--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France


Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

Pavel Krivanek-3
In reply to this post by Andrei Chis


2017-04-14 12:52 GMT+02:00 Andrei Chis <[hidden email]>:
Isn't it a bit too late for such a change? Might break projects that expect configurations to be present.

I do not think so. We do not have configurations for the system itself (well, we have them in an external repository but they are not update since switch to baselines). They are used only for the actively maintained semi-external projects like GT, QA, Epicea, Zinc etc. However even in that case they are sometimes out-of-sync with the upstream. 

Most users of such configurations are using the upstream configurations. If some one is using wrongly the versions in Pharo, he uses reference to the Pharo repository where the configurations will still be present.

Cheers,
-- Pavel
 

Cheers,
Andrei

On Fri, Apr 14, 2017 at 1:07 PM, Pavel Krivanek <[hidden email]> wrote:
Hi,

in Pharo 7 all configurations will be removed and replaced with the baselines. The bootstrapped image itself does not load the configurations at all. Most of them is now outdated and old versions of configurations in the standard Pharo image can cause problems for users of newer versions semi-internal packages (like Moose-Algos).

So we, me and Cyril think that we should remove all current Configurations from the image just before the Pharo 6 release. Do you see any disadvantages of this step?

Cheers,
-- Pavel


Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

Andrei Chis


On Apr 14, 2017 14:13, "Pavel Krivanek" <[hidden email]> wrote:


2017-04-14 12:52 GMT+02:00 Andrei Chis <[hidden email]>:
Isn't it a bit too late for such a change? Might break projects that expect configurations to be present.

I do not think so. We do not have configurations for the system itself (well, we have them in an external repository but they are not update since switch to baselines). They are used only for the actively maintained semi-external projects like GT, QA, Epicea, Zinc etc. However even in that case they are sometimes out-of-sync with the upstream. 

Most users of such configurations are using the upstream configurations. If some one is using wrongly the versions in Pharo, he uses reference to the Pharo repository where the configurations will still be present.

For the record, I still think it's not the best idea to do this now :)

Cheers,
Andrei


Cheers,
-- Pavel
 

Cheers,
Andrei

On Fri, Apr 14, 2017 at 1:07 PM, Pavel Krivanek <[hidden email]> wrote:
Hi,

in Pharo 7 all configurations will be removed and replaced with the baselines. The bootstrapped image itself does not load the configurations at all. Most of them is now outdated and old versions of configurations in the standard Pharo image can cause problems for users of newer versions semi-internal packages (like Moose-Algos).

So we, me and Cyril think that we should remove all current Configurations from the image just before the Pharo 6 release. Do you see any disadvantages of this step?

Cheers,
-- Pavel



Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

Pavel Krivanek-3


2017-04-14 14:20 GMT+02:00 Andrei Chis <[hidden email]>:


On Apr 14, 2017 14:13, "Pavel Krivanek" <[hidden email]> wrote:


2017-04-14 12:52 GMT+02:00 Andrei Chis <[hidden email]>:
Isn't it a bit too late for such a change? Might break projects that expect configurations to be present.

I do not think so. We do not have configurations for the system itself (well, we have them in an external repository but they are not update since switch to baselines). They are used only for the actively maintained semi-external projects like GT, QA, Epicea, Zinc etc. However even in that case they are sometimes out-of-sync with the upstream. 

Most users of such configurations are using the upstream configurations. If some one is using wrongly the versions in Pharo, he uses reference to the Pharo repository where the configurations will still be present.

For the record, I still think it's not the best idea to do this now :)

Probably :-) In the end, the users that have troubles with it can easily do it during preparations of their images too.

-- Pavel
 

Cheers,
Andrei


Cheers,
-- Pavel
 

Cheers,
Andrei

On Fri, Apr 14, 2017 at 1:07 PM, Pavel Krivanek <[hidden email]> wrote:
Hi,

in Pharo 7 all configurations will be removed and replaced with the baselines. The bootstrapped image itself does not load the configurations at all. Most of them is now outdated and old versions of configurations in the standard Pharo image can cause problems for users of newer versions semi-internal packages (like Moose-Algos).

So we, me and Cyril think that we should remove all current Configurations from the image just before the Pharo 6 release. Do you see any disadvantages of this step?

Cheers,
-- Pavel




Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

Tudor Girba-2
Hi,

I do not quite understand the benefit of removing Configurations in Pharo 6. Is there a benefit that I do not see?

Cheers,
Doru



> On Apr 14, 2017, at 2:24 PM, Pavel Krivanek <[hidden email]> wrote:
>
>
>
> 2017-04-14 14:20 GMT+02:00 Andrei Chis <[hidden email]>:
>
>
> On Apr 14, 2017 14:13, "Pavel Krivanek" <[hidden email]> wrote:
>
>
> 2017-04-14 12:52 GMT+02:00 Andrei Chis <[hidden email]>:
> Isn't it a bit too late for such a change? Might break projects that expect configurations to be present.
>
> I do not think so. We do not have configurations for the system itself (well, we have them in an external repository but they are not update since switch to baselines). They are used only for the actively maintained semi-external projects like GT, QA, Epicea, Zinc etc. However even in that case they are sometimes out-of-sync with the upstream.
>
> Most users of such configurations are using the upstream configurations. If some one is using wrongly the versions in Pharo, he uses reference to the Pharo repository where the configurations will still be present.
>
> For the record, I still think it's not the best idea to do this now :)
>
> Probably :-) In the end, the users that have troubles with it can easily do it during preparations of their images too.
>
> -- Pavel
>  
>
> Cheers,
> Andrei
>
>
> Cheers,
> -- Pavel
>  
>
> Cheers,
> Andrei
>
> On Fri, Apr 14, 2017 at 1:07 PM, Pavel Krivanek <[hidden email]> wrote:
> Hi,
>
> in Pharo 7 all configurations will be removed and replaced with the baselines. The bootstrapped image itself does not load the configurations at all. Most of them is now outdated and old versions of configurations in the standard Pharo image can cause problems for users of newer versions semi-internal packages (like Moose-Algos).
>
> So we, me and Cyril think that we should remove all current Configurations from the image just before the Pharo 6 release. Do you see any disadvantages of this step?
>
> Cheers,
> -- Pavel

--
www.tudorgirba.com
www.feenk.com

"Reasonable is what we are accustomed with."


Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

abergel
I understand that since the whole development will be Git-based, then the configurations will be pretty much obsolete.

Alexandre


> On Apr 15, 2017, at 6:08 PM, Tudor Girba <[hidden email]> wrote:
>
> Hi,
>
> I do not quite understand the benefit of removing Configurations in Pharo 6. Is there a benefit that I do not see?
>
> Cheers,
> Doru
>
>
>
>> On Apr 14, 2017, at 2:24 PM, Pavel Krivanek <[hidden email]> wrote:
>>
>>
>>
>> 2017-04-14 14:20 GMT+02:00 Andrei Chis <[hidden email]>:
>>
>>
>> On Apr 14, 2017 14:13, "Pavel Krivanek" <[hidden email]> wrote:
>>
>>
>> 2017-04-14 12:52 GMT+02:00 Andrei Chis <[hidden email]>:
>> Isn't it a bit too late for such a change? Might break projects that expect configurations to be present.
>>
>> I do not think so. We do not have configurations for the system itself (well, we have them in an external repository but they are not update since switch to baselines). They are used only for the actively maintained semi-external projects like GT, QA, Epicea, Zinc etc. However even in that case they are sometimes out-of-sync with the upstream.
>>
>> Most users of such configurations are using the upstream configurations. If some one is using wrongly the versions in Pharo, he uses reference to the Pharo repository where the configurations will still be present.
>>
>> For the record, I still think it's not the best idea to do this now :)
>>
>> Probably :-) In the end, the users that have troubles with it can easily do it during preparations of their images too.
>>
>> -- Pavel
>>
>>
>> Cheers,
>> Andrei
>>
>>
>> Cheers,
>> -- Pavel
>>
>>
>> Cheers,
>> Andrei
>>
>> On Fri, Apr 14, 2017 at 1:07 PM, Pavel Krivanek <[hidden email]> wrote:
>> Hi,
>>
>> in Pharo 7 all configurations will be removed and replaced with the baselines. The bootstrapped image itself does not load the configurations at all. Most of them is now outdated and old versions of configurations in the standard Pharo image can cause problems for users of newer versions semi-internal packages (like Moose-Algos).
>>
>> So we, me and Cyril think that we should remove all current Configurations from the image just before the Pharo 6 release. Do you see any disadvantages of this step?
>>
>> Cheers,
>> -- Pavel
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Reasonable is what we are accustomed with."
>
>

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




Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

CyrilFerlicot
In reply to this post by Tudor Girba-2
On 15/04/2017 23:08, Tudor Girba wrote:
> Hi,
>
> I do not quite understand the benefit of removing Configurations in Pharo 6. Is there a benefit that I do not see?
>
> Cheers,
> Doru
>
>

If you have a project depending on another project that got his
configuration in the image, the configuration will not be updated if you
do not do it explicitly.

We found with Pavel that the version of MooseAlgo used by Moose was
outdated because ConfigurationOfMooseAlgos was in the image with 5-6
commits late.

Users should not have to update the configuration of the dependencies of
their project by hand in their builds because Pharo has old
configurations inside the image.

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

Tudor Girba-2
In reply to this post by abergel
Of course. But, that will only be applicable to people using Pharo 7 and beyond. For people using Pharo 6, they will still rely on how the code was packaged for that release. Or did I miss something?

Doru


> On Apr 15, 2017, at 11:11 PM, Alexandre Bergel <[hidden email]> wrote:
>
> I understand that since the whole development will be Git-based, then the configurations will be pretty much obsolete.
>
> Alexandre
>
>
>> On Apr 15, 2017, at 6:08 PM, Tudor Girba <[hidden email]> wrote:
>>
>> Hi,
>>
>> I do not quite understand the benefit of removing Configurations in Pharo 6. Is there a benefit that I do not see?
>>
>> Cheers,
>> Doru
>>
>>
>>
>>> On Apr 14, 2017, at 2:24 PM, Pavel Krivanek <[hidden email]> wrote:
>>>
>>>
>>>
>>> 2017-04-14 14:20 GMT+02:00 Andrei Chis <[hidden email]>:
>>>
>>>
>>> On Apr 14, 2017 14:13, "Pavel Krivanek" <[hidden email]> wrote:
>>>
>>>
>>> 2017-04-14 12:52 GMT+02:00 Andrei Chis <[hidden email]>:
>>> Isn't it a bit too late for such a change? Might break projects that expect configurations to be present.
>>>
>>> I do not think so. We do not have configurations for the system itself (well, we have them in an external repository but they are not update since switch to baselines). They are used only for the actively maintained semi-external projects like GT, QA, Epicea, Zinc etc. However even in that case they are sometimes out-of-sync with the upstream.
>>>
>>> Most users of such configurations are using the upstream configurations. If some one is using wrongly the versions in Pharo, he uses reference to the Pharo repository where the configurations will still be present.
>>>
>>> For the record, I still think it's not the best idea to do this now :)
>>>
>>> Probably :-) In the end, the users that have troubles with it can easily do it during preparations of their images too.
>>>
>>> -- Pavel
>>>
>>>
>>> Cheers,
>>> Andrei
>>>
>>>
>>> Cheers,
>>> -- Pavel
>>>
>>>
>>> Cheers,
>>> Andrei
>>>
>>> On Fri, Apr 14, 2017 at 1:07 PM, Pavel Krivanek <[hidden email]> wrote:
>>> Hi,
>>>
>>> in Pharo 7 all configurations will be removed and replaced with the baselines. The bootstrapped image itself does not load the configurations at all. Most of them is now outdated and old versions of configurations in the standard Pharo image can cause problems for users of newer versions semi-internal packages (like Moose-Algos).
>>>
>>> So we, me and Cyril think that we should remove all current Configurations from the image just before the Pharo 6 release. Do you see any disadvantages of this step?
>>>
>>> Cheers,
>>> -- Pavel
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Reasonable is what we are accustomed with."
>>
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>

--
www.tudorgirba.com
www.feenk.com

"No matter how many recipes we know, we still value a chef."








Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

Tudor Girba-2
In reply to this post by CyrilFerlicot
Hi,

Ok, that is a better reason.

As far as I can tell, the baseline situation is not much better, is it?

Cheers,
Doru



> On Apr 15, 2017, at 11:12 PM, Cyril Ferlicot D. <[hidden email]> wrote:
>
> On 15/04/2017 23:08, Tudor Girba wrote:
>> Hi,
>>
>> I do not quite understand the benefit of removing Configurations in Pharo 6. Is there a benefit that I do not see?
>>
>> Cheers,
>> Doru
>>
>>
>
> If you have a project depending on another project that got his
> configuration in the image, the configuration will not be updated if you
> do not do it explicitly.
>
> We found with Pavel that the version of MooseAlgo used by Moose was
> outdated because ConfigurationOfMooseAlgos was in the image with 5-6
> commits late.
>
> Users should not have to update the configuration of the dependencies of
> their project by hand in their builds because Pharo has old
> configurations inside 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

"Yesterday is a fact.
 Tomorrow is a possibility.
 Today is a challenge."





Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

CyrilFerlicot
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


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

Tudor Girba-2
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. <[hidden email]> 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."






Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

Tudor Girba-2
However, Configurations are useful in offering people a way to understand how the code is organized. For example, in Moose we have the inspector extension that shows the dependencies and it is very valuable.

The only thing we need is to Metacello to be able to load new versions of the configuration/baseline.

Cheers,
Doru


> On Apr 16, 2017, at 8:36 AM, Tudor Girba <[hidden email]> wrote:
>
> 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. <[hidden email]> 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."
>
>
>
>
>

--
www.tudorgirba.com
www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the software gets."


Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

kilon.alios
Just for the record the easiest way to load packages in the image the Package Browser relies solely on configurations . Is there a plan to migrate because as much I am vocal supporter of Pharo moving to git it will be a big lose if Package Browser is not ported .
On Sun, 16 Apr 2017 at 09:55, Tudor Girba <[hidden email]> wrote:
However, Configurations are useful in offering people a way to understand how the code is organized. For example, in Moose we have the inspector extension that shows the dependencies and it is very valuable.

The only thing we need is to Metacello to be able to load new versions of the configuration/baseline.

Cheers,
Doru


> On Apr 16, 2017, at 8:36 AM, Tudor Girba <[hidden email]> wrote:
>
> 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. <[hidden email]> 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."
>
>
>
>
>

--
www.tudorgirba.com
www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the software gets."


Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

CyrilFerlicot
In reply to this post by Tudor Girba-2
On 16/04/2017 08:54, Tudor Girba wrote:
> However, Configurations are useful in offering people a way to understand how the code is organized. For example, in Moose we have the inspector extension that shows the dependencies and it is very valuable.
>
> The only thing we need is to Metacello to be able to load new versions of the configuration/baseline.
>

Hi,

This is already possible via the method #get.

But, IMO, the user should not have to do that with a fresh Pharo image.


> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> “The smaller and more pervasive the hardware becomes, the more physical the software gets."
>
>

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

Stephan Eggermont-3
In reply to this post by kilon.alios
On 16/04/17 16:14, Dimitris Chloupis wrote:
> Just for the record the easiest way to load packages in the image the
> Package Browser relies solely on configurations . Is there a plan to
> migrate because as much I am vocal supporter of Pharo moving to git it
> will be a big lose if Package Browser is not ported .

Which browser do you mean? Catalog? That generally does not work well
because it cannot deal with combinations of configurations.

Stephan



Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

kilon.alios
Ephestos is my project that is a single configuration that unites all my other projects under one roof. Ephestos loads 1) Nireas 2) ChronosManager 3) SmaCC (not mine) 4) Atlas 5) CPP 6) Octopus 7) BPY 8) Orpheas . Each one of them a separate git repo with its own baseline. Some of them depend on each other. Also each of those repos has its own configuration in case I want to install it separately. So this way I can build my own image with a single click. https://github.com/kilon/Ephestos/blob/master/BaselineOfEphestos.package/BaselineOfEphestos.class/instance/baseline..st

So yeah I would like for Package Browser to stay, it works great for me and I have not even used the convenience of git tags, branches, github releases and git modules yet that would easily allow me to build insanely complex images with a single click.
On Mon, 17 Apr 2017 at 00:25, Stephan Eggermont <[hidden email]> wrote:
On 16/04/17 16:14, Dimitris Chloupis wrote:
> Just for the record the easiest way to load packages in the image the
> Package Browser relies solely on configurations . Is there a plan to
> migrate because as much I am vocal supporter of Pharo moving to git it
> will be a big lose if Package Browser is not ported .

Which browser do you mean? Catalog? That generally does not work well
because it cannot deal with combinations of configurations.

Stephan



Reply | Threaded
Open this post in threaded view
|

Re: Remove all Configurations in the Pharo 6 release?

Dale Henrichs-3
In reply to this post by CyrilFerlicot
I would think that a `project list` view that made the Metacello project
registration visible would help developers keep things straight.

It seems that the issue here is that developers can't tell what projects
are already loaded in the current image and also cannot tell what
version of the project is loaded ... if you are using the `Metacello
new` to load projects, then Metacello knows what projects and what
versions are loaded in the image .... and that informatation really
needs to be exposed to the developers ...

If you have a `project list` then you can do things like automatically
do a get on a configuration/baseline when a project is loaded via the
`project list tool` ... there are additional details that need to be
tracked and managed, but without the a basic `project list` the
developer is responsible for "knowing what to do" and the first step is
to let the developer know exactly which versions of which projects are
loaded in the base image ...

Dale


On 04/16/2017 11:46 AM, Cyril Ferlicot D. wrote:

> On 16/04/2017 08:54, Tudor Girba wrote:
>> However, Configurations are useful in offering people a way to understand how the code is organized. For example, in Moose we have the inspector extension that shows the dependencies and it is very valuable.
>>
>> The only thing we need is to Metacello to be able to load new versions of the configuration/baseline.
>>
> Hi,
>
> This is already possible via the method #get.
>
> But, IMO, the user should not have to do that with a fresh Pharo image.
>
>
>> Cheers,
>> Doru
>>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> “The smaller and more pervasive the hardware becomes, the more physical the software gets."
>>
>>
>


12