- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Mm10s] 2019-11-25

by Sean P. DeNigris

ducasse wrote > Thanks Esteban this is great Yes, thanks! Very interesting and helpful :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 27, 2019

Re: [Pharo-dev] BlueInk removal

by Cyril Ferlicot

On Wed, Nov 27, 2019 at 2:17 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Yes, this could have been handled much better, I guess (I don't know the details). > > But for day to day work, you have to use Pharo 7, which should be 100% stable, while Pharo 8 is a moving target, an alpha version that is sometimes broken. > Hi, I agree that the alpha version does not have to be stable all the time, but I still don't think it justify to not deprecate things. When you are working on stable version only, it is still better to be able to migrate your projects from one version to the other via the deprecation than to have everything broken and not loadable. If you can't even load your code, it's much harder to fix it. So I still think that we should go via deprecations. It has really a low cost and make migrations so much easier. Especially it give us time instead of giving us an ultimatum "You want to change of version? Then you need to fix everything now". > Now, we still want users for Pharo 8, else there will be no feedback, so there are certainly two sides to this argument. > > Sven > > > -- Cyril Ferlicot https://ferlicot.fr

Nov. 27, 2019

Re: [Pharo-dev] BlueInk removal

by Sven Van Caekenberghe

> On 27 Nov 2019, at 14:05, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Tue, Nov 26, 2019 at 6:29 PM ducasse <stepharo(a)netcourrier.com> wrote: >> >> Cyril >> >> We are crawling with too many things. >> Pharo should start to lose fat FOR REAL. >> I really hope that we will get rid of lot of old code in the future. >> If Enlumineur does not work when we integrate it - I just issue a PR >> then you will have a good case for reintegrating and having two formatter, two contexts classes, >> two packages full of nearly the same but not quite tests. >> > > Yes but deprecation give us time to migrate. > > Now I cannot work on Moose because the dev version is broken since > Roassal depends on GTEventRecorder and it was removed without > deprecation. > > It's the second day in a row where I cannot work properly. And I don't > know when Moose will be fixed because I don't know the code of roassal > and I cannot fix it myself. So I have to wait that someone else fixes > it. > > I understand that we want Pharo to be smaller but here it prevent > people from working. And the size of those projects is nothing > compared to the global size of Pharo and we are assured to be able to > remove them just after the release of Pharo 8. > >> S. >> >> >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr Yes, this could have been handled much better, I guess (I don't know the details). But for day to day work, you have to use Pharo 7, which should be 100% stable, while Pharo 8 is a moving target, an alpha version that is sometimes broken. Now, we still want users for Pharo 8, else there will be no feedback, so there are certainly two sides to this argument. Sven

Nov. 27, 2019

Re: [Pharo-dev] BlueInk removal

by Cyril Ferlicot

On Tue, Nov 26, 2019 at 6:29 PM ducasse <stepharo(a)netcourrier.com> wrote: > > Cyril > > We are crawling with too many things. > Pharo should start to lose fat FOR REAL. > I really hope that we will get rid of lot of old code in the future. > If Enlumineur does not work when we integrate it - I just issue a PR > then you will have a good case for reintegrating and having two formatter, two contexts classes, > two packages full of nearly the same but not quite tests. > Yes but deprecation give us time to migrate. Now I cannot work on Moose because the dev version is broken since Roassal depends on GTEventRecorder and it was removed without deprecation. It's the second day in a row where I cannot work properly. And I don't know when Moose will be fixed because I don't know the code of roassal and I cannot fix it myself. So I have to wait that someone else fixes it. I understand that we want Pharo to be smaller but here it prevent people from working. And the size of those projects is nothing compared to the global size of Pharo and we are assured to be able to remove them just after the release of Pharo 8. > S. > > > > -- Cyril Ferlicot https://ferlicot.fr

Nov. 27, 2019