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

[pharo-project/pharo-core] cb6342: 50312

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: cb634202202449e568ea5a8ee049fa49b43dcaed https://github.com/pharo-project/pharo-core/commit/cb634202202449e568ea5a8e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-08 (Tue, 08 Sep 2015) Changed paths: M ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic versions/stable_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version08_.st M Morphic-Core.package/WorldState.class/class/world menu items/saveAs.st M Nautilus.package/AbstractNautilusUI.class/instance/private/runClassTests_notifying_.st M Nautilus.package/AbstractNautilusUI.class/instance/private/runTestsOfClass_notifying_.st A Polymorph-Widgets.package/TEasilyThemed.class/instance/services/fileSave_initialAnswer_extensions_path_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50311.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50312.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50311.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50312.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Catalog.package/CatalogBrowser.class/README.md A Tool-Catalog.package/CatalogBrowser.class/instance/actions/defineAllRepositoriesInMCBrowser.st A Tool-Catalog.package/CatalogBrowser.class/instance/actions/defineCurrentVersionRepositoryInMCBrowser.st R Tool-Catalog.package/CatalogBrowser.class/instance/building/installStableVersionButton_.st R Tool-Catalog.package/CatalogBrowser.class/instance/building/installStableVersionMenuItem_.st R Tool-Catalog.package/CatalogBrowser.class/instance/building/loadConfigurationButton_.st R Tool-Catalog.package/CatalogBrowser.class/instance/building/loadConfigurationMenuItem_.st A Tool-Catalog.package/CatalogBrowser.class/instance/menu/defineAllRepositoriesInMCBrowserButton_.st A Tool-Catalog.package/CatalogBrowser.class/instance/menu/defineCurrentVersionRepositoryButton_.st A Tool-Catalog.package/CatalogBrowser.class/instance/menu/installStableVersionButton_.st A Tool-Catalog.package/CatalogBrowser.class/instance/menu/installStableVersionMenuItem_.st A Tool-Catalog.package/CatalogBrowser.class/instance/menu/loadConfigurationButton_.st A Tool-Catalog.package/CatalogBrowser.class/instance/menu/loadConfigurationMenuItem_.st A Tool-Catalog.package/CatalogBrowser.class/instance/private - utilities/availableRepositoryURLStrings.st M Tool-Catalog.package/CatalogBrowser.class/instance/private - utilities/buildContextMenuOn_.st A Tool-Catalog.package/CatalogBrowser.class/instance/private - utilities/repositoryObjectFromURLString_.st M Tool-Catalog.package/CatalogProject.class/README.md R Tool-Catalog.package/CatalogProject.class/class/accessing/repositoryNames.st A Tool-Catalog.package/CatalogProject.class/class/accessing/repositoryURLToNameMappings.st A Tool-Catalog.package/CatalogProject.class/class/private/availableRepositoryURLStrings.st R Tool-Catalog.package/CatalogProject.class/class/private/createRepositoryNames.st A Tool-Catalog.package/CatalogProject.class/class/private/createRepositoryURLtoNameMappings.st A Tool-Catalog.package/CatalogProject.class/class/private/pharoCurrentDottedName.st A Tool-Catalog.package/CatalogProject.class/class/private/pharoCurrentMajorName.st A Tool-Catalog.package/CatalogProject.class/class/private/pharoDistributionRepository.st M Tool-Catalog.package/CatalogProject.class/instance/accessing/allKeywords.st R Tool-Catalog.package/CatalogProject.class/instance/accessing/repository.st A Tool-Catalog.package/CatalogProject.class/instance/accessing/repositoryName.st M Tool-Catalog.package/CatalogProject.class/instance/testing/isAvailableForCurrentPharo.st M Tool-Catalog.package/CatalogProvider.class/README.md Log Message: ----------- 50312 16496 Provide context menu icons in Catalog browser https://pharo.fogbugz.com/f/cases/16496 15374 exception handling when running tests in Nautilus https://pharo.fogbugz.com/f/cases/15374 16511 Smalltalk saveAs should include the current image name as the initial text in the file dialogue https://pharo.fogbugz.com/f/cases/16511 http://files.pharo.org/image/50/50312.zip

Sept. 8, 2015

garbage on transcript

by stepharo

Hi when I define methods and the Transcript is open I get such kind of trace and I do not get where it comes from. I think that this is the syntactical coloring. Would be good to avoid because this is annoying. StoreImporter>>messageSelectorAndArgumentNames (statements is Undeclared) UndefinedObject>>noMethod (messageSelectorAndArgumentNames is Undeclared) Stef

Sept. 8, 2015

Re: [Pharo-dev] ANSICompatibility package

by Ben Coman

On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > Hi, > > is there actually such a thing like ANSICompatibility package? > (it has been mentioned here lately, but I cannot find it) > > Thanks, Jan > I made it up for the purpose of discussion to see what interest it generated. Should we start one ? cheers -ben

Sept. 8, 2015

ANSICompatibility package

by Jan Vrany

Hi, is there actually such a thing like ANSICompatibility package? (it has been mentioned here lately, but I cannot find it) Thanks, Jan

Sept. 8, 2015

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

by Eliot Miranda

Sent from my iPhone > On Sep 7, 2015, at 2:16 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > *Now* I understand this rule. Hi Nicolai, points to the need for some very good doc for these rules :-) > > 2015-09-02 3:40 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >>> On Tue, Sep 1, 2015 at 1:29 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> Thank you all for your response, >>> now the interesting question is, what should this rule recommend to use instead? First assign to a block local variable and >>> add a nil check in the unwind block? >> >> No. I think the pattern modifies this: >> >> | t | >> ... >> [t := initExpr. >> exprs] >> ensure: [t msg] >> >> to this >> >> | t | >> ... >> t := initExpr. >> [exprs] >> ensure: [t msg] >> >> Control never reaches the block [exprs] isf there is an error in initExpr so there's no issue with t being unassigned; control won't get to the ensure block, so no need to test for nil. >> >>> >>> And maybe we should improve that rule, because in Pharo 5.0 there are 5 methods catched by >>> this rule: >>> 3 have an explicit ifnonil check before accessing the variable - their implementation actually behaves correctly. >>> The other two are just "testdata" used in the unit test for this rule >>> >>> >>> >>> 2015-08-31 15:30 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>> 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 >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >

Sept. 8, 2015

Re: [Pharo-dev] Nautilus strange pattern

by Ben Coman

On Tue, Sep 8, 2015 at 5:32 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > We should make sure to unregister to all announcement when the window is > closed. +1. Nautilus seems to leak announcements. Sorry I forgot to log an issue already for this... https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg31953.html So should I log a new issue now, or do you want to pick it up under existing work? cheers -ben > (Or is there any reason or situation in which nautilus can properly work > after the window is closed?) > > 2015-09-06 10:41 GMT+02:00 stepharo <stepharo(a)free.fr>: >> >> Hi >> >> I'm trying to understand what there is a need for this window ifNil: [^ >> self ] >> And I wonder is this is not problem due to a global announcer that would >> keep announcer even when the nautilus widget >> has been deleted. >> Any other suggestions? >> >> Stef >> >> classRemoved: anAnnouncement >> | class oldPackage | >> window ifNil: [ ^ self ]. >> window isDisplayed >> ifFalse: [ ^ self ]. >> class := anAnnouncement classRemoved. >> (self classWidget getClassesList includes: class) >> ifTrue: >> [ >> >> classRecategorized: anAnnouncement >> >> window ifNil: [ ^ self ]. >> window isDisplayed ifFalse: [ ^ self ]. >> self selectedPackage ifNotNil:[:selection | >> ({ anAnnouncement oldCategory. anAnnouncement newCategory } >> anySatisfy: [ :each | selection includesCategory: each ]) >> ifTrue: [ self updatePackageGroupAndClassList ]] >> >> >> classRemoved: anAnnouncement >> | class oldPackage | >> window ifNil: [ ^ self ]. >> window isDisplayed >> ifFalse: [ ^ self ]. >> class := anAnnouncement classRemoved. >> (self classWidget getClassesList includes: cla >> >

Sept. 7, 2015

Re: [Pharo-dev] Nautilus strange pattern

by Nicolai Hess

We should make sure to unregister to all announcement when the window is closed. (Or is there any reason or situation in which nautilus can properly work after the window is closed?) 2015-09-06 10:41 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi > > I'm trying to understand what there is a need for this window ifNil: [^ > self ] > And I wonder is this is not problem due to a global announcer that would > keep announcer even when the nautilus widget > has been deleted. > Any other suggestions? > > Stef > > classRemoved: anAnnouncement > | class oldPackage | > window ifNil: [ ^ self ]. > window isDisplayed > ifFalse: [ ^ self ]. > class := anAnnouncement classRemoved. > (self classWidget getClassesList includes: class) > ifTrue: > [ > > classRecategorized: anAnnouncement > > window ifNil: [ ^ self ]. > window isDisplayed ifFalse: [ ^ self ]. > self selectedPackage ifNotNil:[:selection | > ({ anAnnouncement oldCategory. anAnnouncement newCategory } > anySatisfy: [ :each | selection includesCategory: each ]) > ifTrue: [ self updatePackageGroupAndClassList ]] > > > classRemoved: anAnnouncement > | class oldPackage | > window ifNil: [ ^ self ]. > window isDisplayed > ifFalse: [ ^ self ]. > class := anAnnouncement classRemoved. > (self classWidget getClassesList includes: cla > >

Sept. 7, 2015

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

by Nicolai Hess

*Now* I understand this rule. 2015-09-02 3:40 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Tue, Sep 1, 2015 at 1:29 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Thank you all for your response, >> now the interesting question is, what should this rule recommend to use >> instead? First assign to a block local variable and >> add a nil check in the unwind block? >> > > No. I think the pattern modifies this: > > | t | > ... > [t := initExpr. > exprs] > ensure: [t msg] > > to this > > | t | > ... > t := initExpr. > [exprs] > ensure: [t msg] > > Control never reaches the block [exprs] isf there is an error in initExpr > so there's no issue with t being unassigned; control won't get to the > ensure block, so no need to test for nil. > > >> And maybe we should improve that rule, because in Pharo 5.0 there are 5 >> methods catched by >> this rule: >> 3 have an explicit ifnonil check before accessing the variable - their >> implementation actually behaves correctly. >> The other two are just "testdata" used in the unit test for this rule >> >> >> >> 2015-08-31 15:30 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> 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 <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 >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Sept. 7, 2015

Re: [Pharo-dev] GitFileTree with Project Template from GitHub

by Thierry Goubier

Le 07/09/2015 20:58, Peter UhnÃ¡k a Ã©crit : > MCFileTreeGitRemoteRepository > > > I was under the impression that Remote is read only because you cannot > commit directly to github; this is DCVS. No, remote works just like a normal gitfiletree repository, and it becomes read only if you use https as a protocol. MCFileTreeGitRemoteRepository is only there because: - you add the clone and branch to download the repository - and MC only allows one creation method per repository class. > What I do is that I have local copy of the git repo which is then loaded > into Pharo... But it is even easier to do something like: Metacello new baseline: 'SmaCC'; repository: 'gitfiletree://github.com/ThierryGoubier/SmaCC'; load Thierry > > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > Metacello new > baseline: 'BaslineOfMyProject'; > repository: 'gitfiletree:///path/to/my/git/repo'; > load. > ~~~~~~~~~~~~~~~~~~~~~ > > > On Mon, Sep 7, 2015 at 7:59 PM, Sean P. DeNigris <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>> wrote: > > Let's say you decide to port a repo from StHub to GitHub. Here's a > logical > workflow: > 1. Create a repo via the GitHub we interface so you get a nice > license file > and readme > 2. Create a MCFileTreeGitRemoteRepository as the destination for the > port. > For example: > (cloneFolder / 'repository') ensureCreateDirectory. > destination := MCFileTreeGitRemoteRepository > location: 'git@github.com:seandenigris/Superuser.git' > name: cloneFolder > subdirectory: 'repository' > branch: ''. > > Oops! I couldn't find a magic incantation to get #2 to work. Here is > what > seems to be the problem: If you specify the 'repository' > subdirectory, you > get an error that it doesn't exist (because there's no way to > autogenerate > empty directories from the GitHub web interface), but if you create it > before the clone, you get an error that the pre-existing cloneFolder > is not > a git repo. Catch 22! > > It would be nice if GitFileTree cloned the repo and then created the > subdirectory if needed. I hacked around a bit, but didn't get very > far :/ > > I ended up manually cloning and then creating a vanilla GitFileTree repo > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/GitFileTree-with-Project-Template-from-GitHub-tp48486… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Sept. 7, 2015

Re: [Pharo-dev] GitFileTree with Project Template from GitHub

by Thierry Goubier

Le 07/09/2015 19:59, Sean P. DeNigris a Ã©crit : > Let's say you decide to port a repo from StHub to GitHub. Here's a logical > workflow: > 1. Create a repo via the GitHub we interface so you get a nice license file > and readme > 2. Create a MCFileTreeGitRemoteRepository as the destination for the port. > For example: > (cloneFolder / 'repository') ensureCreateDirectory. > destination := MCFileTreeGitRemoteRepository > location: 'git@github.com:seandenigris/Superuser.git' > name: cloneFolder > subdirectory: 'repository' > branch: ''. > > Oops! I couldn't find a magic incantation to get #2 to work. Here is what > seems to be the problem: If you specify the 'repository' subdirectory, you > get an error that it doesn't exist (because there's no way to autogenerate > empty directories from the GitHub web interface), but if you create it > before the clone, you get an error that the pre-existing cloneFolder is not > a git repo. Catch 22! > > It would be nice if GitFileTree cloned the repo and then created the > subdirectory if needed. I hacked around a bit, but didn't get very far :/ Good point. It is doable with probably a single line (when opening the repository, ensure the target directory is created if it doesn't exist) > I ended up manually cloning and then creating a vanilla GitFileTree repo This work-around allways exist ;) I'll try and add an auto-creation if the target repository is missing. Thierry > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/GitFileTree-with-Project-Template-from-GitHub-tp48486… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Sept. 7, 2015