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

[pharo-project/pharo-core]

by GitHub

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

Sept. 3, 2015

[pharo-project/pharo-core] 770358: 50300

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 77035832f5bcfbf49f088eb2f0b20f9d865b6a29 https://github.com/pharo-project/pharo-core/commit/77035832f5bcfbf49f088eb2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-03 (Thu, 03 Sep 2015) Changed paths: M CodeImport.package/ChunkFileFormatParser.class/definition.st A CodeImport.package/ChunkFileFormatParser.class/instance/class factory/classCommentChunkClass.st A CodeImport.package/ChunkFileFormatParser.class/instance/class factory/classOrganisationChunkClass.st A CodeImport.package/ChunkFileFormatParser.class/instance/class factory/doItChunkClass.st A CodeImport.package/ChunkFileFormatParser.class/instance/class factory/methodChunkClass.st A CodeImport.package/ChunkFileFormatParser.class/instance/class factory/styleChunkClass.st A CodeImport.package/ChunkFileFormatParser.class/instance/custom points/classSelector.st A CodeImport.package/ChunkFileFormatParser.class/instance/custom points/classSelector_.st A CodeImport.package/ChunkFileFormatParser.class/instance/custom points/classTraitSelector.st A CodeImport.package/ChunkFileFormatParser.class/instance/custom points/classTraitSelector_.st A CodeImport.package/ChunkFileFormatParser.class/instance/custom points/commentStampSelector.st A CodeImport.package/ChunkFileFormatParser.class/instance/custom points/commentStampSelector_.st A CodeImport.package/ChunkFileFormatParser.class/instance/custom points/methodsForSelector.st A CodeImport.package/ChunkFileFormatParser.class/instance/custom points/methodsForSelector_.st A CodeImport.package/ChunkFileFormatParser.class/instance/custom points/reorganizeSelector.st A CodeImport.package/ChunkFileFormatParser.class/instance/custom points/reorganizeSelector_.st A CodeImport.package/ChunkFileFormatParser.class/instance/initialization/defaultClassSelector.st A CodeImport.package/ChunkFileFormatParser.class/instance/initialization/defaultClassTraitSelector.st A CodeImport.package/ChunkFileFormatParser.class/instance/initialization/defaultCommentStampSelector.st A CodeImport.package/ChunkFileFormatParser.class/instance/initialization/defaultMethodsForSelector.st A CodeImport.package/ChunkFileFormatParser.class/instance/initialization/defaultReorganizeSelector.st M CodeImport.package/ChunkFileFormatParser.class/instance/initialization/initialize.st M CodeImport.package/ChunkFileFormatParser.class/instance/parsing/parseChunks.st M CodeImport.package/ChunkFileFormatParser.class/instance/parsing/parseClassOrganization_.st M CodeImport.package/ChunkFileFormatParser.class/instance/parsing/parseCommentDeclaration_.st M CodeImport.package/ChunkFileFormatParser.class/instance/parsing/parseMethodDeclarations_.st M CodeImport.package/ChunkFileFormatParser.class/instance/parsing/parseNextDeclaration.st R Morphic-Base.package/MenuItemMorph.class/instance/accessing/itemWithWording_.st M Morphic-Base.package/MenuMorph.class/definition.st A Morphic-Base.package/MenuMorph.class/instance/accessing/defaultTarget_.st M Morphic-Base.package/MenuMorph.class/instance/accessing/embeddable.st M Morphic-Base.package/MenuMorph.class/instance/accessing/embeddable_.st R Morphic-Base.package/MenuMorph.class/instance/accessing/itemWithWording_.st A Morphic-Base.package/MenuMorph.class/instance/construction-title/addStayUpIcons.st A Morphic-Base.package/MenuMorph.class/instance/construction-title/addStayUpItem.st A Morphic-Base.package/MenuMorph.class/instance/construction-title/addTitle_.st A Morphic-Base.package/MenuMorph.class/instance/construction-title/addTitle_icon_.st A Morphic-Base.package/MenuMorph.class/instance/construction-title/newTitleIconCalling_form_ballonText_.st R Morphic-Base.package/MenuMorph.class/instance/construction/addStayUpIcons.st R Morphic-Base.package/MenuMorph.class/instance/construction/addStayUpItem.st R Morphic-Base.package/MenuMorph.class/instance/construction/addTitle_.st R Morphic-Base.package/MenuMorph.class/instance/construction/addTitle_icon_.st R Morphic-Base.package/MenuMorph.class/instance/construction/defaultTarget_.st A Morphic-Base.package/MenuMorph.class/instance/events/pinboxClicked.st R Morphic-Base.package/MenuMorph.class/instance/initialization/defaultBounds.st R Morphic-Base.package/MenuMorph.class/instance/keyboard control/selectMoreItem_.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/private-method/privateRemoveParameterMethodFor_.st M Refactoring-Core.package/RBRemoveParameterRefactoring.class/instance/transforming/getNewSelector.st A SUnit-UITesting.package/extension/MenuItemMorph/instance/itemWithWording_.st A SUnit-UITesting.package/extension/MenuMorph/instance/itemWithWording_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50299.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50300.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50299.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50300.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50300 16461 ChunkFileParser https://pharo.fogbugz.com/f/cases/16461 16459 Refactoring remove method parameter doesnt work https://pharo.fogbugz.com/f/cases/16459 16457 Minor improvements to MenuMorph https://pharo.fogbugz.com/f/cases/16457 http://files.pharo.org/image/50/50300.zip

Sept. 3, 2015

Re: [Pharo-dev] size of MCbrowser should be proportional

by Esteban Lorenzano

+1 I also submitted an issue about MCBrowser not taking into account the size of the world window (and then appearing with part of it hidden out of the visible area) > On 02 Sep 2015, at 10:07, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > now when I open MCBrowser it gets 80% of my window. > So this is good to make it larger but it should be proportional to the actual size. > > https://pharo.fogbugz.com/f/cases/16451/MCBrowser-default-size-should-propo… > Could the person that originally changed it fix it? > > Stef >

Sept. 3, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 91327c: 50299

by Marcus Denker

this is: 16464 Smart suggestion is broken https://pharo.fogbugz.com/f/cases/16464 16458 #instead for MethodNode https://pharo.fogbugz.com/f/cases/16458 16455 Spotter dying on not understanding #canUnderstand: https://pharo.fogbugz.com/f/cases/16455 <https://pharo.fogbugz.com/f/cases/16455> > > Log Message: > ----------- > 50299 > ConfigurationOfRubric > > http://files.pharo.org/image/50/50299.zip > >

Sept. 3, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 3, 2015

[pharo-project/pharo-core] 91327c: 50299

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 91327c96398da12d50ffe960fa8c88b99315b8e3 https://github.com/pharo-project/pharo-core/commit/91327c96398da12d50ffe960… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-03 (Thu, 03 Sep 2015) Changed paths: M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version1211_.st A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version307_.st M GT-Spotter-EventRecorder.package/GTSpotterEventRecorder.class/instance/events/recordAccouncement_.st A GT-Spotter-EventRecorder.package/GTSpotterEventRecorder.class/instance/events/recordAnnouncement_.st M GT-Spotter-EventRecorder.package/GTSpotterEventRecorder.class/instance/initialization/linkToSpotter_.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadMethod.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitMethodNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50298.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50299.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50298.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50299.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions.package/SugsNautilusContext.class/instance/refactoring/contentSelection.st M SmartSuggestions.package/SugsNautilusContext.class/instance/refactoring/flashSourceCodeArea.st M SmartSuggestions.package/SugsNautilusContext.class/instance/refactoring/formatSourceCode.st M SmartSuggestions.package/SugsNautilusContext.class/instance/refactoring/selectTheTextForTheNode.st M SmartSuggestions.package/SugsNautilusContext.class/instance/refactoring/selectionInterval.st Log Message: ----------- 50299 ConfigurationOfRubric http://files.pharo.org/image/50/50299.zip

Sept. 3, 2015

Re: [Pharo-dev] Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by Sven Van Caekenberghe

> On 03 Sep 2015, at 06:01, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > On 9/2/15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> But Timestamp was already removed completely from 4.0, why re-add it, even >> deprecated ? > > Because it will be added in a compatibility layer package which is > only loaded by packages which need it. There might be other things in > the Pharo 5/4 compatibility package. But still, if external packages do load that code, they will never have to change, and the class will remain in the image forever. It is like when you load certain Squeak packages that are 'ported' with compatibility layers to Pharo: they just add again all the methods that we tried to clean up. > --HH > >> I am sure many external packages are already modified, I know I did it for >> mine. > >>> On 02 Sep 2015, at 13:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> >>>> On 02 Sep 2015, at 12:32, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Hi guille >>>> >>>> there is not stress. I just wanted to let you know. >>>> I was wondering if just subclassing DateAndTime would not be enough for >>>> now. >>> >>> Yes, as far as I remember Timestamp was just an empy subclass. >>> >>> We could: >>> >>> -> add it back to Deprecated50 or maybe even to a âCompatibilityâ package >>> -> Write a Quality Check rule. >>> >>>> I will go back to code with Pharo 40 >>>> >>>> stef >>>> >>>> Le 2/9/15 10:30, Guillermo Polito a Ã©crit : >>>>> If somebody can check it and fix it it would be good :). I've just >>>>> started my new job and my evenings are busy looking for an apartment or >>>>> staying in a hostel without a proper internet connection... >>>>> >>>>> If not, I think we can wait a bit. The first step should be enabling CI >>>>> jobs for pharo5. Also, I do not think the intersection between 'people >>>>> using garage opendbx' and 'people using pharo5' is that big to justify a >>>>> rush. >>>>> >>>>> Guille >>>>> >>>>> El miÃ©., 2 de sept. de 2015 a la(s) 10:12 a. m., stepharo >>>>> <stepharo(a)free.fr> escribiÃ³: >>>>> for your info... >>>>> >>>>> Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp >>>>> >>>>> Stef >>>>> >>>> >>> >> >> >> >

Sept. 3, 2015

Re: [Pharo-dev] block brace alignment (Re: feedback from J Brant)

by Sven Van Caekenberghe

And what happened to the plain normal (in my mind/experience) ? self xxx ifTrue: [ self bla. self foo ]. I would say that is the most common one I've seen in the image. And it is how the old formatter worked. > On 03 Sep 2015, at 03:39, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Ben, > > have you read Kent Beck's formatting rules? I wish we would adhere to these in our formatters. And I wish he would put the formatting rules in the public domain on the web (Kent?). He actually justifies the rules he chooses; they're not just personal preferences. And IMO they produce eleant, readable Smalltalk. I have to say your block formatting below is horrible. Blocks are blocks. [ & ] are /not/ the same as { & } in C. [...] define an *object*, not merely delimit syntax. As such any good Smalltalk format will emphasize the objectness of blocks. And IMNERHO that is to make them rectangles as in > > self ifIWantedYouToWriteC ifTrue: > [self useABloodyCCompiler. > self useCCMinusPToMakeSenseOfTheDamageDoneByTheCPreProcessor] > > > On Wed, Sep 2, 2015 at 6:23 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Thu, Sep 3, 2015 at 2:28 AM, stepharo <stepharo(a)free.fr> wrote: > > > > I do not really like all the formattings of kent. Because sometimes it just > > does not work. > > But this is why we ask franck (an interns to start to have a look). > > > > For example I do not like > > > > self xxx > > ifTrue: > > [ > > self bla > > self foo. > > Agreed. Unneccessary waste of a line. > > > in the current default formatter. > > and I prefer > > > > self xxx > > ifTrue: [ self bla. > > self foo > > But here the problem is that the self foo is not tab aligned because > > ifTrue: [ > > > > self xxx > > ifTrue: > > [ self bla. > > self foo > > So may be this one is a nice compromise > > Not quite there. The "self bla" is still not actually vertically aligned. > > > I think that we should change some settings. In fact in alpha things are > > there to evolve until the release :) > > I like... > self xxx > ifTrue: > [ self bla. > self foo. > ]. > > for three reasons: > * the first statement of the block is vertically aligned with the rest > * vertical alignment of paired brackets makes visual matching *simple* > * the vertical whitespace enforced by the closing bracket on its > own visually groups blocks. > > Now some people don't like the closing brace on its own because they > prefer code density. So maybe this... > > self xxx > ifTrue: > [ self bla. > self foo. ] > ifFalse: > [ self baa. > self moo. ]. > > But still I prefer... > > self xxx > ifTrue: > [ self bla. > self foo. > ] > ifFalse: > [ self baa. > self moo. > ]. > > cheers -ben > > > > > -- > _,,,^..^,,,_ > best, Eliot

Sept. 3, 2015

Re: [Pharo-dev] GitFileTree: Playing Nice with FileTree

by Thierry Goubier

Hi Sean, Le 03/09/2015 04:29, Sean P. DeNigris a Ã©crit : > If I have a filetree://path/to/canonical/local/repo repository, can I later > point a GitFileTree repo to that folder? From the MC Browser +Repository > menu, I only seem to be able to set the subfolder relative to the > #imageDirectory, not the absolute pathâ¦ Are you sure about the local path? I know I played with a few things to try to get local paths to work if used. But gitfiletree://path/to/canonical/local/repo will work. Thierry

Sept. 3, 2015

Re: [Pharo-dev] Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by H. Hirzel

On 9/2/15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> On 02 Sep 2015, at 12:32, stepharo <stepharo(a)free.fr> wrote: >> >> Hi guille >> >> there is not stress. I just wanted to let you know. >> I was wondering if just subclassing DateAndTime would not be enough for >> now. > > Yes, as far as I remember Timestamp was just an empy subclass. > > We could: > > -> add it back to Deprecated50 or maybe even to a âCompatibilityâ package +1 > -> Write a Quality Check rule. > >> I will go back to code with Pharo 40 >> >> stef >> >> Le 2/9/15 10:30, Guillermo Polito a Ã©crit : >>> If somebody can check it and fix it it would be good :). I've just >>> started my new job and my evenings are busy looking for an apartment or >>> staying in a hostel without a proper internet connection... >>> >>> If not, I think we can wait a bit. The first step should be enabling CI >>> jobs for pharo5. Also, I do not think the intersection between 'people >>> using garage opendbx' and 'people using pharo5' is that big to justify a >>> rush. >>> >>> Guille >>> >>> El miÃ©., 2 de sept. de 2015 a la(s) 10:12 a. m., stepharo >>> <stepharo(a)free.fr <mailto:stepharo@free.fr>> escribiÃ³: >>> for your info... >>> >>> Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp >>> >>> Stef >>> >> > >

Sept. 3, 2015