November 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] BlueInk removal

by Benoit St-Jean

StÃ©phane, You could have said the exact same thing in nicer words, calmly WITHOUT SHOUTING and taking it personal. If people criticize stuff/work/code, it's because 1) they care about Pharo 2) they use Pharo. The day no one will complain on the list will mean Pharo's dead. It also means people have to deal with real projects and real apps and real customers and real migration problems. We have a tool called deprecation, let's use it. It'll save a lot of headaches to everyone. And if you remove stuff, give the developers an extra chance by at least informing them of the upcoming changes/removals by deprecating stuff, not just removing it without warning! I don't recall one single instance in my professional life when VisualWorks or VisualAge Smalltalk didn't provide EVERYTHING that was necessary to be compatible with the previous version to facilitate the job of their customers, us, the developers. Whether it was in the form of deprecated parcels or packages, Cincom & IBM (and now Instantiations) understood one thing : you don't migrate apps that generate millions a year like a tic-tac-toe project on GitHub. It takes time just to migrate from one version to the next, imagine the nightmare when "stuff had just been removed" out of the blue. If you want to see more commercial use of Pharo, you'll have to understand that! In the meantime, could you PLEASE stop taking criticism as if it was directed towards you and/or the Pharo devs? On 2019-11-27 15:31, ducasse wrote: > Cyril > > there is no deprecation for classes: yes I would have to subclass each class and provide old classes. > Sorry but *****I******* repackaged, cleaned the tests, cleaned the baseline, made sure that the baseline is working â¦. of > - GTRecorder (not used in Pharo since 3 YEARS). > - Enlumineur > > And I do not have nor the time or energy at the end of the day to do that in addition > to do all the deprecation and of course fix all the dependencies tests. > > Now if your message is that Pharo should stay with all that shit inside then perfect, Iâm off. > I have plenty of other things (and a lot more exciting to do). > > BTW I THE GUY THAT IS PRODUCING MIGRATOR: you see the idiot that is collecting all the deprecated methods > and packaged them so that OTHERS than me can migrate. > > So now for Blueink then you take 5 min and change your scripts. > So GTEvent recorder you ask alex or milton to see if we can get rid of the problem. > > I do not see why Moose is loading Roassal with it. > To me this is a bad dependency of Roassal. > > If Pharo puts on itself so much constraints then at the end may be I should stop and do something and see > how great this super kitchen sink will evolved. > > Have you ever dare to look at the BaselineOfPharo, IDE just for the fun. > > > >>> 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 >> > > -- ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth GitHub: bstjean Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Nov. 28, 2019

[Pharo 8.0] Build #1021: 5246--AST-Core-Tests-package-disappeared

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1021 was: FAILURE. The Pull Request #5254 was integrated: "5246--AST-Core-Tests-package-disappeared" Pull request url: https://github.com/pharo-project/pharo/pull/5254 Issue Url: https://github.com/pharo-project/pharo/issues/5246 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2019

Re: [Pharo-dev] BlueInk removal

by Nicolas Cellier

Why is there no deprecation for classes? The class definition can belong to a deprecated package. For more advanced feature, the deprected globals could belong to another dictionary, a bit like Undeclared... Le mer. 27 nov. 2019 Ã 21:31, ducasse <stepharo(a)netcourrier.com> a Ã©crit : > Cyril > > there is no deprecation for classes: yes I would have to subclass each > class and provide old classes. > Sorry but *****I******* repackaged, cleaned the tests, cleaned the > baseline, made sure that the baseline is working â¦. of > - GTRecorder (not used in Pharo since 3 YEARS). > - Enlumineur > > And I do not have nor the time or energy at the end of the day to do that > in addition > to do all the deprecation and of course fix all the dependencies tests. > > Now if your message is that Pharo should stay with all that shit inside > then perfect, Iâm off. > I have plenty of other things (and a lot more exciting to do). > > BTW I THE GUY THAT IS PRODUCING MIGRATOR: you see the idiot that is > collecting all the deprecated methods > and packaged them so that OTHERS than me can migrate. > > So now for Blueink then you take 5 min and change your scripts. > So GTEvent recorder you ask alex or milton to see if we can get rid of the > problem. > > I do not see why Moose is loading Roassal with it. > To me this is a bad dependency of Roassal. > > If Pharo puts on itself so much constraints then at the end may be I > should stop and do something and see > how great this super kitchen sink will evolved. > > Have you ever dare to look at the BaselineOfPharo, IDE just for the fun. > > > > >> 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 ducasse

Cyril there is no deprecation for classes: yes I would have to subclass each class and provide old classes. Sorry but *****I******* repackaged, cleaned the tests, cleaned the baseline, made sure that the baseline is working â¦. of - GTRecorder (not used in Pharo since 3 YEARS). - Enlumineur And I do not have nor the time or energy at the end of the day to do that in addition to do all the deprecation and of course fix all the dependencies tests. Now if your message is that Pharo should stay with all that shit inside then perfect, Iâm off. I have plenty of other things (and a lot more exciting to do). BTW I THE GUY THAT IS PRODUCING MIGRATOR: you see the idiot that is collecting all the deprecated methods and packaged them so that OTHERS than me can migrate. So now for Blueink then you take 5 min and change your scripts. So GTEvent recorder you ask alex or milton to see if we can get rid of the problem. I do not see why Moose is loading Roassal with it. To me this is a bad dependency of Roassal. If Pharo puts on itself so much constraints then at the end may be I should stop and do something and see how great this super kitchen sink will evolved. Have you ever dare to look at the BaselineOfPharo, IDE just for the fun. >> 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 ducasse

> 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. ok sorry I do not get why roassal depends on event recorder. > 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. Sure but Pharo is alpha. If in alpha we cannot do this can of things then I prefer to do something else. > 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. No because I spent my time cleaning and moving GTRecorder out of Pharo and the same for BlueInk. Now Iâm sorry but this is not my fault if - you work in alpha - roassal depends on old projects Iâm fed up to have a system full of shit and abandonware. Iâm fed up to have tons of user of global everywhere that I do not want to fix. Iâm fed up cleaning the mess of others. S. > >> S. >> >> >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr >

Nov. 27, 2019

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

[Pharo 8.0] Build #1020: Fix spotter openning bug

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1020 was: SUCCESS. The Pull Request #5251 was integrated: "Fix spotter openning bug" Pull request url: https://github.com/pharo-project/pharo/pull/5251 Issue Url: https://github.com/pharo-project/pharo/issues/fix_spotter_bug Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2019