- Pharo-dev - lists.pharo.org

No longer valid issues

by Peter UhnÃ¡k

Sometimes I encounter issue that is no longer valid (has been fixed / changed / ... ) Do I mark it as a) Work Needed (Not Reproducible) but there's no more work needed b) Resolved (Fix Review Needed) with a comment that's no longer reproducible c) Resolved (Invalid) since it's no longer valid d) something else? Option b) makes probably most sense since someone just needs to review that it's truly not reproducible and close it. Or maybe option a), and change the "To Review" filter to also include this. There also seem to be quite large amount of stale issues... If someone didn't fix them nor even commented on them in years, maybe the issue should be let to die? If nobody is commenting on it, nobody is interested in it. If the issue pops up again, we can easily create fresh issue. Peter

Sept. 1, 2015

[Pharo4] Issues for review for Pharo4

by Marcus Denker

Hello, There are 4 issues for Pharo4 that need input: https://pharo.fogbugz.com/f/filters/45/Review <https://pharo.fogbugz.com/f/filters/45/Review> Marcus

Sept. 1, 2015

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

by Stephan Eggermont

On 01-09-15 08:35, Marcus Denker wrote: > 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. This is a crucial step to support continuous improvement indeed. Just-in-time repeatable refactoring, reducing the cost of change Stephan

Sept. 1, 2015

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