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

[Pharo 9.0] Build #17: RB* and GR* should be renamed as Re* ... Rule - fixes: #5496

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

There is a new Pharo build available! The status of the build #17 was: FAILURE. The Pull Request #5497 was integrated: "RB* and GR* should be renamed as Re* ... Rule - fixes: #5496" Pull request url: https://github.com/pharo-project/pharo/pull/5497 Issue Url: https://github.com/pharo-project/pharo/issues/RenameRBGRRuleIntoReRule Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 22, 2020

Re: [Pharo-dev] Fed up

by ducasse

> On 22 Jan 2020, at 13:10, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > Hi! > > I see no problem in replacing the symbol usage with blocks. It's a nice shortcut for scripting but not a game changer. > And I'm also in favor of being cautious before introducing new things without analyzing it's impact. this is my point. > However, I see use cases for using objects polymorphic with blocks. A common case is to use some reification for a condition instead of a block evaluating to true/false. We have many of this in our systems where the end user needs to filter some kind of collection, and the filtering options are based on some other objects that the user creates in the system, and the user also wants to save his filter configuration so the next login this options are preserved. If you try to use blocks to model this conditions is more complex than using a proper abstraction, and more if you end up needing to persist this preferences in a relational database. Indeed now we found cool to be able to do it. But what is the cost because nothing prevent you to have your own vocabulary. This is what RBCondition is doing for example. > I don't know how this kind of scenario impacts the analyzer but for sure it has to cope with the reality that the people will be using things polymorphic with blocks. And if the analysis is static sometimes the object will be a block, but will come in an argument of the method and you don't know that doing static analysis. > > > > On Wed, Jan 22, 2020 at 5:09 AM ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: > > >> On 21 Jan 2020, at 23:46, Esteban Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@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 Gabriel Cotelli

Hi! I see no problem in replacing the symbol usage with blocks. It's a nice shortcut for scripting but not a game changer. And I'm also in favor of being cautious before introducing new things without analyzing it's impact. However, I see use cases for using objects polymorphic with blocks. A common case is to use some reification for a condition instead of a block evaluating to true/false. We have many of this in our systems where the end user needs to filter some kind of collection, and the filtering options are based on some other objects that the user creates in the system, and the user also wants to save his filter configuration so the next login this options are preserved. If you try to use blocks to model this conditions is more complex than using a proper abstraction, and more if you end up needing to persist this preferences in a relational database. I don't know how this kind of scenario impacts the analyzer but for sure it has to cope with the reality that the people will be using things polymorphic with blocks. And if the analysis is static sometimes the object will be a block, but will come in an argument of the method and you don't know that doing static analysis. On Wed, Jan 22, 2020 at 5:09 AM ducasse <stepharo(a)netcourrier.com> wrote: > > > 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> 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. 22, 2020

Re: [Pharo-dev] [P9] Large images tag

by ducasse

Thanks I went over the list and tagged nearly all of them. I think that P9 will be a real stabilisation phase. S. > On 22 Jan 2020, at 12:47, Vincent Blondeau <vincent.blondeau(a)lifeware.ch> wrote: > > > From: "Vincent Blondeau" <vincent.blondeau(a)lifeware.ch> > Subject: RE: [Pharo-dev] [P9] Large images tag > Date: 22 January 2020 at 12:47:21 CET > To: "'Pharo Development List'" <pharo-dev(a)lists.pharo.org> > > > Hi Stef, > > Great idea! Here are some that could be added to the list: > https://github.com/pharo-project/pharo/issues/5478 > https://github.com/pharo-project/pharo/issues/5260 > https://github.com/pharo-project/pharo/issues/5191 > https://github.com/pharo-project/pharo/issues/5188 > https://github.com/pharo-project/pharo/issues/5187 > https://github.com/pharo-project/pharo/issues/4896 > > Cheers, > Vincent > > Ps: only members of the Pharo git repo can tag issues. > > > -----Original Message----- > From: Pharo-dev On Behalf Of ducasse > Sent: Tuesday, 21 January 2020 20:34 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: [Pharo-dev] [P9] Large images tag > > Hi all > > We are starting an effort to review and improve the behavior of pharo in presence of super large images. > I created a special tag to highlight the issues. > So if you have concerns and found annoying behavior related to slugginess in large image, please use this tag. > > We are also looking for misuse of operations fully scanning the memory or kind of like allInstances of and others. > > S. > > > > > >

Jan. 22, 2020

RE: [Pharo-dev] [P9] Large images tag

by Vincent Blondeau

Hi Stef, Great idea! Here are some that could be added to the list: https://github.com/pharo-project/pharo/issues/5478 https://github.com/pharo-project/pharo/issues/5260 https://github.com/pharo-project/pharo/issues/5191 https://github.com/pharo-project/pharo/issues/5188 https://github.com/pharo-project/pharo/issues/5187 https://github.com/pharo-project/pharo/issues/4896 Cheers, Vincent Ps: only members of the Pharo git repo can tag issues. -----Original Message----- From: Pharo-dev On Behalf Of ducasse Sent: Tuesday, 21 January 2020 20:34 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] [P9] Large images tag Hi all We are starting an effort to review and improve the behavior of pharo in presence of super large images. I created a special tag to highlight the issues. So if you have concerns and found annoying behavior related to slugginess in large image, please use this tag. We are also looking for misuse of operations fully scanning the memory or kind of like allInstances of and others. S.

Jan. 22, 2020

Re: [Pharo-dev] Fed up

by Benoit St-Jean

+1000 I'm with you 110% on this one! Who, in their right mind, would code like that? Is it a trend among younger Smalltalkers while dinosaurs like me just "naturally" still use the "old way" and blocks? And do we have statistics about how often that "syntax" is used in the current image? In the past, I've complained a gazillion times about portability between Pharo and other Smalltalks and/or legacy code so you pretty much know my position on this kind of semantic twist!Â Okay, one might argue that using a symbol instead of a Block in your example saves you a big 16 characters to type.Â But who spends all their day mostly iterating over a collection so that it becomes an issue to save 16 characters ???Â And then, once we open that door, what's next? aCol do: [:eachItem | eachItem calculateProvincialTax. eachItem calculateFederalTax. eachItem calculateRebates. eachItem calculateTotal] Then, are we going to end up with "keystroke-savers" like: aCol do: #calculateProvincialTax and: #calculateFederalTax and: #calculateRebates and: calculateTotal Yeah, polymorphism is cool. But "coolness" has never been a reason in itself alone to use cool features just because they do exist! </rant> ;) On 2020-01-21 15:10, ducasse 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. > > > -- ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth GitHub: bstjean Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Jan. 22, 2020

[ANN] Cross Platform Embedding Example (Linux, MacOS)

by Pierce Ng

Hi all, Inspired by Pablo's example, I've created a cross-platform implemenation. Pablo's example uses Pharo.image embedded as a Windows resource. Well, the excellent and, like Smalltalk, vastly underrated Free Pascal has built-in cross platform support for Windows resources. Basically I have implemented, in Pascal, FFI to libPharoVMCore and the embedded image access routines for callback by libPharoVMCore, together with a driver program to run the embedded Pharo.image. Repository is here: https://github.com/PierceNg/pharo-vm-embedded-pascal More details to come in the repository. Pierce

Jan. 22, 2020

Re: [Pharo-dev] Unnecessary double checks of infinity

by Serge Stinckwich

https://github.com/pharo-project/pharo/issues/5542 On Sun, Dec 22, 2019 at 5:12 PM Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Hi all, > I'm having a look how floats are printed. > Why we check two times if a Float is infinite ? > A first time in: > > Float>>printOn: stream base: base > ... > self isInfinite > ifTrue: [ > stream nextPutAll: 'Float infinity'. > ^ self sign = -1 ifTrue: [ stream nextPutAll: ' negated' ] ]. > ... > > and a second time in: > > Float>>absPrintExactlyOn: aStream base: base > ... > self isInfinite ifTrue: [ > aStream nextPutAll: 'Float infinity'. > ^ self]. > ... > > the same in Float>>absPrintInexactlyOn: aStream base: base > ... > self isInfinite ifTrue: [aStream nextPutAll: 'Float infinity'. ^ self]. > ... > > Apparently the last two methods are never called when number is infinite. > > I remove the second checks and apparently nothing breaks (all number tests > are still green). > > Regards, > -- > Serge Stinckwic > h > > Int. Research Unit > on Modelling/Simulation of Complex Systems (UMMISCO) > Sorbonne University > (SU) > French National Research Institute for Sustainable Development (IRD) > U > niversity of YaoundÃ© I, Cameroon > "Programs must be written for people to read, and only incidentally for > machines to execute." > https://twitter.com/SergeStinckwich > -- Serge Stinckwic âhâ Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) âSorbonne University (SU) French National Research Institute for Sustainable Development (IRD)â U âniversity of YaoundÃ© Iâ, Cameroon "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich â

Jan. 22, 2020

Re: [Pharo-dev] Iceberg Bug? Branches with $/

by Guillermo Polito

Hi all, Iceberg supports branches named with slashes. It can pull, push, merge, checkoutâ¦ IIRC, what does not properly work is metacello support regarding it, because the parser of metacello urls may consider those extra âurl path elementsâ part of the directory to fetch the project. Guille > El 14 ene 2020, a las 18:33, Ben Coman <btc(a)openinworld.com> escribiÃ³: > > On Tue, 14 Jan 2020 at 21:26, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Ben Coman wrote >>> I find slashes in branch names problematic >> >> Okay, you've convinced me. How do we guide people toward that policy? >> A warning when creating such branches? > > That sounds reasonable. Perhaps a discrete warning icon/button appears > that opens a Help Subject > that describes that slashes are supported, but warns of a few > potential pitfalls. > > cheers -ben >

Jan. 22, 2020

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

by ducasse

Thanks pablo. This is the typical example that even if we do not want to do things the world is pushing us. So good code always pays because change is the only constant. S > On 22 Jan 2020, at 09:59, tesonep(a)gmail.com wrote: > > 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