- Pharo-dev - lists.pharo.org

[Pharo 7.0] Build #92: 22860-Re-introduce-new-rubric-classes
by ci-pharo-ci-jenkins2＠inria.fr Jan. 2, 2019

Jan. 2, 2019

There is a new Pharo build available! The status of the build #92 was: SUCCESS. The Pull Request #2162 was integrated: "22860-Re-introduce-new-rubric-classes" Pull request url: https://github.com/pharo-project/pharo/pull/2162 Issue Url: https://pharo.fogbugz.com/f/cases/22860 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Happy new year!
by Esteban Lorenzano Jan. 2, 2019

Jan. 2, 2019

Hi list, Just that. I wish you all have a happy new year, and may it be even better than this one :) Esteban

6 5

Re: [Pharo-dev] Happy new year!
by Guillermo Polito Jan. 2, 2019

Jan. 2, 2019

Feliz aÃ±o nuevo! On Wed, Jan 2, 2019 at 4:11 AM Sean P. DeNigris via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > EstebanLM wrote > > I wish you all have a happy new year, and may it be even better than this > > one :) > > Happy New Year to all!! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

1 0

Re: [Pharo-users] New book: Pharo with Style
by Sean P. DeNigris Jan. 2, 2019

Jan. 2, 2019

Pharo Smalltalk Developers mailing list wrote > Including what the method does, even when the code is fairly simple > (OK, not getter / setter methods), is still useful. Yes, but... there is no free lunch. While there may be a benefit when the code and comment are freshly written and in sync, they are duplication which smells whether code or comment and it is all too easy for the code to be patched without updating the comment. Now that minor speedup turns into a more significant slowdown when a user blindly follows the now-wrong comment. This possibility is made more likely be the fact that a stale comment will not be picked up by the testing framework. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

1 0

New book: Pharo with Style
by Stephane Ducasse Jan. 1, 2019

Jan. 1, 2019

Hello Fellow Pharoers I'm happy to announce a new little book to improve the culture around Pharo. I will revise it in the future so you can feel free to send feedback and pull requests to https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle Stef "The best way to predict the future is to invent" so I do it.

4 5

Re: [Pharo-users] [Pharo-dev] New book: Pharo with Style
by Tim Mackinnon Jan. 1, 2019

Jan. 1, 2019

Iâve always felt the XP book nailed it - donât use comments as a crutch to avoid fixing confusing code and donât do work twice by simply writing a comment that says the same as the code. (You can of course try to write the comment and auto-generate the code, but weâve tried that before). Smalltalk is an expressive language that should read like comments naturally - both with the name of a method, the variables and the statements in it. This leaves comments as a good place to tell a story about the wider context and where to look to get started or learn more. I think this is possibly where Documentor is going to help you navigate along the real code. Of course if after all of this you canât figure out how to fix the code - then a comment is a good last resort. Tim Sent from my iPhone > On 1 Jan 2019, at 12:43, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Richard, > >> On Tue, 1 Jan 2019 at 07:26, Richard O'Keefe <raoknz(a)gmail.com> wrote: >> >> ... >> >> To get an example, I did (String allSelectors atRandom), getting >> #copyWithoutAll:. That has only one definition, in Collection: >> copyWithoutAll: aCollection >> "Answer a copy of the receiver that does not contain any elements >> equal to those in aCollection." >> >> ^ self reject: [:each | aCollection includes: each] >> >> The comment simply paraphrases the rather simple code. > > I agree with pretty much everything you've written, but have a > slightly different view here. > > Including what the method does, even when the code is fairly simple > (OK, not getter / setter methods), is still useful. If the comment is > absent, I have to look at the code, figure out what it does, and then > either figure out if that's what it is supposed to do, or just assume > that I'm correct. Having to figure out whether I've interpreted the > code correctly just increases the cognitive load. If the comment > includes what it is supposed to do, I have a context in which to read > and evaluate the code, and it becomes much less effort. > > Cheers, > Alistair >

1 0

Re: [Pharo-users] [Pharo-dev] New book: Pharo with Style
by Alistair Grant Jan. 1, 2019

Jan. 1, 2019

Hi Richard, On Tue, 1 Jan 2019 at 07:26, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > ... > > To get an example, I did (String allSelectors atRandom), getting > #copyWithoutAll:. That has only one definition, in Collection: > copyWithoutAll: aCollection > "Answer a copy of the receiver that does not contain any elements > equal to those in aCollection." > > ^ self reject: [:each | aCollection includes: each] > > The comment simply paraphrases the rather simple code. I agree with pretty much everything you've written, but have a slightly different view here. Including what the method does, even when the code is fairly simple (OK, not getter / setter methods), is still useful. If the comment is absent, I have to look at the code, figure out what it does, and then either figure out if that's what it is supposed to do, or just assume that I'm correct. Having to figure out whether I've interpreted the code correctly just increases the cognitive load. If the comment includes what it is supposed to do, I have a context in which to read and evaluate the code, and it becomes much less effort. Cheers, Alistair

1 0

Esteban's ChangeLog week of 24 December 2018
by estebanlm＠gmail.com Dec. 31, 2018

Dec. 31, 2018

Hello! This is my weekly ChangeLog, from 24 December 2018 to 30 December 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=24/12/2018&to=30/12/2018 ChangeLog ========= 27 December 2018: ----------------- * Opened Pharo8.0 development * branch was already opened by Stef :) * opened issue tracker * updated documents to point to it * sent mails to list TODO: Update videos (we needed new ones anyway) cheers! Esteban

1 0

[Pharo 7.0] Build #91: Revert "21876 Re-evaluating of class definition with slots cleans the class instance variables"
by ci-pharo-ci-jenkins2＠inria.fr Dec. 30, 2018

Dec. 30, 2018

There is a new Pharo build available! The status of the build #91 was: FAILURE. The Pull Request #2145 was integrated: "Revert "21876 Re-evaluating of class definition with slots cleans the class instance variables"" Pull request url: https://github.com/pharo-project/pharo/pull/2145 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] About contribution process, people participation and communication (WAS: Re: [ANN] Pharo 8.0 development started)
by Ben Coman Dec. 30, 2018

Dec. 30, 2018

On Sun, 30 Dec 2018 at 23:28, Esteban Lorenzano via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > Now, while the general direction was explained, I think I failed to > communicate several things. > For what I can think at this moment (for sure there are a lot more): > > - I failed to communicate that opening Pharo 8.0 branch didnât mean > closing Pharo 7.0 development, just to allow people doing big changes to > merge them. > - I failed to communicate correctly that having a release candidate (rc1) > meant âcode freezeâ (and then forbidding new changes except bug fixing). > Thanks for acknowledging this Esteban. In spite of the communication issue, the point I'd make in support of this arrangement is that historically we've done poorly with code-freezes, or even the lesser strength feature-freezes leading up to a release. A code freeze can be discouraging when integration of new features are delayed and can weaken such the code freeze. Opening the next-version-dev branch when the current-version freezes for release-candidate seems to facilitate pre-release stability - though the risk though of mind-share drifting to the next-version-dev branch needs to be managed. cheers -ben

1 0