- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Linux installation

by Stephane Ducasse

Hi sean how do we record what you did because it should not be lost. Stef On Fri, Feb 23, 2018 at 2:04 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Steph, I agree completely. I've spent many hours documenting and researching > ways to make Linux installation easier/better - and I don't even use Linux! > It was only that the steady stream of questions on the MLs makes it seem > fairly important. > > Sven, thanks - that's exactly what I was looking for. In my current case, > it's just for CI because Gitlab.com doesn't support OS X targets out of the > box, so I really have no attachment to any flavor. > > Norbert, that's great, thanks. I'll have to look and see how to tie a Pharo > Docker image into the SmalltalkCI infrastructure. > > Finally, I notice that the following specify different sets of libs. Are > they out of sync or for different use cases? > - > https://github.com/pharo-project/pharo-vm/blob/master/scripts/setup-ubuntu.… > - http://pharo.org/gnu-linux-installation (Ubuntu section) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Feb. 24, 2018

Re: [Pharo-dev] control flow graph

by Stephane Ducasse

Clement this analysis can be done without a control flow no? On Fri, Feb 23, 2018 at 11:47 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > I used that in the past on intermediate representations, I feel it is very > useful to directly edit the code of methods with large control flows since > when you have many closing brackets ] ] ] ] you never know where to write > your code. Now it's specific to some use-cases such as algorithms where you > write methods with large control flows, in most methods due to object > oriented programming convention the control flow is not that big. In this > context other things could be possible (Smart suggestions to move code out > of loops, etc.) > > > > > > > On Fri, Feb 23, 2018 at 11:37 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Hi >> >> I'm experimenting in building a control flow graph of pharo methods >> and I would like to know if you have ideas about what we can do >> with them to support our development environment. >> >> Stef >> > > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Feb. 24, 2018

Re: [Pharo-dev] control flow graph

by Stephane Ducasse

Tx. I was thinking about x = 3 ifTrue: [^ 66] ifFalse: [^ 88]. ^ 666 kind of analysis. Anyway for now I just continue to do it and we will see On Fri, Feb 23, 2018 at 2:27 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > It would be cool to have the graph for a method as a Calypso tool, so you > can see them side by side :) > > On Fri, Feb 23, 2018 at 11:47 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: >> >> I used that in the past on intermediate representations, I feel it is very >> useful to directly edit the code of methods with large control flows since >> when you have many closing brackets ] ] ] ] you never know where to write >> your code. Now it's specific to some use-cases such as algorithms where you >> write methods with large control flows, in most methods due to object >> oriented programming convention the control flow is not that big. In this >> context other things could be possible (Smart suggestions to move code out >> of loops, etc.) >> >> >> >> >> >> >> On Fri, Feb 23, 2018 at 11:37 AM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> >>> Hi >>> >>> I'm experimenting in building a control flow graph of pharo methods >>> and I would like to know if you have ideas about what we can do >>> with them to support our development environment. >>> >>> Stef >>> >> >> >> >> -- >> ClÃ©ment BÃ©ra >> Pharo consortium engineer >> https://clementbera.wordpress.com/ >> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > >

Feb. 24, 2018

Re: [Pharo-dev] [ANN] 900 pull requests closed for Pharo7!

by Stephane Ducasse

Hi guys this is great but there is nothing magic. You can help reviewing submitted fixes. Sorry to be boring but PHARO IS YOURS!!! Stef On Fri, Feb 23, 2018 at 1:27 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > March 11, we passed 800. Today (just now) we closed 900 full requests! > > https://github.com/pharo-project/pharo/pulls > > Marcus

Feb. 24, 2018

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