- Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #249: 3279-UndefinedClass-cleaning
by ci-pharo-ci-jenkins2＠inria.fr May 1, 2019

May 1, 2019

There is a new Pharo build available! The status of the build #249 was: FAILURE. The Pull Request #3280 was integrated: "3279-UndefinedClass-cleaning" Pull request url: https://github.com/pharo-project/pharo/pull/3280 Issue Url: https://github.com/pharo-project/pharo/issues/3279 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #248: 3272-Slot-Demo-HistorySlot
by ci-pharo-ci-jenkins2＠inria.fr April 30, 2019

April 30, 2019

There is a new Pharo build available! The status of the build #248 was: SUCCESS. The Pull Request #3273 was integrated: "3272-Slot-Demo-HistorySlot" Pull request url: https://github.com/pharo-project/pharo/pull/3273 Issue Url: https://github.com/pharo-project/pharo/issues/3272 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

how implement isAbstract?
by Denis Kudriashov April 30, 2019

April 30, 2019

Hello. We did recently several cleanups by marking abstract classes as abstract using #isAbstract method (https://github.com/pharo-project/pharo/pull/3087, https://github.com/pharo-ide/Calypso/pull/462) . I would like to discuss here and decide what the right way to implement this method. The logic behind is to only return true when receiver is defining class of this method. And it should be false for any subclasses (if they do not implement own #isAbstract method). There is old pattern for implementation to compare name of class: MyAbstractClass class>>isAbstract ^self name == #MyAbstractClass It is used in many places (mostly tests). And it was used in recent Pharo PR (3087). We have another pattern in other places which simply compare self with class: MyAbstractClass class>>isAbstract ^self == MyAbstractClass And in Calypso I used "more simplified" version using equality: MyAbstractClass class>>isAbstract ^self = MyAbstractClass I think we would all agree that simplest version is last one. It does not raise any question about why we compare name or why we use identity comparison. So this is my choice in this discussion. Please write arguments about your preferred implementation. And let's choose single way at the end. There is an idea to add a command into browser to make classes abstract. And this decision will be used as a template. Best regards, Denis

11 19

Re: [Pharo-dev] color protocols and marking creation methods (msg 1 of Pharo-dev Digest, Vol 72, Issue 23)
by Jim Sawyer April 29, 2019

April 29, 2019

> 1. Re: How to convey that a message create a new instance > (Esteban Maringolo) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 28 Apr 2019 13:11:06 -0300 > From: Esteban Maringolo <emaringolo(a)gmail.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] How to convey that a message create a new > instance > Message-ID: > <CAJMgPCK1YB98CFn3KxhcDxLmoY7mYoXDboT5ZC2o7ZbL6pTYjA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Esteban A. Maringolo > > > On Sun, Apr 28, 2019 at 6:02 AM ducasse <stepharo(a)netcourrier.com> wrote: >>> On 28 Apr 2019, at 10:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> On 28 Apr 2019, at 01:05, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >>>> >>>> I tend to use the following idioms: >>>> - 'beSomething' idiom for cases modifying the receiver. >>>> - 'newWithSomething' or 'copyWithXx' for cases when I want to make it clear that you would get a new instance As a class, I think of Color as a factory, answering an immutable (though not literal) propertyValue. I might tell an object with a color property to change to a different propertyValue. I would expect it to do so by changing the property (replacing the current value with anotherPropertyValue), and would not expect the propertyValue itself to mutate (thus affecting all references to said value). Red cannot be darker.Â Red is Red.Â This sortOfRed can be darker than thatSortOfRed, so if you have theColorRed you can ask it for something darker, but you cannot ask it to become darker. Therefore, Color should not have any 'be' methods or 'as' methods. It might well have some fancy 'instance side' modifiers for describing a desired result, but they should always be answering an immutable instance of the class Color. self setColor: (Color red " (#FF0000) " butDarker) self color: (self color butDarker) self lightBulbColor: (Color red opacity: 0.2) As for #be vs. #as vs #newSomething, I would agree. I've beenÂ using the following conventions... Â Â Â #beX Â Â Â #beNotX (iff mode X is binary) Â Â Â #be: X Â Â Â to mean change your own state to that of mode X Â Â Â #isX Â Â Â #is: X Â Â to answer whether state is currently mode X and Â Â Â #notXÂ Â Â (iff mode X is binary) Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â rather than #isNotX Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â so that the 'mode' category lists modes as Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â isX Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â isY Â Â Â Â Â Â Â Â Â Â Â Â Â Â isZ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â notX Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â notY Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â notZ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â which is easier to read when there are lots of modes. and Â Â Â #asClassX Â Â Â #as: ClassXÂ Â Â to mean answer yourself as an instance of ClassX Â Â Â #asNewClassX Â Â Â #asNew: ClassXÂ Â Â to mean answer yourself as a new instance of ClassX and Â Â Â #newSomething Â Â Â #newWith: intialValue to mean create and answer a new instance and Â Â Â #variableOrPropertyNameÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â public accessingÂ Â Â Â Â Â Â Â Â (possibly lazily initialed) Â Â Â #setVariableName: nilOrValue Â Â Â Â Â Â Â Â Â Â Â Â private mutating Â Â Â Â Â Â Â Â (can be reset to nil, but not otherwise changed) Â Â Â #releaseVariableOrPropertyNameÂ Â Â Â Â Â Â Â Â private initial/release Â Â Â (if a resource) and set to nil, answer nil. Â Â Â #resetVariableOrPropertyNameÂ Â Â Â Â Â Â Â Â Â Â Â private initial/release Â Â Â reset to nil, answer self variableOrProprtyName Â Â Â #resetVariableOrPropertyName: valueÂ Â Â private initial/releaseÂ Â Â Â release (if a resource) and set to value Â Â Â #somePropertyName: valueÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â public mutatingÂ Â Â Â Â Â Â Â Â Â Â (answer self -- private mutators answer parameter) but these are all conventions for mutable objects. -Jim Jim Sawyer: jas(a)cruzio.com === --- This email has been checked for viruses by AVG. https://www.avg.com

1 0

Rename method Refactoring leads to infinite warning in latest image.
by ducasse April 29, 2019

April 29, 2019

I could not find what was the problem. /Users/ducasse/Documents/Pharo/images/P8Evaluator/P8Evaluator.image Pharo8.0.0 Build information: Pharo-8.0.0+build.247.sha.57e3eb84cac4564882b47b87e2a977199fbe2470 (64 Bit) Unnamed May be Spec2 side effect. Good news - reproducible - can stop with cmd . https://github.com/pharo-project/pharo/issues/3275 Stef

1 0

keyboard events using Spec
by RaniOfTheRain April 29, 2019

April 29, 2019

Hey, I'm new to using Pharo and Spec and am currently trying to build a Text Editor for a university project. I was wondering how one would capture keyboard events in order to change the text on a Spec LabelPresenter. I know there is a TextPresenter however I'm not able to use this as I need to program my own selection code etc. Many thanks -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

2 1

image state saving TDD
by Ben Coman April 29, 2019

April 29, 2019

Just a thought on a dream feature... When doing TDD, it would be super cool if in a test method, the state of the image was saved just before an #assert: so if the assert fails the state is restored to just before the assert was called, so I don't have to <Restart> and multi-step <Over> through the whole method to get back to the message I want to step into. cheers -ben

2 1

[ANN] Pharo Consortium New Academic Member: LIFIA
by Marcus Denker April 29, 2019

April 29, 2019

The Pharo Consortium is very happy to announce that LIFIA has joined the Consortium as an Academic Member. About - LIFIA is a Research Center based at the Faculty of Informatics of the National University of La Plata, in Argentina. It is an associated center to the Scientific Research Commission of the Buenos Aires Province (CIC-PBA). LIFIA pioneered the use of OOP (and Smalltalk in particular) in Argentina's industry and academia. https://www.lifia.info.unlp.edu.ar/en/ - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

1 0

[Pharo 8.0] Build #247: 3214-Spec-synchronization
by ci-pharo-ci-jenkins2＠inria.fr April 29, 2019

April 29, 2019

There is a new Pharo build available! The status of the build #247 was: FAILURE. The Pull Request #3216 was integrated: "3214-Spec-synchronization" Pull request url: https://github.com/pharo-project/pharo/pull/3216 Issue Url: https://github.com/pharo-project/pharo/issues/3214 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #246: Fixes: #3245 to ensure that we cannot create an empty protocol.
by ci-pharo-ci-jenkins2＠inria.fr April 29, 2019

April 29, 2019

There is a new Pharo build available! The status of the build #246 was: FAILURE. The Pull Request #3270 was integrated: "Fixes: #3245 to ensure that we cannot create an empty protocol." Pull request url: https://github.com/pharo-project/pharo/pull/3270 Issue Url: https://github.com/pharo-project/pharo/issues/3245 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0