February 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [update 6.0] #60535

by Stephane Ducasse

Thanks a lot for this back port! This is highly appreciated and yes this is taking your time and I would prefer that you push the object centric debugger. Stef On Fri, Feb 23, 2018 at 4:13 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > â¦ CI just started to build: > > 60535 > ----- > > 21236 Sometimes the debugger opens with the context one off > https://pharo.fogbugz.com/f/cases/21236 > > 21324 Missing "Browse receiver" feature in the debugger > https://pharo.fogbugz.com/f/cases/21324 > >

Feb. 24, 2018

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

by Stephane Ducasse

Stephan Can you stop ranting for ranting and be positive thinking? Don't you think that are ARE PAYING ATTENTION!!! We will NOT END UP looking like some other systems! If you want to help here is a concrete proposal (we want to do it but we are busy doing bullshit works like reviewing fix and fixing typos around). - Gather all the deprecated methods in the past Pharo versions starting with Pharo 60. - add Transform rule when posible - package them so that people can load it and get helped during their migration EASY NO? sorry but I have something to hear that such kind of emails. Stef On Fri, Feb 23, 2018 at 8:20 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> Or are you saying there should be a collection of rewrite rules even after >> the method is totally removed so one can bring a very old project up to the >> newest APIs? > > Making sure the code works in each intermediate version of Pharo is > increasingly unattractive. It also requires indefinite support of all the > old pharo versions. A collection of separate rewrite rules looks to me like > the right thing to both explain changes and speed up migrations. > > Stephan > >

Feb. 24, 2018

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

by Stephan Eggermont

Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Or are you saying there should be a collection of rewrite rules even after > the method is totally removed so one can bring a very old project up to the > newest APIs? Making sure the code works in each intermediate version of Pharo is increasingly unattractive. It also requires indefinite support of all the old pharo versions. A collection of separate rewrite rules looks to me like the right thing to both explain changes and speed up migrations. Stephan

Feb. 23, 2018

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

by Sean P. DeNigris

Esteban A. Maringolo wrote >> That means with a code rewrite rule. Deprecations are not enough. > Why not both? It seems like you're both saying the same thing, no? Isn't this all accomplished via: self deprecated: 'Renamed to #action because now accepts any valuable as an action (e.g. aBlock).' on: '10/24/2017' in: #Pharo61 transformWith: '`@receiver selector' -> '`@receiver action'. Or are you saying there should be a collection of rewrite rules even after the method is totally removed so one can bring a very old project up to the newest APIs? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 23, 2018

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

by Esteban A. Maringolo

2018-02-23 14:50 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Cleanups at the level of Object are particularly valuable. > > It needs to be done in a way that is sustainable. That means with a code > rewrite rule. Deprecations are not enough. The number of people who can > migrate forwards older code is very small, especially as we are missing > crucial parts of design discussion that took place on slack and were not > copied to mail. Why not both? With a noisy enough deprecation warning and a handy rewrite rules script it would ease the transition. AFAIR the procedure was to mark as deprecated in one release and remove completely in the next one. Best regards! Esteban A. Maringolo

Feb. 23, 2018

[Pharo 7.0-dev] Build #601: 21374-Cancel-if-there-are-unsolved-depencies-during-bootstrap

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #601 was: FAILURE. The Pull Request #918 was integrated: "21374-Cancel-if-there-are-unsolved-depencies-during-bootstrap" Pull request url: https://github.com/pharo-project/pharo/pull/918 Issue Url: https://pharo.fogbugz.com/f/cases/21374 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 23, 2018

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

by Stephan Eggermont

Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Either we keep on adding cruft (or leaving cruft in place) in the sake of > backwards compatibility or be do something about it. It is not hard to > fix a couple of senders. It could be done more softly with a deprecation. > > Cleanups at the level of Object are particularly valuable. It needs to be done in a way that is sustainable. That means with a code rewrite rule. Deprecations are not enough. The number of people who can migrate forwards older code is very small, especially as we are missing crucial parts of design discussion that took place on slack and were not copied to mail. When I created my Morphic screencasts I had to look back to mailing list discussions from 10 years ago and had to run ancient squeak images to gain an understanding of how things were supposed to work and how they changed. Cleanups at this low level need to be done with rewrite rules (and tests) Stephan

Feb. 23, 2018

[Pharo 7.0-dev] Build #600: 21324-Missing-Browse-receiver-feature-in-the-debugger

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #600 was: SUCCESS. The Pull Request #945 was integrated: "21324-Missing-Browse-receiver-feature-in-the-debugger" Pull request url: https://github.com/pharo-project/pharo/pull/945 Issue Url: https://pharo.fogbugz.com/f/cases/21324 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 23, 2018

[update 6.0] #60535

by Marcus Denker

â¦ CI just started to build: 60535 ----- 21236 Sometimes the debugger opens with the context one off https://pharo.fogbugz.com/f/cases/21236 21324 Missing "Browse receiver" feature in the debugger https://pharo.fogbugz.com/f/cases/21324

Feb. 23, 2018

[Pharo 7.0-dev] Build #599: 21320-externalName-still-exists-in-class-Class

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #599 was: SUCCESS. The Pull Request #947 was integrated: "21320-externalName-still-exists-in-class-Class" Pull request url: https://github.com/pharo-project/pharo/pull/947 Issue Url: https://pharo.fogbugz.com/f/cases/21320 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 23, 2018