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

Re: [Pharo-dev] [Pharo-users] QualityAssistant v0.4

by Yuriy Tymchuk

It is coming ;) > On 23 Apr 2015, at 18:57, Ben Coman <btc(a)openinworld.com> wrote: > > Making code critics more visible --> expect a flood of opinions about the usefulness of rules and what they mean, and Uko should not be responsible for all of them :) This is an area where gathering usage statistics (similar to Spotter) might be very useful - if there was some way to record which rules people have issues with. > cheers -ben > > On Thu, Apr 23, 2015 at 12:06 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> wrote: > Hi ! > Your quality assistant say to me "repeated method in the superclass" > (If a class is overriding a method, it should use a different code. Is > meaningless to have a method in a class and in its superclass) but > i've 3 methods into my class and all overrides a method with "^ > shouldBeImplemented" in the superclass. > I think something is wrong with this warning :) > > > On 22 April 2015 at 16:45, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > > Good point, this brings up two problems. > > > > 1) The rule can improve detection by checking the type is the message is > > sent to self > > 2) Automatic fixing should display the changes and letting you decide > > whether you want to apply them. > > > > 1st will take some time. 2nd will be soon in QA :) > > > > Uko > > > > > > On 22 Apr 2015, at 16:33, Johan Fabry <jfabry(a)dcc.uchile.cl <mailto:jfabry@dcc.uchile.cl>> wrote: > > > > Some weird behavior in quality assistant. Have a look at this method: > > > > duplicateVar: aVarName > > > > self show: 'Var: ', aVarName, ' redefinition ignored'. > > > > This raises the issue: âUse cascaded nextPutAll:âs instead of #, in > > nextPutAll:â It also pops up the automatic rewrite icon, so I clicked on it > > to see how it would transform the code. Result: > > > > duplicateVar: aVarName > > self > > show: 'Var: ' , aVarName; > > show: ' redefinition ignored' > > > > Needless to say, thatâs not a behavior preserving transformation. > > > > > > On Apr 22, 2015, at 03:58, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > > > > Please give me a feedback about your experience, as I want to make it even > > more useful. Either write me an email, or open an entry at: > > https://github.com/Uko/QualityAssistant/issues <https://github.com/Uko/QualityAssistant/issues> > > > > > > > > > > ---> Save our in-boxes! http://emailcharter.org <http://emailcharter.org/> <--- > > > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/~jfabry> > > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > > > > > > -- > Cheers > Cyril Ferlicot > >

April 23, 2015

Re: [Pharo-dev] [Pharo-users] QualityAssistant v0.4

by Ben Coman

Making code critics more visible --> expect a flood of opinions about the usefulness of rules and what they mean, and Uko should not be responsible for all of them :) This is an area where gathering usage statistics (similar to Spotter) might be very useful - if there was some way to record which rules people have issues with. cheers -ben On Thu, Apr 23, 2015 at 12:06 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > Hi ! > Your quality assistant say to me "repeated method in the superclass" > (If a class is overriding a method, it should use a different code. Is > meaningless to have a method in a class and in its superclass) but > i've 3 methods into my class and all overrides a method with "^ > shouldBeImplemented" in the superclass. > I think something is wrong with this warning :) > > > On 22 April 2015 at 16:45, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Good point, this brings up two problems. > > > > 1) The rule can improve detection by checking the type is the message is > > sent to self > > 2) Automatic fixing should display the changes and letting you decide > > whether you want to apply them. > > > > 1st will take some time. 2nd will be soon in QA :) > > > > Uko > > > > > > On 22 Apr 2015, at 16:33, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > > > Some weird behavior in quality assistant. Have a look at this method: > > > > duplicateVar: aVarName > > > > self show: 'Var: ', aVarName, ' redefinition ignored'. > > > > This raises the issue: âUse cascaded nextPutAll:âs instead of #, in > > nextPutAll:â It also pops up the automatic rewrite icon, so I clicked on > it > > to see how it would transform the code. Result: > > > > duplicateVar: aVarName > > self > > show: 'Var: ' , aVarName; > > show: ' redefinition ignored' > > > > Needless to say, thatâs not a behavior preserving transformation. > > > > > > On Apr 22, 2015, at 03:58, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > > Please give me a feedback about your experience, as I want to make it > even > > more useful. Either write me an email, or open an entry at: > > https://github.com/Uko/QualityAssistant/issues > > > > > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > > > Johan Fabry - http://pleiad.cl/~jfabry > > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > > > > > > -- > Cheers > Cyril Ferlicot > >

April 23, 2015

[pharo-project/pharo-core]

by GitHub

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

April 23, 2015

[pharo-project/pharo-core] 54ae88: 50009

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 54ae881ebaaa1f40f5369cf6af2e3688ef86c166 https://github.com/pharo-project/pharo-core/commit/54ae881ebaaa1f40f5369cf6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-23 (Thu, 23 Apr 2015) Changed paths: M KernelTests.package/ClassTest.class/instance/testing/testClassRespectsPolymorphismWithTrait.st M Monticello.package/MCLazyVersionInfo.class/instance/initialization/initializeWithName_id_message_date_time_author_ancestors_stepChildren_.st M Monticello.package/MCVersionInfo.class/instance/initialization/initializeWithName_id_message_date_time_author_ancestors_stepChildren_.st M MonticelloGUI.package/MCFileRepositoryInspector.class/instance/accessing/selectedPackageAncestors.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script617.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script618.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50008.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50009.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50009 15372 forward port pharaoh: 15339 Monticello with spotter extension methods throws MNU errors when browsing packages in repos that don https://pharo.fogbugz.com/f/cases/15372 15380 Failing test: ClassTest.testClassRespectsPolymorphismWithTrait https://pharo.fogbugz.com/f/cases/15380 http://files.pharo.org/image/50/50009.zip

April 23, 2015

RPackage: 'accessing' vs 'all accessing' Protocol

by Sean P. DeNigris

What is the distinction of 'all accessing'? ----- Cheers, Sean -- View this message in context: http://forum.world.st/RPackage-accessing-vs-all-accessing-Protocol-tp482146… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 23, 2015

Re: [Pharo-dev] TClassDescription: Why #comment:?

by Sean P. DeNigris

Marcus Denker-4 wrote > Yes, we had in the past the problem that comments lost the stamps oftenâ¦ > I wanted to remove all cases where it puts > <historical> Okay, I created Issue 15389 "Class Comments: Never Create <historical> Stamps" Marcus Denker-4 wrote > Hmm.. strange. Maybe the notification is not done correctly? I'm having trouble reproducing it. Let's assume it was a fluke for now... ----- Cheers, Sean -- View this message in context: http://forum.world.st/TClassDescription-Why-comment-tp4821441p4821461.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 23, 2015

Re: [Pharo-dev] TClassDescription: Why #comment:?

by Marcus Denker

> On 23 Apr 2015, at 16:45, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sean P. DeNigris wrote >> When would we want that? > > And, AFAICT there are senders (out of the 24 total) who should be using the > stamp version - FileContentsBrowser>>#contents:notifying:, this will soon go away thankfullyâ¦ > AbstractNautilusUI>>#openCommentEditor:... > a comment: that sets a good default stamp should be good here, too, or not? Marcus

April 23, 2015

Re: [Pharo-dev] TClassDescription: Why #comment:?

by Marcus Denker

> On 23 Apr 2015, at 16:30, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > There is already #comment:stamp:. #comment: makes the stamp <historical>. > When would we want that? Or if it's a convenience method, maybe it should > pass `... stamp: Author changeStamp`? > Yes, we had in the past the problem that comments lost the stamps oftenâ¦ I wanted to remove all cases where it puts <historical> > Also, it seems that the result of neither of these messages shows up in MC > changes browser, even though they do go into the changes file and are > committed by MC... > Hmm.. strange. Maybe the notification is not done correctly? Marcus

April 23, 2015

Re: [Pharo-dev] TClassDescription: Why #comment:?

by Sean P. DeNigris

Sean P. DeNigris wrote > When would we want that? And, AFAICT there are senders (out of the 24 total) who should be using the stamp version - FileContentsBrowser>>#contents:notifying:, AbstractNautilusUI>>#openCommentEditor:... ----- Cheers, Sean -- View this message in context: http://forum.world.st/TClassDescription-Why-comment-tp4821441p4821442.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 23, 2015

TClassDescription: Why #comment:?

by Sean P. DeNigris

There is already #comment:stamp:. #comment: makes the stamp <historical>. When would we want that? Or if it's a convenience method, maybe it should pass `... stamp: Author changeStamp`? Also, it seems that the result of neither of these messages shows up in MC changes browser, even though they do go into the changes file and are committed by MC... ----- Cheers, Sean -- View this message in context: http://forum.world.st/TClassDescription-Why-comment-tp4821441.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 23, 2015