December 2016 - Pharo-dev - lists.pharo.org

Fogbugz admin - please add Pharo 7 milestone

by Ben Coman

Just taking a browse through open tickets for Pharo 6, and maybe some can be bumped to Pharo 7 (rather than just "Later"). Could we have a Fogbugz milestone for it? cheers -ben

Dec. 7, 2016

Re: [Pharo-dev] How to report website text bugs?

by Ben Coman

On Thu, Dec 1, 2016 at 2:21 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Am 01.12.2016 12:30 vorm. schrieb "Ben Coman" <btc(a)openinworld.com>: >> >> On Wed, Nov 30, 2016 at 7:37 PM, Henrik Nergaard <henrik.nergaard(a)uia.no> >> wrote: >> > SystemNavigation new allLocalCallsOn: 'No change' ofClass: ProtoObject . >> > >> > "a Set(Delay class>>#delaySchedulerClass:)" >> >> That is only called from two places: >> * DelayBenchmark>>bench: >> * Delay class >> systemSettingOn: >> so it is curious that #delaySchedulerClass: is being invoked. >> >> > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >> > Esteban Lorenzano >> > Sent: Wednesday, November 30, 2016 12:14 PM >> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> > Subject: Re: [Pharo-dev] How to report website text bugs? >> > >> > >> > On 30 Nov 2016, at 12:09, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> > On 30 Nov 2016, at 11:26, Tim Mackinnon <tim(a)testit.works> wrote: >> > >> > I just tried the new example on the website (factorial is a great >> > example >> > from the command line - I like it). >> > >> > The output is: >> > >> > $ ./pharo Pharo.image eval "42 factorial" >> > 'No change' >> > 1405006117752879898543142606244511569936384000000000 >> > >> > Out of curiosity, What is the âNo Changeâ message above the answer? >> > no idea :) >> > obviouslyâ¦ a remaining error :P >> > and btwâ¦ thatâs obviously a transcript message. >> >> actually an #inform: >> >> >> >> >> On Thu, Dec 1, 2016 at 12:14 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > Tim, >> > >> >> On 30 Nov 2016, at 11:26, Tim Mackinnon <tim(a)testit.works> wrote: >> >> >> >> I just tried the new example on the website (factorial is a great >> >> example from the command line - I like it). >> >> >> >> The output is: >> >> >> >> $ ./pharo Pharo.image eval "42 factorial" >> >> 'No change' >> >> 1405006117752879898543142606244511569936384000000000 >> >> $ >> >> >> >> Out of curiosity, What is the âNo Changeâ message above the answer? >> > >> > What version are you using, I just tried (on macOS 10.12.1), in a >> > terminal: >> > >> > prometheus:pharo6 sven$ curl get.pharo.org/60+vm | bash >> > % Total % Received % Xferd Average Speed Time Time Time >> > Current >> > Dload Upload Total Spent Left >> > Speed >> > 100 2901 100 2901 0 0 2565 0 0:00:01 0:00:01 --:--:-- >> > 2571 >> > Downloading the latest 60 Image: >> > http://files.pharo.org/get-files/60/pharo.zip >> > Pharo.image >> > Downloading the latest pharoVM: >> > http://files.pharo.org/get-files/60/pharo-mac-stable.zip >> > pharo-vm/Pharo.app/Contents/MacOS/Pharo >> > Downloading PharoV60.sources: >> > http://files.pharo.org/get-files/60/sources.zip >> > Creating starter scripts pharo and pharo-ui >> > >> > prometheus:pharo6 sven$ ./pharo Pharo.image printVersion >> > [version] 6.0 #60311 >> > >> > prometheus:pharo6 sven$ ./pharo Pharo.image eval '42 factorial' >> > 1405006117752879898543142606244511569936384000000000 >> > >> > Works like a charm. I assume it works on Linux too. >> >> I just tried the same with new download of Pharo 5 and it worked >> without outputting 'No change' >> cheers -ben >> > > It depends on your user settings. If and what set of user settings were > exported. And maybe, if there is a set if user settings in the old format. Nice pick up. Better to be less verbose... https://pharo.fogbugz.com/default.asp?19428 cheers -ben

Dec. 7, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Ben Coman

How about mostly keeping the existing behaviour, but default to collisions being deselected? Then at least you don't need to search for it. It minimises the chance of missing it by mistake. The deselected item easily stands out to be reselected if required. P.S. An additional side idea: If collision is from a superclass then append (Superclass>>name) to the list item, and clicking on it shows a code dialog to the right similar to Spotter code review pane, to make a review easier. cheers -ben On Tue, Dec 6, 2016 at 10:09 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > It shouldnât be too intelligent. Keep the default behavior, and for each > method add a 3-state checkbox: create (default), skip, force (override). > Also having a usage recorder would be nice to know if developers are > actually checking the other state more often than the default one. > > Uko > > On 6 Dec 2016, at 13:03, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2016-12-06 11:34 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> >> 2016-12-06 11:28 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >>> >>> Additionally it was annoying if a superclass has a method with the same >>> name. For example if you have a name var and you create accessors Iâd like >>> to have actually a ânameâ getter and not âname1â >> >> >> Yes >> > > If you start to make it so intelligent it requires half a dozen click to > generate a simple accessor, then people will stop using the refactoring and > write the code by hand... > > Thierry > > >

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by stepharong

>> That isnât a refactoring. The existing methods arenât accessors. The >> refactoring will find accessors for the variables if they exist (even >> if they have a different names). >> >> We all know what is refactoring. Usually we don't care about safe >> aspect of it (and we have tests). We just want simple code >> transformation. I think it is exactly such case. > > âWe allâ probably donât agree on much. In fact, I think many people > would argue that the âsafe aspectâ is a very important part of a > refactoring. Otherwise, they shouldnât be called refactorings, but > should instead be called transformations. If you call something a > ârefactoringâ but donât do basic checks on its validity then that is > just wrong. Yes this is why we are working on proposing refactorings and transformations. We are currently refactoring the refactorings to have both transformations and refactorings.

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by John Brant

> On Dec 6, 2016, at 10:53 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-12-06 17:16 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > > For me it is too intelligent now because it is tried to create new version of accessors instead of existing one. > > But simple logic should just analyze method name and if accessor already exists it should skip it > > That isnât a refactoring. The existing methods arenât accessors. The refactoring will find accessors for the variables if they exist (even if they have a different names). > > We all know what is refactoring. Usually we don't care about safe aspect of it (and we have tests). We just want simple code transformation. I think it is exactly such case. âWe allâ probably donât agree on much. In fact, I think many people would argue that the âsafe aspectâ is a very important part of a refactoring. Otherwise, they shouldnât be called refactorings, but should instead be called transformations. If you call something a ârefactoringâ but donât do basic checks on its validity then that is just wrong. > Also after applying override browser shows it with special icon. And user could see it. Assuming that you didnât override something that is an essential part of the image. For example, try overriding the class side method #name to return nil and tell me how the special icon works. > > New accessors canât override an existing method, for example #name, since that would change the behavior of the #name method for that object. If you are suggesting not creating the accessor method for the âmyInstVar ^myInstVar ifNil: [#someValue]â method, then youâll need to change the abstract variable refactorings so that they no longer use the modified create accessors refactoring. > > We could make it configurable. "Manually" accessors will be generated in simplified mode and related refactorings will use intelligent mode My personal preference would be to ask the user what to do when performing the accessor refactoring. If the class hierarchy already has a method with the name of the variable, we can look at that method and determine what to do. In the case of #name, we could see that it is defined in a superclass and ask if it is ok to override the method (likely a good choice, but not always so it is good to confirm with the user). If the class directly defines the method, and that method has a return that returns the variable, then we can ask if they want to use that method as the âaccessorâ even though it does some other stuff (and potential returns a different value). Finally, if some subclass defines the method, then we can ask if they want to create that method even though some subclass is overriding it. Of course, we could have any combination of all three too. If they want a different method, then we should ask what to name the method instead of appending a number to the name. Currently, the extract method works similarly. If you enter an existing hierarchy method name, it warns you that you could be changing the behavior and asks if that is what you want to do. By asking the user, we can confirm that is what they really want to do, and also let them know of the potential problems that they may not have been aware of. John Brant

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Nicolai Hess

2016-12-06 17:53 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-12-06 17:16 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > >> > For me it is too intelligent now because it is tried to create new >> version of accessors instead of existing one. >> > But simple logic should just analyze method name and if accessor >> already exists it should skip it >> >> That isnât a refactoring. The existing methods arenât accessors. The >> refactoring will find accessors for the variables if they exist (even if >> they have a different names). >> > > We all know what is refactoring. Usually we don't care about safe aspect > of it (and we have tests). We just want simple code transformation. I think > it is exactly such case. > Also after applying override browser shows it with special icon. And user > could see it. > > >> >> New accessors canât override an existing method, for example #name, since >> that would change the behavior of the #name method for that object. If you >> are suggesting not creating the accessor method for the âmyInstVar >> ^myInstVar ifNil: [#someValue]â method, then youâll need to change the >> abstract variable refactorings so that they no longer use the modified >> create accessors refactoring. > > > We could make it configurable. "Manually" accessors will be generated in > simplified mode and related refactorings will use intelligent mode > The whole refactoring engine is pretty well written, we should take care to not fix the wrong places (this has been done already in the past by people (including me) not understanding the framework well enough).

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Nicolai Hess

2016-12-06 17:16 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > > > On Dec 6, 2016, at 8:25 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > > > 2016-12-06 15:09 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > It shouldnât be too intelligent. Keep the default behavior, and for each > method add a 3-state checkbox: create (default), skip, force (override). > Also having a usage recorder would be nice to know if developers are > actually checking the other state more often than the default one. > > > > For me it is too intelligent now because it is tried to create new > version of accessors instead of existing one. > > But simple logic should just analyze method name and if accessor already > exists it should skip it > > That isnât a refactoring. The existing methods arenât accessors. The > refactoring will find accessors for the variables if they exist (even if > they have a different names). > > New accessors canât override an existing method, for example #name, since > that would change the behavior of the #name method for that object. If you > are suggesting not creating the accessor method for the âmyInstVar > ^myInstVar ifNil: [#someValue]â method, then youâll need to change the > abstract variable refactorings so that they no longer use the modified > create accessors refactoring. Otherwise you can change behavior. For > example, code such as âmyInstVar ifNil: [#someOtherValue]â would no longer > be able to return #someOtherValue and would instead return #someValue. > > My personal preference would be to request some additional input from the > user in these cases. I donât know if the 3-state checkbox or something else > would be best. Anyway, we chose adding a number to the end of the name so > that these methods would be easy to rename since they would have a low > likelihood of conflicting with already existing method names. For example, > no one implements #name1 in my image. > > BTW, it appears that someone changed the refactoring errors to be > information messages that are displayed at the bottom (and quickly go away > and sometimes appear behind your browser or other windows). Yes, this is really bad. I tried to fix this but it is not taht easy. (And what is even worse, in the meantime some refactoring precondition were changed to work with this behavior (Ok, I am not totally innocent, some of that changes are from me, because it took some time to understand how the refactoring preconditions and refactoring errors are working)) But we should change this to a real error handling. > This allows someone to perform a refactoring that failed its > preconditions. If you are not looking at the bottom of the screen when the > message appears you think everything is fine when it isnât. For example, it > let me perform the abstract class variable refactoring on DependentFields > in Object (which breaks your image). Also, since the refactorings were > written so that an error stopped the refactoring from running, you can now > get debuggers when some future step of the refactoring is being executed > when it should be executed. For example, try extracting some code with a > return that isnât the last part of a method: > > foo > self someTest ifTrue: [ ^true ]. > ^false > > If you try to extract the first line, you get an information notice at the > bottom that you canât extract the code since it has a return, but the > extract method keeps running, and you get a debugger when the refactoring > is being performed on something that failed the preconditions. > > > John Brant >

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by stepharong

>> For me it is too intelligent now because it is tried to create new >> version of accessors instead of existing one. >> But simple logic should just analyze method name and if accessor >> already exists it should skip it > > That isnât a refactoring. The existing methods arenât accessors. The > refactoring will find accessors for the variables if they exist (even if > they have a different names). We all know what is refactoring. Usually we don't care about safe aspect of it (and we have tests). We just want simple code transformation. I think it is exactly such case. + 1 Often I get a popup telling me something that I do not understand and I ended doing all the changes. So if the situation is refactoring or doit by hand I prefer automatic transformations under my responsibilities because else I have to do it by hand. I like the idea of the radio buttons to control the behavior. > Also after applying override browser shows it with special icon. And > user could see it. > >> >> New accessors canât override an existing method, for example #name, >> since that would change the behavior of the #name method for that >> object. If you are suggesting not creating the accessor >>method for >> the âmyInstVar ^myInstVar ifNil: [#someValue]â method, then youâll need >> to change the abstract variable refactorings so that they no longer use >> the modified create accessors >>refactoring. > > We could make it configurable. "Manually" accessors will be generated in > simplified mode and related refactorings will use intelligent mode -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Denis Kudriashov

2016-12-06 17:16 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > > For me it is too intelligent now because it is tried to create new > version of accessors instead of existing one. > > But simple logic should just analyze method name and if accessor already > exists it should skip it > > That isnât a refactoring. The existing methods arenât accessors. The > refactoring will find accessors for the variables if they exist (even if > they have a different names). > We all know what is refactoring. Usually we don't care about safe aspect of it (and we have tests). We just want simple code transformation. I think it is exactly such case. Also after applying override browser shows it with special icon. And user could see it. > > New accessors canât override an existing method, for example #name, since > that would change the behavior of the #name method for that object. If you > are suggesting not creating the accessor method for the âmyInstVar > ^myInstVar ifNil: [#someValue]â method, then youâll need to change the > abstract variable refactorings so that they no longer use the modified > create accessors refactoring. We could make it configurable. "Manually" accessors will be generated in simplified mode and related refactorings will use intelligent mode

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by John Brant

> On Dec 6, 2016, at 8:25 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-12-06 15:09 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > It shouldnât be too intelligent. Keep the default behavior, and for each method add a 3-state checkbox: create (default), skip, force (override). Also having a usage recorder would be nice to know if developers are actually checking the other state more often than the default one. > > For me it is too intelligent now because it is tried to create new version of accessors instead of existing one. > But simple logic should just analyze method name and if accessor already exists it should skip it That isnât a refactoring. The existing methods arenât accessors. The refactoring will find accessors for the variables if they exist (even if they have a different names). New accessors canât override an existing method, for example #name, since that would change the behavior of the #name method for that object. If you are suggesting not creating the accessor method for the âmyInstVar ^myInstVar ifNil: [#someValue]â method, then youâll need to change the abstract variable refactorings so that they no longer use the modified create accessors refactoring. Otherwise you can change behavior. For example, code such as âmyInstVar ifNil: [#someOtherValue]â would no longer be able to return #someOtherValue and would instead return #someValue. My personal preference would be to request some additional input from the user in these cases. I donât know if the 3-state checkbox or something else would be best. Anyway, we chose adding a number to the end of the name so that these methods would be easy to rename since they would have a low likelihood of conflicting with already existing method names. For example, no one implements #name1 in my image. BTW, it appears that someone changed the refactoring errors to be information messages that are displayed at the bottom (and quickly go away and sometimes appear behind your browser or other windows). This allows someone to perform a refactoring that failed its preconditions. If you are not looking at the bottom of the screen when the message appears you think everything is fine when it isnât. For example, it let me perform the abstract class variable refactoring on DependentFields in Object (which breaks your image). Also, since the refactorings were written so that an error stopped the refactoring from running, you can now get debuggers when some future step of the refactoring is being executed when it should be executed. For example, try extracting some code with a return that isnât the last part of a method: foo self someTest ifTrue: [ ^true ]. ^false If you try to extract the first line, you get an information notice at the bottom that you canât extract the code since it has a return, but the extract method keeps running, and you get a debugger when the refactoring is being performed on something that failed the preconditions. John Brant

Dec. 6, 2016