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 |
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:
|
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 |
On Apr 14, 2017 13:55, "Cyril Ferlicot D." <[hidden email]> wrote:
I know some that use the GT related ones.
I definetly agree. Just doing it so early to the release will most likely lead to side effects. Cheers, Andrei
|
In reply to this post by Andrei Chis
2017-04-14 12:52 GMT+02:00 Andrei Chis <[hidden email]>:
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
|
On Apr 14, 2017 14:13, "Pavel Krivanek" <[hidden email]> wrote:
For the record, I still think it's not the best idea to do this now :) Cheers, Andrei
|
2017-04-14 14:20 GMT+02:00 Andrei Chis <[hidden email]>:
Probably :-) In the end, the users that have troubles with it can easily do it during preparations of their images too. -- Pavel
|
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." |
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
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 |
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." |
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." |
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 |
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." |
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." |
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. |
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 |
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 |
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: |
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." >> >> > |
Free forum by Nabble | Edit this page |