January 2020 - Pharo-dev - lists.pharo.org

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

by Alistair Grant

Hi Stef & Guille, I received the same deprecation notice as Stef on 13 December. I've also just seen an `IceGitHubError: Not Found` error: IceGitHubAPI>>responseWithValidationDo: IceGitHubAPI>>contentsWithValidationDo: IceGitHubAPI>>jsonContentsWithValidationDo: IceGitHubAPI>>get: IceGitHubAPI>>getRepository:project: [ ^ IceGitHubAPI new beAnonymous; getRepository: self userName project: self projectName ] in IceTipGitHubRepositoryPanel>>getGitHubRepository in Block: [ ^ IceGitHubAPI new... BlockClosure>>on:do: IceTipGitHubRepositoryPanel>>getGitHubRepository [ | githubRepository | githubRepository := self getGitHubRepository. ... Not sure if it is related or not. Cheers, Alistair On Wed, 22 Jan 2020 at 09:49, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Did you re-clone your repository? I donât think soâ¦ > Did you create a PR using Pharoâs github integration? > > Those are the only points we use Githubâs API :/ > > > El 22 ene 2020, a las 9:13, ducasse <stepharo(a)netcourrier.com> escribiÃ³: > > > > I was just committing to my pharo fork ââ¦.using Zinc HTTP Components 1.0 (Pharo/9.0) ...â > > so I do not get fully get it. > > If Iâm the only one to receive this mail then this is ok > > > > Guille apparently I used password else it would have failed? Can it be that my password is not well set? > > > > I have hte impression that they mean something else. > > > > "We will deprecate basic authentication using passwordâ > > > > S > > > >> On 22 Jan 2020, at 07:47, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >> > >> Hi, > >> > >> I believe that when cloning a repository using the Github tab from iceberg, iceberg makes a request to ask github for that projectâs meta-data. > >> This query identifies if the cloned repository is a fork of another repository or not, and in case it is a fork, correctly pre-configure the repository remotes to simplify further operations (such as fetching from upstream, or creating pull requests in-image). > >> > >> If user credentials are not available, such request is anonymous. > >> However, if user credentials **are** available, they are used => this is required for private projects to work. > >> > >> One possible solution would be to add a new kind of credentials Token-based, to existing ones (passwords also used for https, ssh key pairs). > >> > >>> El 22 ene 2020, a las 7:34, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > >>> > >>> We probably have to change something. > >>> > >>> Do you know which operation (GitHub API access from Pharo code) is responsible for this ? > >>> > >>>> On 21 Jan 2020, at 21:05, 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. 22, 2020

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

by tesonep＠gmail.com

Yes, it is the PR creation API. I have started to add support to tokens in a nice way. I can push it to the next version. On Wed, Jan 22, 2020 at 9:55 AM ducasse <stepharo(a)netcourrier.com> wrote: > > > > > On 22 Jan 2020, at 09:48, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > Did you re-clone your repository? I donât think soâ¦ > > no > > > Did you create a PR using Pharoâs github integration? > > Yes I did this. > > > Those are the only points we use Githubâs API :/ > Ok we found it :) > > > > > >> El 22 ene 2020, a las 9:13, ducasse <stepharo(a)netcourrier.com> escribiÃ³: > >> > >> I was just committing to my pharo fork ââ¦.using Zinc HTTP Components 1.0 (Pharo/9.0) ...â > >> so I do not get fully get it. > >> If Iâm the only one to receive this mail then this is ok > >> > >> Guille apparently I used password else it would have failed? Can it be that my password is not well set? > >> > >> I have hte impression that they mean something else. > >> > >> "We will deprecate basic authentication using passwordâ > >> > >> S > >> > >>> On 22 Jan 2020, at 07:47, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >>> > >>> Hi, > >>> > >>> I believe that when cloning a repository using the Github tab from iceberg, iceberg makes a request to ask github for that projectâs meta-data. > >>> This query identifies if the cloned repository is a fork of another repository or not, and in case it is a fork, correctly pre-configure the repository remotes to simplify further operations (such as fetching from upstream, or creating pull requests in-image). > >>> > >>> If user credentials are not available, such request is anonymous. > >>> However, if user credentials **are** available, they are used => this is required for private projects to work. > >>> > >>> One possible solution would be to add a new kind of credentials Token-based, to existing ones (passwords also used for https, ssh key pairs). > >>> > >>>> El 22 ene 2020, a las 7:34, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > >>>> > >>>> We probably have to change something. > >>>> > >>>> Do you know which operation (GitHub API access from Pharo code) is responsible for this ? > >>>> > >>>>> On 21 Jan 2020, at 21:05, 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 > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> > > > > > > > -- Pablo Tesone. tesonep(a)gmail.com

Jan. 22, 2020

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

by ducasse

> On 22 Jan 2020, at 09:48, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Did you re-clone your repository? I donât think soâ¦ no > Did you create a PR using Pharoâs github integration? Yes I did this. > Those are the only points we use Githubâs API :/ Ok we found it :) > >> El 22 ene 2020, a las 9:13, ducasse <stepharo(a)netcourrier.com> escribiÃ³: >> >> I was just committing to my pharo fork ââ¦.using Zinc HTTP Components 1.0 (Pharo/9.0) ...â >> so I do not get fully get it. >> If Iâm the only one to receive this mail then this is ok >> >> Guille apparently I used password else it would have failed? Can it be that my password is not well set? >> >> I have hte impression that they mean something else. >> >> "We will deprecate basic authentication using passwordâ >> >> S >> >>> On 22 Jan 2020, at 07:47, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>> Hi, >>> >>> I believe that when cloning a repository using the Github tab from iceberg, iceberg makes a request to ask github for that projectâs meta-data. >>> This query identifies if the cloned repository is a fork of another repository or not, and in case it is a fork, correctly pre-configure the repository remotes to simplify further operations (such as fetching from upstream, or creating pull requests in-image). >>> >>> If user credentials are not available, such request is anonymous. >>> However, if user credentials **are** available, they are used => this is required for private projects to work. >>> >>> One possible solution would be to add a new kind of credentials Token-based, to existing ones (passwords also used for https, ssh key pairs). >>> >>>> El 22 ene 2020, a las 7:34, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: >>>> >>>> We probably have to change something. >>>> >>>> Do you know which operation (GitHub API access from Pharo code) is responsible for this ? >>>> >>>>> On 21 Jan 2020, at 21:05, 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. 22, 2020

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

by Guillermo Polito

Did you re-clone your repository? I donât think soâ¦ Did you create a PR using Pharoâs github integration? Those are the only points we use Githubâs API :/ > El 22 ene 2020, a las 9:13, ducasse <stepharo(a)netcourrier.com> escribiÃ³: > > I was just committing to my pharo fork ââ¦.using Zinc HTTP Components 1.0 (Pharo/9.0) ...â > so I do not get fully get it. > If Iâm the only one to receive this mail then this is ok > > Guille apparently I used password else it would have failed? Can it be that my password is not well set? > > I have hte impression that they mean something else. > > "We will deprecate basic authentication using passwordâ > > S > >> On 22 Jan 2020, at 07:47, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> Hi, >> >> I believe that when cloning a repository using the Github tab from iceberg, iceberg makes a request to ask github for that projectâs meta-data. >> This query identifies if the cloned repository is a fork of another repository or not, and in case it is a fork, correctly pre-configure the repository remotes to simplify further operations (such as fetching from upstream, or creating pull requests in-image). >> >> If user credentials are not available, such request is anonymous. >> However, if user credentials **are** available, they are used => this is required for private projects to work. >> >> One possible solution would be to add a new kind of credentials Token-based, to existing ones (passwords also used for https, ssh key pairs). >> >>> El 22 ene 2020, a las 7:34, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: >>> >>> We probably have to change something. >>> >>> Do you know which operation (GitHub API access from Pharo code) is responsible for this ? >>> >>>> On 21 Jan 2020, at 21:05, 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. 22, 2020

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

by ducasse

I was just committing to my pharo fork ââ¦.using Zinc HTTP Components 1.0 (Pharo/9.0) ...â so I do not get fully get it. If Iâm the only one to receive this mail then this is ok Guille apparently I used password else it would have failed? Can it be that my password is not well set? I have hte impression that they mean something else. "We will deprecate basic authentication using passwordâ S > On 22 Jan 2020, at 07:47, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi, > > I believe that when cloning a repository using the Github tab from iceberg, iceberg makes a request to ask github for that projectâs meta-data. > This query identifies if the cloned repository is a fork of another repository or not, and in case it is a fork, correctly pre-configure the repository remotes to simplify further operations (such as fetching from upstream, or creating pull requests in-image). > > If user credentials are not available, such request is anonymous. > However, if user credentials **are** available, they are used => this is required for private projects to work. > > One possible solution would be to add a new kind of credentials Token-based, to existing ones (passwords also used for https, ssh key pairs). > >> El 22 ene 2020, a las 7:34, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: >> >> We probably have to change something. >> >> Do you know which operation (GitHub API access from Pharo code) is responsible for this ? >> >>> On 21 Jan 2020, at 21:05, 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. 22, 2020

Re: [Pharo-dev] Fed up

by ducasse

> On 21 Jan 2020, at 23:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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. The difference is not only in speed. And it is exactly why I do not like value in Object. > 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 ? See my reply to esteban. >> 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. 22, 2020

Re: [Pharo-dev] Fed up

by ducasse

> On 21 Jan 2020, at 23:46, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > I also like the polymorphism of the #value: message, not only with Symbols but also with MADescriptions and many other uses. Thanks this is exactly my point and I do not like it because this is cheap and put the hell on tools. Of course the alternative is a bit more verbose because if you want to have aCol do: MADescription new then you would have to have myDomain >> do: anObject â¦. â¦. anObject value: â¦. But this means that a type inferencer could see that your code is calling this domain >> do: with a MADescription Now we destroy all the knowledge because do: has as argument anything on earth. What a gain. We went from any do: argument is a block and your do: has a MA to any do: implementation can get any object. So forget do build nice tools. After we can all program with perform: everywhere, but the trade we make is lame. Symbol >> value: anObject ^anObject perform: self. I have no problem that libraries break the possibility to have better tools applied to them. To me having value in Object is bad. Iâm fed up of our attitude. We are lame because we do not look further than our little nose. S. > > 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 <mailto:sean@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 <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> >

Jan. 22, 2020

Re: [Pharo-dev] Fed up

by ducasse

> On 22 Jan 2020, at 01:43, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > That performance regression looks more like a language implementation bug that a problem of the language itself. Probably but you see it via an optimisation prism. The problem is not just an optimisation of perform: which should be done in any way and orthogonally to this problem. Now what if we want to build static analysers. We put the burden on tool maker. If I have a write a type inferencer or a call graph then I will have to consider that the arg is - a block and do block analysis - a symbol and do a special treatment This is slightly not relayed but since any object understands valueâ¦.. we just dropped the possibility to use the code representation to gain some information about the program. This exactly for this reason that the classDefinition is a good move because sending a message to a class is a bad idea (easy and sweet at the beginning) but you cannot build nice tools, you cannot easily build remote code browser and perform dependency analyses (oh yes we can we build ring for it and many more). > If we assume that #do: and some other selectors (e.g. #select, #reject) should always receive a block instead of a symbol, then the compiler could perfectly replace the symbol literal for an already instantiated block literal transparently from the user perspective. Yes this is the optimisation I mention. > If the compiler does that we can save the bytecode for instantiating the block closure, which can save a potential roundtrip to the garbage collector. I guess (I am just speculating) that this performance overhead must be in the implementation of the #perform: primitive, which I guess has to: > 1) go through the JIT stack into the C stack transition (saving/restoring interpreter/JIT state, additional pressure, and primitive activation overhead. > 2) the lack of inline caches for #perform: (again, I am just guessing in this case). > > Note that the OpalCompiler is currently inlining some methods such as #ifTrue:ifFalse: , #ifNil:ifNotNil: #and: #or: and there are not actual message sends, so adding an additional list of selector where literal symbol arguments are synthesized as blocks is not different to the cheating that the current compiler is doing. If an user wants to disable this inlining, there is currently a pragma for telling the compiler. > > Do you want me to propose an experimental patch for testing this infrastructure? It would be nice but to me it is not exactly my point. After we should also see what is the impact on the decompiler, debugger, â¦. Now there is no such closed list of selectors that accept a block and now get a symbol. At the end what I would like in Pharo is a scientific process: Where we propose measure evaluate and decide once we have the data and not just oh this is easy let us make it. Pharo will not be a nice language by just adding tricks on top of tricks. S.

Jan. 22, 2020

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

by Guillermo Polito

Hi, I believe that when cloning a repository using the Github tab from iceberg, iceberg makes a request to ask github for that projectâs meta-data. This query identifies if the cloned repository is a fork of another repository or not, and in case it is a fork, correctly pre-configure the repository remotes to simplify further operations (such as fetching from upstream, or creating pull requests in-image). If user credentials are not available, such request is anonymous. However, if user credentials **are** available, they are used => this is required for private projects to work. One possible solution would be to add a new kind of credentials Token-based, to existing ones (passwords also used for https, ssh key pairs). > El 22 ene 2020, a las 7:34, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > > We probably have to change something. > > Do you know which operation (GitHub API access from Pharo code) is responsible for this ? > >> On 21 Jan 2020, at 21:05, 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. 22, 2020

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

by Sven Van Caekenberghe

We probably have to change something. Do you know which operation (GitHub API access from Pharo code) is responsible for this ? > On 21 Jan 2020, at 21:05, 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. 22, 2020