- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Fwd: [GitHub] Deprecation Notice

by Gabriel Cotelli

You can create a personal access token and use it instead of the password. For example when setting the iceberg credentials. So, I think there's no problem per se. On Tue, Jan 21, 2020, 17:06 ducasse <stepharo(a)netcourrier.com> wrote: > what will be the implication? > > > Begin forwarded message: > > *From: *GitHub <noreply(a)github.com> > *Subject: **[GitHub] Deprecation Notice* > *Date: *21 January 2020 at 21:03:28 CET > *To: *StÃ©phaneDucasse <stephane.ducasse(a)inria.fr> > > Hi @Ducasse, > > You recently used a password to access an endpoint through the GitHub API > using Zinc HTTP Components 1.0 (Pharo/9.0). We will deprecate basic > authentication using password to this endpoint soon: > > https://api.github.com/repositories/169849137 > > We recommend using a personal access token (PAT) with the appropriate > scope to access this endpoint instead. Visit > https://github.com/settings/tokens for more information. > > Thanks, > The GitHub Team > > > >

Jan. 21, 2020

Re: [Pharo-dev] Fed up

by Sven Van Caekenberghe

I also like the use of symbols but more for casual code. I know using blocks can be faster, but the difference is not massive. What I don't understand is why it is so super bad. Polymorphism will always be there, that is really powerful, when used wisely. I can't immediately see why one or the other would make analysis easier or better. Can you explain ? > On 21 Jan 2020, at 23:37, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > ducasse wrote >> in Pharo we should write >> aCol do: [ :each | each store ] > > I always enjoyed the Symbol/Block polymorphism because I thought it was such > a clever and visible example of the power of Smalltalk, and, let's face it, > I'm lazy and enjoyed saving a few key strokes! > > That said, I had no idea that there was a dramatic performance cost. Also, > the issues you raise about analysis seem important. > > Since people are free to still use it in their own projects, it doesn't seem > to controversial. Can/should we add a lint rule? Can/should it be scoped to > Pharo core? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Jan. 21, 2020

Re: [Pharo-dev] Fed up

by Esteban Maringolo

I also like the polymorphism of the #value: message, not only with Symbols but also with MADescriptions and many other uses. If that feds you up, and others too, maybe that "convention" (to use blocks only) might be scoped to Pharo core (whatever that is) methods. Regards, El mar., 21 de enero de 2020 19:35, Sean P. DeNigris <sean(a)clipperadams.com> escribiÃ³: > ducasse wrote > > in Pharo we should write > > aCol do: [ :each | each store ] > > I always enjoyed the Symbol/Block polymorphism because I thought it was > such > a clever and visible example of the power of Smalltalk, and, let's face it, > I'm lazy and enjoyed saving a few key strokes! > > That said, I had no idea that there was a dramatic performance cost. Also, > the issues you raise about analysis seem important. > > Since people are free to still use it in their own projects, it doesn't > seem > to controversial. Can/should we add a lint rule? Can/should it be scoped to > Pharo core? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Jan. 21, 2020

Re: [Pharo-dev] Fed up

by Sean P. DeNigris

ducasse wrote > in Pharo we should write > aCol do: [ :each | each store ] I always enjoyed the Symbol/Block polymorphism because I thought it was such a clever and visible example of the power of Smalltalk, and, let's face it, I'm lazy and enjoyed saving a few key strokes! That said, I had no idea that there was a dramatic performance cost. Also, the issues you raise about analysis seem important. Since people are free to still use it in their own projects, it doesn't seem to controversial. Can/should we add a lint rule? Can/should it be scoped to Pharo core? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 21, 2020

Re: [Pharo-dev] Fed up

by Aliaksei Syrel

Hi Indeed, iterating over a collection using symbols is somewhat ~20% slower :) Here are some numbers: aCol := (1 to: 100000000). > [ 10 timesRepeat: [ aCol *do: #yourself* ] ] timeToRunWithoutGC / 10.0. > *"1110.8"* > [ 10 timesRepeat: [ aCol *do: [ :each | each yourself ]* ] ] > timeToRunWithoutGC / 10.0. *"898.1"*. > (1110.8 - 898.1) / 1110.8 * 100 "*19.14836154123154*" Cheers, Alex On Tue, 21 Jan 2020 at 21:11, ducasse <stepharo(a)netcourrier.com> wrote: > Hi > > Iâm fed up. Why? > Because I see lousy code in Pharo and that such lousy code in Pharo is > slower, and sure that writing a type inferencer > for pharo will be more complex, and probably will make sista more complex > too. > > I asked the pharo consortium to take a clear position because I want a > better Pharo not the inverse. > So what is it. > > You can write in your code but not in Pharo. > > aCol do: #store > > in Pharo we should write > > aCol do: [ :each | each store ] > > Block argument should be blocks else any static analyser will have to > check it is a block, it is a symbol, is > it a RANDOM object that answer value. > > Seriously can be not make the life of people doing program analysis > simpler? > > So now if Iâm wrong then I will shut up and Iâm really pissed that we do > that without paying attention > to the consequence. > > I asked the consortium to take position and to take action. > We should have a better code review for REAL. > > S. > > > >

Jan. 21, 2020

Re: [Pharo-dev] Short Survey about automatic deprecation rewrites

by ducasse

Thanks! Martin milton juraj should do it too :) S. > On 21 Jan 2020, at 21:34, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > From: Alexandre Bergel <alexandre.bergel(a)me.com> > Subject: Re: [Pharo-dev] Short Survey about automatic deprecation rewrites > Date: 21 January 2020 at 21:34:58 CET > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > > Just answered! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On 21-01-2020, at 13:23, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> Hi all, >> >> We would like to share with you a short survey about the automatic deprecation rewrites that have been around since Pharo 6. >> It will be super useful for us to enhance the support for migrations. >> We estimate it will take ~< 3 minutes to fill. >> >> This survey is aimed at people both *using* Pharo, or writing libraries and frameworks for Pharo. >> If youâre a library/framework maintainer and you know people using your library, would you mind share it with them? >> >> Link to the survey: https://sondages.inria.fr/index.php/133442?lang=en >> >> Thanks a lot! >> Guille, in behalf of the Pharo consortium > > > >

Jan. 21, 2020

Re: [Pharo-dev] Short Survey about automatic deprecation rewrites

by Alexandre Bergel

Just answered! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On 21-01-2020, at 13:23, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > We would like to share with you a short survey about the automatic deprecation rewrites that have been around since Pharo 6. > It will be super useful for us to enhance the support for migrations. > We estimate it will take ~< 3 minutes to fill. > > This survey is aimed at people both *using* Pharo, or writing libraries and frameworks for Pharo. > If youâre a library/framework maintainer and you know people using your library, would you mind share it with them? > > Link to the survey: https://sondages.inria.fr/index.php/133442?lang=en > > Thanks a lot! > Guille, in behalf of the Pharo consortium

Jan. 21, 2020

Fed up

by ducasse

Hi Iâm fed up. Why? Because I see lousy code in Pharo and that such lousy code in Pharo is slower, and sure that writing a type inferencer for pharo will be more complex, and probably will make sista more complex too. I asked the pharo consortium to take a clear position because I want a better Pharo not the inverse. So what is it. You can write in your code but not in Pharo. aCol do: #store in Pharo we should write aCol do: [ :each | each store ] Block argument should be blocks else any static analyser will have to check it is a block, it is a symbol, is it a RANDOM object that answer value. Seriously can be not make the life of people doing program analysis simpler? So now if Iâm wrong then I will shut up and Iâm really pissed that we do that without paying attention to the consequence. I asked the consortium to take position and to take action. We should have a better code review for REAL. S.

Jan. 21, 2020

Fwd: [GitHub] Deprecation Notice

by ducasse

what will be the implication? > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [GitHub] Deprecation Notice > Date: 21 January 2020 at 21:03:28 CET > To: StÃ©phaneDucasse <stephane.ducasse(a)inria.fr> > > Hi @Ducasse, > > You recently used a password to access an endpoint through the GitHub API using Zinc HTTP Components 1.0 (Pharo/9.0). We will deprecate basic authentication using password to this endpoint soon: > > https://api.github.com/repositories/169849137 <https://api.github.com/repositories/169849137> > > We recommend using a personal access token (PAT) with the appropriate scope to access this endpoint instead. Visit https://github.com/settings/tokens <https://github.com/settings/tokens> for more information. > > Thanks, > The GitHub Team

Jan. 21, 2020

[Pharo 9.0] Build #16: Switch to the light theme

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

There is a new Pharo build available! The status of the build #16 was: SUCCESS. The Pull Request #5535 was integrated: "Switch to the light theme" Pull request url: https://github.com/pharo-project/pharo/pull/5535 Issue Url: https://github.com/pharo-project/pharo/issues/switchToLightTheme Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 21, 2020