BlueInk removal
Locked
 
|
Hi,
Can we revert the removal of blueink the time the new formatter is in the image please? (And maybe deprecate it instead of removing it). I ask this because: - If we work with Pharo 8 we need to format the code by hand because the format option is currently messing the code - The current formatter is removing all method comment - Currently removing it without deprecation is breaking the setting system (And since I push the setting system further than most people, I cannot even open an image with settings now...) I remind that the formatter is called by the refactorings. Imagine my surprise when I wanted to commit refactorings and I saw all the formatting messed up and all my method comments missing. I really do not appreciate to lose comments I spent time to write like this... -- Cyril Ferlicot https://ferlicot.fr |
|
|
Cyril can you wait until this evening?
We should remove old things and having the two side by side is a lot more painful to work. We are still in Pharo 80 alpha. Stef > On 26 Nov 2019, at 11:55, Cyril Ferlicot <[hidden email]> wrote: > > Hi, > > Can we revert the removal of blueink the time the new formatter is in > the image please? (And maybe deprecate it instead of removing it). > > I ask this because: > - If we work with Pharo 8 we need to format the code by hand because > the format option is currently messing the code > - The current formatter is removing all method comment > - Currently removing it without deprecation is breaking the setting > system (And since I push the setting system further than most people, > I cannot even open an image with settings now...) > > I remind that the formatter is called by the refactorings. Imagine my > surprise when I wanted to commit refactorings and I saw all the > formatting messed up and all my method comments missing. I really do > not appreciate to lose comments I spent time to write like this... > > -- > Cyril Ferlicot > https://ferlicot.fr > |
|
|
On Tue, Nov 26, 2019 at 2:07 PM ducasse <[hidden email]> wrote:
> > Cyril can you wait until this evening? > We should remove old things and having the two side by side is a lot more painful > to work. > We are still in Pharo 80 alpha. > > Stef > Can't we deprecate it? It's 1200 LoC, if it's deprecated everything will be stricked and people will know they should not use it and it will help us migrate our settings without breaking everything. And deprecating it is just one method in the manifest. > > -- Cyril Ferlicot https://ferlicot.fr |
|
|
> On 26 Nov 2019, at 14:16, Cyril Ferlicot <[hidden email]> wrote: > > On Tue, Nov 26, 2019 at 2:07 PM ducasse <[hidden email]> wrote: >> >> Cyril can you wait until this evening? >> We should remove old things and having the two side by side is a lot more painful >> to work. >> We are still in Pharo 80 alpha. >> >> Stef >> > > Can't we deprecate it? It's 1200 LoC, if it's deprecated everything > will be stricked and people will know they should not use it and it > will help us migrate our settings without breaking everything. ;((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( > > And deprecating it is just one method in the manifest. > >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr > |
|
|
In reply to this post by CyrilFerlicot
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. S. > On 26 Nov 2019, at 14:16, Cyril Ferlicot <[hidden email]> wrote: > > On Tue, Nov 26, 2019 at 2:07 PM ducasse <[hidden email]> wrote: >> >> Cyril can you wait until this evening? >> We should remove old things and having the two side by side is a lot more painful >> to work. >> We are still in Pharo 80 alpha. >> >> Stef >> > > Can't we deprecate it? It's 1200 LoC, if it's deprecated everything > will be stricked and people will know they should not use it and it > will help us migrate our settings without breaking everything. > > And deprecating it is just one method in the manifest. > >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr > |
|
|
I guess most Pharo developers and user care more on RELIABILITY, STABILITY and REPRODUCABILITY.
Unfortunately there was - no initial discussion on the mailinglist - no description what "Enlumineur" is or where to find it (had to google it and link issue to your repo) - PR was not reviewed nor commented from a second side although removal or switch to basic formatter is a more radical change - an integrator is merging his own PR, no additional look from a second side - all this from one day to the other - ending up in an image broken settings and a basic formatter (who is buggy and eating the comments when used) which will also affect future contributions We for sure all agree on the "WHY" and value that you take action to care on the topic. But you have to admit the "HOW" puts a guestion mark on the way the contribution/integration process works. We have broken settings now - which was clear when we just remove. This will also not be solved automagically when we are past alpha stage. Especially when proper deprecation would have been a single method in the package manifest, see [1]. Some community members had to repair local settings now and also this discussion pulls time (we all could have better invested). If the plate is full we will not empty it out by leaving our paths ... Thx T. [1] http://forum.world.st/Deprecation-guide-for-methods-classes-and-packages-td5085081.html > Gesendet: Dienstag, 26. November 2019 um 18:29 Uhr > Von: "ducasse" <[hidden email]> > An: "Pharo Development List" <[hidden email]> > Betreff: Re: [Pharo-dev] BlueInk removal > > 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. > > S. > > > On 26 Nov 2019, at 14:16, Cyril Ferlicot <[hidden email]> wrote: > > > > On Tue, Nov 26, 2019 at 2:07 PM ducasse <[hidden email]> wrote: > >> > >> Cyril can you wait until this evening? > >> We should remove old things and having the two side by side is a lot more painful > >> to work. > >> We are still in Pharo 80 alpha. > >> > >> Stef > >> > > > > Can't we deprecate it? It's 1200 LoC, if it's deprecated everything > > will be stricked and people will know they should not use it and it > > will help us migrate our settings without breaking everything. > > > > And deprecating it is just one method in the manifest. > > > >> > >> > > > > > > -- > > Cyril Ferlicot > > https://ferlicot.fr > > > > > > |
|
|
In reply to this post by ducasse
On Tue, Nov 26, 2019 at 6:29 PM ducasse <[hidden email]> 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 |
|
|
> On 27 Nov 2019, at 14:05, Cyril Ferlicot <[hidden email]> wrote: > > On Tue, Nov 26, 2019 at 6:29 PM ducasse <[hidden email]> 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 |
|
|
On Wed, Nov 27, 2019 at 2:17 PM Sven Van Caekenberghe <[hidden email]> 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 |
|
|
In reply to this post by CyrilFerlicot
> On 27 Nov 2019, at 14:05, Cyril Ferlicot <[hidden email]> wrote: > > On Tue, Nov 26, 2019 at 6:29 PM ducasse <[hidden email]> 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. |
|
|
In reply to this post by CyrilFerlicot
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 > |
|
|
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 <[hidden email]> a écrit : Cyril |
Re: BlueInk removal
|
|
In reply to this post by ducasse
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) |
|
|
To me it certainly looks like a <before we freeze Pharo 8 we have to speed up with features> to get things in
by all means. Have to admit I had this kind of "panic mode" myself several times in the past too ;) Stef writes he now does not have the time nor energy - which I guess (including his reactions) is a tribute to his workload. But then it would have been better to change to new Elumineire or getting rid of GTEventRecorder in Pharo 9 and now just marking them for later exclusion. Because often we all underestimate the depencies, side effects, migration costs - even the reactions. Meanwhile Pharo is not only the base image - it is the full ecosystem around it which is good and a positive sign and something we IMHO need to respect more and more. One has to understand that by just removing and not using deprecation the situation is getting worse and now pulling more time and energy from other parts of the community too. Because broken stuff like Spotter, Settings, Roassal, Moose, ... would need repair - either directly (to help contributors who use them in P8 alpha already to give quick feedback) - together with the Pharo 8 release so they can be used - after Pharo 8 is released (which would be very late and might include migration surprises) Depreaction would help us better managing such transitions and is something that is standard in other languages too. The alternative would be to say this is OPP (other peoples problem) and completely ignoring that projects are built on top of Pharo base. We all know removing leads to being incompatible and is not helpful in offering a transition path - therefore not a good option. Because then users would always need to start from scratch with each Pharo release and loose interest quickly. Users want to do both: use Pharo and move their projects without having to focus on changed infrastructure too often. Deprecation would give more room to fixing it- we have theses mechanisms like deprecations and we should really use them. In the past we were able to move more freely - but now we should really accept that with more users we have to follow certain backwards compatibility and more clear rules. This slows us down yes and requires more time and energy. But it is still a good thing because Pharo is actually used and the community can grow. We can not move Pharo into the "perfect" future with a crowbar as this would mean to loose users and especially trust into the system. We might then still come up with an improved (but still imperfect) system in a few years - but nobody would be interested anymore. If we fail to see things from the POV of the user then we will fail overall and loose them. I agree with Benoit that especially business users first have to solve the customers problems before they can juggle with migrations. So lets support the overall community and not being ignorant to it. So far we all managed it quite good: moving from Pharo 6 to 7 and even Pharo 8 is working because things over the last releases stabilized and also because we added more rules, depreactions, transformations and helping users. I personally would prefer to see that "Pharo is not perfect but strong and widely used" than "look how cool it could have been", so lets not get too impatient. Step by step - sometimes faster sometimes slower... Thanks T. |
|
|
This is all true, BUT ...
Very few people attempt to do fundamental changes/cleanups/subsystem-replacements in the core image. This takes a lot of work, is never easy and almost always has issues. Resources are limited as well, in theory things can be done better, in practice in the real world, not so much. The alternative is to never touch anything and stay stagnant. > On 28 Nov 2019, at 10:03, Torsten Bergmann <[hidden email]> wrote: > > To me it certainly looks like a <before we freeze Pharo 8 we have to speed up with features> to get things in > by all means. Have to admit I had this kind of "panic mode" myself several times in the past too ;) > > Stef writes he now does not have the time nor energy - which I guess (including his reactions) is a tribute to his workload. > But then it would have been better to change to new Elumineire or getting rid of GTEventRecorder in Pharo 9 and now just marking > them for later exclusion. Because often we all underestimate the depencies, side effects, migration costs - even the reactions. > > Meanwhile Pharo is not only the base image - it is the full ecosystem around it which is good and a positive sign and > something we IMHO need to respect more and more. > > One has to understand that by just removing and not using deprecation the situation is getting worse and now pulling > more time and energy from other parts of the community too. Because broken stuff like Spotter, Settings, Roassal, Moose, ... > would need repair > - either directly (to help contributors who use them in P8 alpha already to give quick feedback) > - together with the Pharo 8 release so they can be used > - after Pharo 8 is released (which would be very late and might include migration surprises) > > Depreaction would help us better managing such transitions and is something that is standard in other languages too. > > The alternative would be to say this is OPP (other peoples problem) and completely ignoring that projects are built on top > of Pharo base. We all know removing leads to being incompatible and is not helpful in offering a transition path - therefore not > a good option. Because then users would always need to start from scratch with each Pharo release and loose interest quickly. > > Users want to do both: use Pharo and move their projects without having to focus on changed infrastructure > too often. Deprecation would give more room to fixing it- we have theses mechanisms like deprecations and we should really use them. > > In the past we were able to move more freely - but now we should really accept that with more users we have to > follow certain backwards compatibility and more clear rules. This slows us down yes and requires more time > and energy. But it is still a good thing because Pharo is actually used and the community can grow. > > We can not move Pharo into the "perfect" future with a crowbar as this would mean to loose users and especially > trust into the system. We might then still come up with an improved (but still imperfect) system in a few years - > but nobody would be interested anymore. If we fail to see things from the POV of the user then we will fail overall and loose them. > > I agree with Benoit that especially business users first have to solve the customers problems before they > can juggle with migrations. So lets support the overall community and not being ignorant to it. > So far we all managed it quite good: moving from Pharo 6 to 7 and even Pharo 8 is working because things over the last > releases stabilized and also because we added more rules, depreactions, transformations and helping users. > > I personally would prefer to see that "Pharo is not perfect but strong and widely used" than "look how cool it could have been", > so lets not get too impatient. Step by step - sometimes faster sometimes slower... > > Thanks > T. > |
|
|
On Thu, Nov 28, 2019 at 6:14 AM Sven Van Caekenberghe <[hidden email]> wrote:
> > This is all true, BUT ... > > Very few people attempt to do fundamental changes/cleanups/subsystem-replacements in the core image. This all true, BUT ... :-) > This takes a lot of work, is never easy and almost always has issues. This is exactly why you "roll out" features. > Resources are limited as well, in theory things can be done better, in practice in the real world, not so much. Resources are limited to everyone, commercial vendors, sponsored ones like Pharo and, last but not least, "users" [1]. [1] That, like me, read these discussions and only participate in the list because sometimes they seem biased because of a lack of consideration/feedback. I won't argue against the enormous progress and things being done by the whole Pharo team, but IMO minimizing the use of resources (time/effort) as a whole is more an objective than a resources thing. > The alternative is to never touch anything and stay stagnant. This is a false dichotomy. But can't deny its punch. :-) Regards, Esteban A. Maringolo |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |