- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Aug. 31, 2015

Re: [Pharo-dev] NBMacShell

by Sean P. DeNigris

Noury Bouraqadi-2 wrote > I came accross NBMacShell that looks like an alternative to OSProcess. > However, I see no Window/Linux equivalent? IIRC, when NB first came out, I noticed NBWin32Shell, and wondered if I could do somthing similar for Mac, to be able to have basic OSProcess behavior without loading OSP. I now often use it for this purpose. The main limitation is that you can't get the output back (or I don't know how at least), so I usually > the output to a file if I need it. n.b. it's blocking unless you say otherwise e.g. by appending a '&' to the command. So there is a Windows and Mac version, and in fact, the Mac version implements #run: via the C library, so it should work fine in Linux AFAICT. If so, NBMacShell should properly be a subclass of NBUnixShell, which implements #open: in a Mac-specific way. HTH. ----- Cheers, Sean -- View this message in context: http://forum.world.st/NBMacShell-tp4847048p4847175.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 31, 2015

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

by Sean P. DeNigris

Nicolai Hess wrote > What does not work in 40608? TWM is also buggy in 4.0, but was working fine in 3.0, and I haven't tested in 5.0. When changing desktops, they flash back and forth, and sometimes won't change at all. We tried to add a deferred block, but it only partially fixed the problem. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Image-used-for-4-0-5-0-Build-50000-transition-tp48469… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 31, 2015

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