September 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Marcus Denker

> On 01 Sep 2015, at 09:51, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Yuriy had an idea that QualityAssistant would offer option to rewrite your code, when you are sending a deprecated message. > So you would have > > MyObject>>myMethod > self deprecated: 'whatevs' rule: RewriteToolRule > > and then in your code which sends this method, the QA would inform you of the deprecation and offer you rewrite. > This is safe (it shows Changes dialog first), and practical, because you can publish the rewrite rules as part of your code and users can update easily whenever they are ready. > Yes! Marcus

Sept. 1, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Peter UhnÃ¡k

Yuriy had an idea that QualityAssistant would offer option to rewrite your code, when you are sending a deprecated message. So you would have MyObject>>myMethod self deprecated: 'whatevs' rule: RewriteToolRule and then in your code which sends this method, the QA would inform you of the deprecation and offer you rewrite. This is safe (it shows Changes dialog first), and practical, because you can publish the rewrite rules as part of your code and users can update easily whenever they are ready. Peter On Tue, Sep 1, 2015 at 9:37 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 01 Sep 2015, at 09:30, Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > > > > > > Le 1 sept. 2015 Ã 08:35, Marcus Denker a Ã©crit : > > > >> > >>> On 01 Sep 2015, at 08:30, stepharo <stepharo(a)free.fr> wrote: > >>> > >>> I do not get why you want to link the rewrite engine with deprecation > at runtime. > >>> We should not have such dependencies. To me it is insane. > >>> > >> > >> > >> It can be made pluggable, of course. I donât want to have that there in > a way that it requires > >> the refactoring engine to be present all the time. > >> > >> If itâs there â> transform. If not â> do what it does now. > >> > >> But just think how much this simplifies the experience of people > loading old code into a new > >> Pharo version: it just keeps running and fixes itself! Itâs that kind > of things we need to be > >> able to evolve the system. > >> > >> Imagine, this is a functionality (I think) no other system has! > > > > I will not like a feature where it transforms my code without asking. > > Yes, I want to have a dialog as a default, too. It should have the > possibility to review, > to do your own change *and* to continue and turn off the dialog for future > transforms > of this session. > > But it is good to know that people donât think this is that important. The > result is that I will > deprecate things with far less guilt using the current scheme ;-) > > Marcus > > > >

Sept. 1, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Christophe Demarey

Le 1 sept. 2015 Ã 09:37, Marcus Denker a Ã©crit : > >> On 01 Sep 2015, at 09:30, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >> >> >> Le 1 sept. 2015 Ã 08:35, Marcus Denker a Ã©crit : >> >>> >>>> On 01 Sep 2015, at 08:30, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> I do not get why you want to link the rewrite engine with deprecation at runtime. >>>> We should not have such dependencies. To me it is insane. >>>> >>> >>> >>> It can be made pluggable, of course. I donât want to have that there in a way that it requires >>> the refactoring engine to be present all the time. >>> >>> If itâs there â> transform. If not â> do what it does now. >>> >>> But just think how much this simplifies the experience of people loading old code into a new >>> Pharo version: it just keeps running and fixes itself! Itâs that kind of things we need to be >>> able to evolve the system. >>> >>> Imagine, this is a functionality (I think) no other system has! >> >> I will not like a feature where it transforms my code without asking. > > Yes, I want to have a dialog as a default, too. It should have the possibility to review, > to do your own change *and* to continue and turn off the dialog for future transforms > of this session. perfect :) > But it is good to know that people donât think this is that important. The result is that I will > deprecate things with far less guilt using the current scheme ;-) with the support you will provide for deprecations, for sure, you will be able to deprecate a lot more things. People will care less because there will be support to convert their code.

Sept. 1, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Marcus Denker

> On 01 Sep 2015, at 09:30, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > > Le 1 sept. 2015 Ã 08:35, Marcus Denker a Ã©crit : > >> >>> On 01 Sep 2015, at 08:30, stepharo <stepharo(a)free.fr> wrote: >>> >>> I do not get why you want to link the rewrite engine with deprecation at runtime. >>> We should not have such dependencies. To me it is insane. >>> >> >> >> It can be made pluggable, of course. I donât want to have that there in a way that it requires >> the refactoring engine to be present all the time. >> >> If itâs there â> transform. If not â> do what it does now. >> >> But just think how much this simplifies the experience of people loading old code into a new >> Pharo version: it just keeps running and fixes itself! Itâs that kind of things we need to be >> able to evolve the system. >> >> Imagine, this is a functionality (I think) no other system has! > > I will not like a feature where it transforms my code without asking. Yes, I want to have a dialog as a default, too. It should have the possibility to review, to do your own change *and* to continue and turn off the dialog for future transforms of this session. But it is good to know that people donât think this is that important. The result is that I will deprecate things with far less guilt using the current scheme ;-) Marcus

Sept. 1, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Christophe Demarey

Le 1 sept. 2015 Ã 08:35, Marcus Denker a Ã©crit : > >> On 01 Sep 2015, at 08:30, stepharo <stepharo(a)free.fr> wrote: >> >> I do not get why you want to link the rewrite engine with deprecation at runtime. >> We should not have such dependencies. To me it is insane. >> > > > It can be made pluggable, of course. I donât want to have that there in a way that it requires > the refactoring engine to be present all the time. > > If itâs there â> transform. If not â> do what it does now. > > But just think how much this simplifies the experience of people loading old code into a new > Pharo version: it just keeps running and fixes itself! Itâs that kind of things we need to be > able to evolve the system. > > Imagine, this is a functionality (I think) no other system has! I will not like a feature where it transforms my code without asking. I would prefer that a diff browser pops up and asks me if changes are ok. Automatic rewrite of code often forgot to check some specific cases and you end with bugs in your code if there is no review. The idea is great but the choice of changing the code or not has to be in the user hands.

Sept. 1, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Marcus Denker

> On 01 Sep 2015, at 08:30, stepharo <stepharo(a)free.fr> wrote: > > I do not get why you want to link the rewrite engine with deprecation at runtime. > We should not have such dependencies. To me it is insane. > It can be made pluggable, of course. I donât want to have that there in a way that it requires the refactoring engine to be present all the time. If itâs there â> transform. If not â> do what it does now. But just think how much this simplifies the experience of people loading old code into a new Pharo version: it just keeps running and fixes itself! Itâs that kind of things we need to be able to evolve the system. Imagine, this is a functionality (I think) no other system has! Marcus

Sept. 1, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by stepharo

I do not get why you want to link the rewrite engine with deprecation at runtime. We should not have such dependencies. To me it is insane. Stef Le 31/8/15 10:18, Peter UhnÃ¡k a Ã©crit : > On Mon, Aug 31, 2015 at 8:41 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > But the tool of mark is a ui tool so why would you want to get a > tool to define a rule in your case? > > > You can use the UI to create the rule, but the application of the rule > can be scripted. > > Yes, it would be nice to have a tool for creating the rules. But > then, one can use Markâs tool as is > for this already now for creating the rewrite rule and then > copy-and-paste it. > An integration could make that even easier, but for me this is > good enough for now. > > > RewriteTool creates classes with the rules, so I don't see the need > for copy-pasting. > Why not just > > self deprecated: anExplanationString rule: > aRuleClassGeneratedByRewriteTool > > self

Sept. 1, 2015

Re: [Pharo-dev] [Issue Tracker] Help needed: 623 open issues

by Marcus Denker

> On 31 Aug 2015, at 19:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 31 Aug 2015, at 11:41, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hello, >> >> We have 623 open issues on the issue tracker. >> > > Down to 619. > Down to 610. It would be really nice if people could look at their old reports. With >600 open issues, I see it very very often that even if an issue has been already reported, people just never look for the old reports. They open new ones. Even if the existing one they open themselves a year ago. And it is me that then closes duplicates. We need to get that number down to a manageable size. Keep in mind that *every* open issue has a cost: it takes away man power form the others. Marcus

Sept. 1, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50294 Home: https://github.com/pharo-project/pharo-core

Sept. 1, 2015

[pharo-project/pharo-core] e696be: 50294

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: e696bef9b5a93f3ce46d14946e67a3171d28f5fc https://github.com/pharo-project/pharo-core/commit/e696bef9b5a93f3ce46d1494… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-01 (Tue, 01 Sep 2015) Changed paths: M ConfigurationOfShoreLineReporter.package/ConfigurationOfShoreLineReporter.class/instance/versions/stable_.st A ConfigurationOfShoreLineReporter.package/ConfigurationOfShoreLineReporter.class/instance/versions/version020_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50293.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50294.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50293.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50294.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M ShoreLine-Report-UI.package/SlReportPreDebugAction.class/instance/testing/appliesToDebugger_.st M ShoreLine-Report-UI.package/SlReportWindow.class/class/instance creation/forDebugger_.st M ShoreLine-Report-UI.package/SlReportWindow.class/instance/accessing/reportSummary.st R ShoreLine-Report-UI.package/SlReportWindow.class/instance/initialization/generateReport.st M ShoreLine-Report-UI.package/SlReportWindow.class/instance/initialization/initializeWidgets.st A ShoreLine-Report-UI.package/SlReportWindow.class/instance/initialization/updateReport.st M Slot.package/SlotClassBuilder.class/instance/private validating/validateClassName.st Log Message: ----------- 50294 16442 ShoreLine Reporter version 0.2.0 https://pharo.fogbugz.com/f/cases/16442 15307 Error message not clear when trying to create a class with a name without the first letter in upper case https://pharo.fogbugz.com/f/cases/15307 http://files.pharo.org/image/50/50294.zip

Sept. 1, 2015