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

Re: [Pharo-dev] ensure: and assignments RB Rule

by Eliot Miranda

If there's an error in the expression that is assigned to file, and the stack unwound, file won't have been assigned and the close will get sent to nil. The assignment to file should precede the block. Sent from my iPhone > On Aug 31, 2015, at 5:03 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Anyone? We may remove this rule if no one understands for what this is good for. > (if anyone knows, please comment that class). > > > > 2014-12-14 11:22 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >> >> 2014-11-30 20:54 GMT+01:00 stepharo <stepharo(a)free.fr>: >>> >>> thanks we should open a bug entry to improve the class comment of this rule. >>> Any taker? >>> >>> Stef >>> >>> Le 30/11/14 12:10, Thierry Goubier a Ã©crit : >> >> done >> 14618 >> Add a comment describing RBFileBlocksRule >> >> now I just need to have a good description for this rule. Please, can >> someone outline the discussion on this thread: >> - describe why code matching this rule is considered back practice >> - describe how the code could be rewritten. >> >> nicolai >> >> >>> >>>> Le 30/11/2014 12:01, Max Leske a Ã©crit : >>>>> >>>>>> On 30.11.2014, at 11:18, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>>>>> >>>>>> Le 30/11/2014 11:06, Max Leske a Ã©crit : >>>>>>> The code would look like this: >>>>>>> >>>>>>> [ | file | >>>>>>> file := StandardFileStream forceNewFileNamed: âfooâ. >>>>>>> file nextPutAll: âbarâ ] >>>>>>> ensure: [ file close ]. >>>>>>> >>>>>>> Why that is considered bad practice however, I canât tell. >>>>>> >>>>>> This one would fail because file is a temp to the block (and not visible to the ensure block). >>>>> >>>>> If it werenât visible, wouldnât the compiler raise an exception? >>>> >>>> In your example, yes. >>>> >>>> But the rule matched: >>>> >>>> | file | >>>> [ >>>> file := StandardFileStream forceNewFileNamed: âfooâ. >>>> file nextPutAll: âbarâ ] >>>> ensure: [ file close ]. >>>> >>>> (Hum: wouldn't the compiler complain of file might be nil in the ensure block?) >>>> >>>>>> Another problem is that, if you have a failure in forceNewFileNamed:, file is nil and the ensure: fail as well. >>>>> >>>>> True, but thatâs a problem this rule doesnât really cover I guess. That oneâs up to the developer. >>>> >>>> I would expect that rule to flag bad coding practices, and I think it does ;) >>>> >>>> Thierry >

Aug. 31, 2015

Re: [Pharo-dev] Does somebody use resumable test failures?

by Damien Cassou

Guillermo Polito <guillermopolito(a)gmail.com> writes: > We have a set of methods like > > #assert:description:resumable: > > That > - have no users besides the tests that test the feature (no real tests > using it) > - there are two implementations and the one in TAssertable is broken > (sends #isResumable: that has no implementors) > > Does somebody see some value in this method? Pillar uses them but I don't know why: testParseLevel1 | wiki text tree | wiki := '!foo'. tree := PRDocument new add: ((PRHeader new) level: 1; add: (PRText content: 'foo'); yourself); yourself. self assertWiki: wiki equalsTree: tree. assertWiki: aString equalsTree: aDocument "Assert that parsing aString results in aDocument." self assert: (self parser parse: aString) = aDocument description: aString resumable: true -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Aug. 31, 2015

[pharo-project/pharo-core] f4d6dd: 50291

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: f4d6dd89042689c049596dad21883068e6f56c5a https://github.com/pharo-project/pharo-core/commit/f4d6dd89042689c049596dad… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-31 (Mon, 31 Aug 2015) Changed paths: R Kernel.package/ClassCategoryReader.class/README.md R Kernel.package/ClassCategoryReader.class/definition.st R Kernel.package/ClassCategoryReader.class/instance/fileIn%2FOut/scanFrom_.st R Kernel.package/ClassCategoryReader.class/instance/private/setClass_category_.st R Kernel.package/ClassCategoryReader.class/instance/private/setClass_category_changeStamp_.st R Kernel.package/ClassCategoryReader.class/instance/private/theClass.st R Kernel.package/ClassCommentReader.class/README.md R Kernel.package/ClassCommentReader.class/class/instance creation/forClass_.st R Kernel.package/ClassCommentReader.class/definition.st R Kernel.package/ClassCommentReader.class/instance/fileIn%2FOut/scanFrom_.st R Monticello.package/MCRepository.class/instance/error handling/retryOnCredentialRequest_.st M Monticello.package/MCRepository.class/instance/storing/storeVersion_.st R MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/actions/retryOnCredentialRequest_.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/actions/storeDependencies_in_.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/actions/storeVersion_in_.st A MonticelloRemoteRepositories.package/MCHttpRepository.class/instance/actions/retryOnCredentialRequest_.st A MonticelloRemoteRepositories.package/MCHttpRepository.class/instance/storing/storeVersion_.st A Refactoring-Critics.package/RBLintRule.class/class/testing/isUsed.st A SUnit-Core.package/TestCase.class/class/testing/isUsed.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50290.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50291.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50290.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50291.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Support.package/extension/TBehavior/instance/isUsed.st Log Message: ----------- 50291 16370 retryOnCredentialRequest: introduces a lot of repeated code and dependencies into monticello https://pharo.fogbugz.com/f/cases/16370 16248 Remove unused ClassCategoryReader and ClassCommentReader https://pharo.fogbugz.com/f/cases/16248 16439 improve #isUsed a little https://pharo.fogbugz.com/f/cases/16439 http://files.pharo.org/image/50/50291.zip

Aug. 31, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 31, 2015

Re: [Pharo-dev] Image used for 4.0 -> 5.0 (Build 50000) transition

by Mariano Martinez Peck

Torsten, maybe it's related to ImageCleaner #cleanupForRelease and cleanupForProduction ? On Mon, Aug 31, 2015 at 3:42 AM, stepharo <stepharo(a)free.fr> wrote: > yes may be a cleanup. > > Le 31/8/15 01:00, Nicolai Hess a Ã©crit : > > Oh, thats funny. > > Maybe this comes from the release buidling process, (condense changes / > sources) anything that > resets some world state? > > 2015-08-30 22:29 GMT+02:00 Torsten Bergmann < <astares(a)gmx.de> > astares(a)gmx.de>: > >> Nicolai Hess wrote: >> >What does not work in 40608? >> >> What Julien describes in [1] when he uses Pharo 4 with DesktopManager. I >> use Pharo 5 >> and did not have this effect. >> >> To reproduce I used latest.zip from >> <http://files.pharo.org/vm/pharo/win/> >> http://files.pharo.org/vm/pharo/win/ >> one time with #40608 and one time with #50000 >> >> Gofer new >> smalltalkhubUser: 'TorstenBergmann' project: 'DesktopManager'; >> configuration; >> loadDevelopment. >> >> 1. Hit CTRL + D and then CTRL + A (which is "D"esktop "A"dd) >> 2. Hit CTRL + D and then CTRL + P (which is "D"esktop "P"revious). >> >> Now the windows on the first desktop are not usable anymore in 40608. >> They do >> not repaint. >> >> In Pharo #50000 or any newer Pharo 5 image this works without a problem. >> >> Bye >> T. >> >> [1] >> http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2015-August/02… >> >> > > > -- Mariano http://marianopeck.wordpress.com

Aug. 31, 2015

Re: [Pharo-dev] ensure: and assignments RB Rule

by Nicolai Hess

Anyone? We may remove this rule if no one understands for what this is good for. (if anyone knows, please comment that class). 2014-12-14 11:22 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > > 2014-11-30 20:54 GMT+01:00 stepharo <stepharo(a)free.fr>: >> >> thanks we should open a bug entry to improve the class comment of this >> rule. >> Any taker? >> >> Stef >> >> Le 30/11/14 12:10, Thierry Goubier a Ã©crit : > > > done > 14618 <https://pharo.fogbugz.com/default.asp?14618> > Add a comment describing RBFileBlocksRule > > now I just need to have a good description for this rule. Please, can > someone outline the discussion on this thread: > - describe why code matching this rule is considered back practice > - describe how the code could be rewritten. > > nicolai > > > >> >> Le 30/11/2014 12:01, Max Leske a Ã©crit : >>> >>>> >>>> On 30.11.2014, at 11:18, Thierry Goubier <thierry.goubier(a)gmail.com> >>>>> wrote: >>>>> >>>>> Le 30/11/2014 11:06, Max Leske a Ã©crit : >>>>> >>>>>> The code would look like this: >>>>>> >>>>>> [ | file | >>>>>> file := StandardFileStream forceNewFileNamed: âfooâ. >>>>>> file nextPutAll: âbarâ ] >>>>>> ensure: [ file close ]. >>>>>> >>>>>> Why that is considered bad practice however, I canât tell. >>>>>> >>>>> >>>>> This one would fail because file is a temp to the block (and not >>>>> visible to the ensure block). >>>>> >>>> >>>> If it werenât visible, wouldnât the compiler raise an exception? >>>> >>> >>> In your example, yes. >>> >>> But the rule matched: >>> >>> | file | >>> [ >>> file := StandardFileStream forceNewFileNamed: âfooâ. >>> file nextPutAll: âbarâ ] >>> ensure: [ file close ]. >>> >>> (Hum: wouldn't the compiler complain of file might be nil in the ensure >>> block?) >>> >>> Another problem is that, if you have a failure in forceNewFileNamed:, >>>>> file is nil and the ensure: fail as well. >>>>> >>>> >>>> True, but thatâs a problem this rule doesnât really cover I guess. That >>>> oneâs up to the developer. >>>> >>> >>> I would expect that rule to flag bad coding practices, and I think it >>> does ;) >>> >>> Thierry >>> >>> >>> >> >>

Aug. 31, 2015

Does somebody use resumable test failures?

by Guillermo Polito

We have a set of methods like #assert:description:resumable: That - have no users besides the tests that test the feature (no real tests using it) - there are two implementations and the one in TAssertable is broken (sends #isResumable: that has no implementors) Does somebody see some value in this method? https://pharo.fogbugz.com/f/cases/16373/Methods-called-but-not-implemented-… Guille

Aug. 31, 2015

[Issue Tracker] Help needed: 623 open issues

by Marcus Denker

Hello, We have 623 open issues on the issue tracker. We need more man power to get the number down. *ESPCECIALLY* please look at issues that you submitted or where you have been part of the discussion in the past. https://pharo.fogbugz.com/f/filters/57/All-newest-first <https://pharo.fogbugz.com/f/filters/57/All-newest-first> Every single issue closed is a step forward. We can only fix 623 issues if we start fixing one. Marcus

Aug. 31, 2015

[issue tracker] many issues marked "fixed upstream"

by Marcus Denker

Hi, We have again many issues that are in the state âfixed upstreamâ. it would be nice if maintainers of packages could make sure that changes get reviewed+integrated and the package updates in Pharo so we can close them. There is nothing gained by postponing this sync back. Marcus

Aug. 31, 2015

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

by Marcus Denker

> On 31 Aug 2015, at 10:18, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > 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 > good idea, this way the rule is reusable for a code critique rule (for those cases where it makes sense, e.g. for ifNotNil: yes, as it is likely unique, but for #at: on SmalltalkImage, no ;-) Marcus

Aug. 31, 2015