- Pharo-dev - lists.pharo.org

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

[pharo-project/pharo-core]

by GitHub

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

Sept. 7, 2015

[pharo-project/pharo-core] 0acdab: 50311

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 0acdab79aac87eca75f566c14f77b99cd2ca2ff3 https://github.com/pharo-project/pharo-core/commit/0acdab79aac87eca75f566c1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-07 (Mon, 07 Sep 2015) Changed paths: M Nautilus.package/ClassWidget.class/instance/private list model/dropInClass_inARow_.st M Nautilus.package/NautilusUI.class/instance/drag and drop/dropMethod_inARow_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50310.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50311.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50310.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50311.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/NewVersionBrowser.class/instance/instance creation/browseVersionsOf_.st M Spec-Tools.package/NewVersionBrowser.class/instance/instance creation/browseVersionsOf_class_meta_category_selector_.st M Spec-Tools.package/NewVersionBrowser.class/instance/instance creation/revert_.st A Spec-Tools.package/NewVersionBrowser.class/instance/private/setRGMethodFrom_.st M Tool-Catalog.package/CatalogBrowser.class/README.md R Tool-Catalog.package/CatalogBrowser.class/instance/actions/defineAllRepositoriesInMCBrowser.st R Tool-Catalog.package/CatalogBrowser.class/instance/actions/defineCurrentVersionRepositoryInMCBrowser.st A Tool-Catalog.package/CatalogBrowser.class/instance/building/installStableVersionButton_.st A Tool-Catalog.package/CatalogBrowser.class/instance/building/installStableVersionMenuItem_.st A Tool-Catalog.package/CatalogBrowser.class/instance/building/loadConfigurationButton_.st A Tool-Catalog.package/CatalogBrowser.class/instance/building/loadConfigurationMenuItem_.st R Tool-Catalog.package/CatalogBrowser.class/instance/menu/defineAllRepositoriesInMCBrowserButton_.st R Tool-Catalog.package/CatalogBrowser.class/instance/menu/defineCurrentVersionRepositoryButton_.st R Tool-Catalog.package/CatalogBrowser.class/instance/menu/installStableVersionButton_.st R Tool-Catalog.package/CatalogBrowser.class/instance/menu/installStableVersionMenuItem_.st R Tool-Catalog.package/CatalogBrowser.class/instance/menu/loadConfigurationButton_.st R Tool-Catalog.package/CatalogBrowser.class/instance/menu/loadConfigurationMenuItem_.st R Tool-Catalog.package/CatalogBrowser.class/instance/private - utilities/availableRepositoryURLStrings.st M Tool-Catalog.package/CatalogBrowser.class/instance/private - utilities/buildContextMenuOn_.st R Tool-Catalog.package/CatalogBrowser.class/instance/private - utilities/repositoryObjectFromURLString_.st M Tool-Catalog.package/CatalogProject.class/README.md A Tool-Catalog.package/CatalogProject.class/class/accessing/repositoryNames.st R Tool-Catalog.package/CatalogProject.class/class/accessing/repositoryURLToNameMappings.st R Tool-Catalog.package/CatalogProject.class/class/private/availableRepositoryURLStrings.st A Tool-Catalog.package/CatalogProject.class/class/private/createRepositoryNames.st R Tool-Catalog.package/CatalogProject.class/class/private/createRepositoryURLtoNameMappings.st R Tool-Catalog.package/CatalogProject.class/class/private/pharoCurrentDottedName.st R Tool-Catalog.package/CatalogProject.class/class/private/pharoCurrentMajorName.st R Tool-Catalog.package/CatalogProject.class/class/private/pharoDistributionRepository.st M Tool-Catalog.package/CatalogProject.class/instance/accessing/allKeywords.st A Tool-Catalog.package/CatalogProject.class/instance/accessing/repository.st R 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: ----------- 50311 16504 NewVersionBrowser and RGMethodDefinition vs. CompiledMethod https://pharo.fogbugz.com/f/cases/16504 16496 Provide context menu icons in Catalog browser https://pharo.fogbugz.com/f/cases/16496 16487 Dropping methods on empty areas of class/method category pane raises SubscriptOutOfBounds https://pharo.fogbugz.com/f/cases/16487 http://files.pharo.org/image/50/50311.zip

Sept. 7, 2015

Re: [Pharo-dev] Did no find yet a way to reproduce QA concurrent access

by Marcus Denker

> On 07 Sep 2015, at 22:07, stepharo <stepharo(a)free.fr> wrote: > > I'm not complaining. I know that there is a good chance that we break the system when improving it. > I have no problem with that and I prefer a living system with some bugs for a while than a dead system with no bug :) exactly. For me, Pharo was exactly that: Imagine instead of ânot doing anything because we could do betterâ we would just do, as trivial and wrong as it our limits allow, but then learn from the mistakes and repeatâ¦ and, important, this in a way that the improvement âfeeds backâ into the system to have a direct impact on the next iteration. There are multiple feedback loops: - you only learn when you do. And most when you do it wrong. When you do the next thing it will be with more understanding and knowledge. If you do nothing because what you can do might be not perfect, you will just end with nothing. - As we improve the system we use, every tiny improvement has an impact on the next improvement. The âThis is just a 2% boring improvementâ is part of an exponential growth process if it happens in such a feedback loop. - The artefact that you see is not the goal. Itâs just a stepping stone towards. It will be ugly and imperfect, it will contain parts that are even not meant to be ever âniceâ as they are just scaffolding. They are there to help us build something else. â¦.. Marcus

Sept. 7, 2015

Re: [Pharo-dev] chunk file format (unrecoverable changes)

by Nicolai Hess

2015-09-07 20:10 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Sun, Sep 6, 2015 at 12:56 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Do we have a documentation about the format of >> - class definitions >> - methods >> - class comments >> for the changes file ? >> > > > Google "specification of smalltalk chunk format" and you will see: > > Overviews: Chunk File Format > <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uac…> > Smalltalk Interchange Format - Draft Smalltalk Standard v1.9 > <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uac…> > The Smalltalk fileOut format - 1 > <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uac…> > > and more. > Thank you eliot (should have google that myself !) > > >> >> I am asking because some entries are using two separator >> "! !" >> and some only one >> "!" >> > > Indeed. It's in the spec. ! ! ends a run of methods in the same > protocol. ! ends a method or a doit, etc. Read the spec. > ah! grouping multiple methods for one protocol. > > > >> And we have a problem with the "Recover lost changes" browser >> (https://pharo.fogbugz.com/f/cases/16498/unrecoverable-changes) >> and I am not sure if this is a bug on the code importer >> or if it is a bug on how we write changes to the changes file. >> >> >> nicolai >> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Sept. 7, 2015

Re: [Pharo-dev] Did no find yet a way to reproduce QA concurrent access

by stepharo

may be this is the same. Le 7/9/15 12:32, Yuriy Tymchuk a Ã©crit : > Yes, I know, but Stef was referring to deleting a method. > > Also I donât really know how I can fix the stuff with instance > variable. I need to have a separate process in order not to slow down > the browsing in Nautilus. I have the impression that we see that the reflective should be thread safe :) No? May be you could check what is used and have a threadsafe wrapper (not since the rules can use many different infromation I guess that this is not practical to do it. In any case this is a really interested case. Food for thoughts as they say.

Sept. 7, 2015

Re: [Pharo-dev] Did no find yet a way to reproduce QA concurrent access

by stepharo

I'm not complaining. I know that there is a good chance that we break the system when improving it. I have no problem with that and I prefer a living system with some bugs for a while than a dead system with no bug :) I'm just trying to help handling this problem. This is alpha with all the risks. Stef Le 7/9/15 00:46, Yuriy Tymchuk a Ã©crit : > I think that it is related to how I was working with Nautilus announcements. Now as announcements are changed, I can improve that. Just give me a bit of time :) > > Uko > >> On 06 Sep 2015, at 22:17, stepharo <stepharo(a)free.fr> wrote: >> >> I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method >> but I failed. >> I got again this bug. >> What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. >> But I cannot reproduce it. >> >> Stef >> > >

Sept. 7, 2015

Re: [Pharo-dev] Did no find yet a way to reproduce QA concurrent access

by stepharo

Ok I will do it. Le 7/9/15 00:56, Yuriy Tymchuk a Ã©crit : > Also, when if this kind of error happens again, can you please fuel it out and sent it to me? Having a stack can be helpful in understanding. > > Uko > >> On 06 Sep 2015, at 22:17, stepharo <stepharo(a)free.fr> wrote: >> >> I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method >> but I failed. >> I got again this bug. >> What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. >> But I cannot reproduce it. >> >> Stef >> > >

Sept. 7, 2015