- Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #736: 2404-Morph-Theme

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

There is a new Pharo build available! The status of the build #736 was: FAILURE. The Pull Request #4600 was integrated: "2404-Morph-Theme" Pull request url: https://github.com/pharo-project/pharo/pull/4600 Issue Url: https://github.com/pharo-project/pharo/issues/2404 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 15, 2019

Re: [Pharo-dev] Help on Iceberg

by ducasse

> On 15 Sep 2019, at 13:31, Hilaire <hilaire(a)drgeo.eu> wrote: > > Question: What is exactly "current commits of your image". I understand > it in two ways: The image you download is somewhere based on a commit from Pharo. You may have got some extra changes in addition (for example if we have run a code that dirtied a package). > 1. Sync the local repo with the commits to match with the code in this > image (I think it is this one) > > 2. Sync local repo with the current commits (yes latest) for this image > in its remote repo > > Thanks > > Hilaire > > Le 15/09/2019 Ã 10:55, ducasse a Ã©crit : >> - the first one is to create a branch in your local repository to >> point to the current commit of your image >> so that you can come back to it (let us call it bottom-xxx). > > -- > Dr. Geo > http://drgeo.eu > > >

Sept. 15, 2019

Re: [Pharo-dev] Help on Iceberg

by Hilaire

Question: What is exactly "current commits of your image". I understand it in two ways: 1. Sync the local repo with the commits to match with the code in this image (I think it is this one) 2. Sync local repo with the current commits (yes latest) for this image in its remote repo Thanks Hilaire Le 15/09/2019 Ã 10:55, ducasse a Ã©critÂ : > -Â the first one is to create a branch in your local repository to > point to the current commit of your image > so that you can come back to it (let us call it bottom-xxx).Â -- Dr. Geo http://drgeo.eu

Sept. 15, 2019

Re: [Pharo-dev] Help on Iceberg

by ducasse

with some copy edit tep 6: Why you do not need to resync your fork with the pharo repo? No you do not need to explicitly resync your fork. Why? Because when you push your commits, you push also the Pharo commits. But let us look at it in details: When you download an image (imagine that this image contains the code of commit3 and that Pharo'repository is at commit5), the repair action will fetch all the commits (up to 5) and put them in your LOCAL repository. When you create your bottom branch (the branch that points to the situation of your image when you downloaded) and later from this one created the branch for your fixes (call it myfix), it means that when you commit your myfix branch all the commits from myfixes and then from commit3 down to the common ancestor between your fork and your local repository will be pushed back to your fork. Now if you downloaded the latest image (imagine for commit6 and that the pharo repository is at commit6 - yes this is the latest image!) when you push your branch (which here points to commit6), automatically all the commits (6 down to the common ancestors between your local repo to your fork) will be pushed to your fork. So your fork will be in sync with Pharo's one. So each time you work and push to your fork from the latest image, your fork gets updated. > On 15 Sep 2019, at 10:59, ducasse <stepharo(a)netcourrier.com> wrote: > > Step 6: Why you do not need to resync your fork with the pharo repo? > > No you do not need to explicitly resync your fork. Why? Because when you push your commits, you push also the Pharo commits. But let us look at it in details: When you download an image (imagine that this image contains the code of commit3 and that Pharo'repository is at commit5), the repair action will fetch all the commits (up to 5) and put them in your local repository. When you create your bottom branch and later from this one create the branch for your fixes (call it myfix), it means that when you will commit your myfix branch all the commits from myfixes and then 3 down will be pushed back to your fork. > > Now if you download the latest image (imagine with commit6 and that the pharo repo is at commit6 - yes this is the latest image!) when you will push your branch (which here point to commit6), automatically all the commits (6 down) will be pushed to your repo. So your fork will be in sync with Pharo's one. > > > >> On 15 Sep 2019, at 10:55, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: >> >> Hilaire >> >> >> When you download an image (it can come from mars) so the system >> does not know, where the sources are, to which commit it should point. >> >> So this is why you should either clone again or point to the source. >> >> Once you have downloaded or pointed to your fork (which can be old from a couple of centuries) >> the system should fetch commits from Pharo first to make sure that locally you have >> the same commits than in Pharo. >> >> Then it should find to which commit your image is from. >> For doing that (your image may contain changes that are not committed) >> it proposes you several options: >> - the first one is to create a branch in your local repository to point to the current commit of your image >> so that you can come back to it (let us call it bottom-xxx). >> When you select it, it explains to you the situation and the consequences. >> I will sit with the icebergers and do a pass on the explanation to make them even more lengthly. >> >> So at then end of this process you should have your image knowing to which commit it is from >> and you have a branch to point to this place so that you can navigate. >> >> Now the process to commit is: (from the wiki section I added https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> >> >> Create a branch for the issue you want to work on. >> Code, then commit, then push to YOUR fork >> Issue a PullRequest from your fork to Pharo >> Check out your Bottom-xxx branch and you can step 1 >> >> Is it clearer? >> >> >> BTW I add a section on why we do not need to explictly sync your fork with the repo on Pharo >> >> >> >>> On 15 Sep 2019, at 09:18, Hilaire <hilaire(a)drgeo.eu <mailto:hilaire@drgeo.eu>> wrote: >>> >>> Forgot the screenshot about the repair options >>> >>> -- >>> Dr. Geo >>> http://drgeo.eu <http://drgeo.eu/> >>> >>> <WhatNext.png> >> >

Sept. 15, 2019

Re: [Pharo-dev] Help on Iceberg

by ducasse

Step 6: Why you do not need to resync your fork with the pharo repo? No you do not need to explicitly resync your fork. Why? Because when you push your commits, you push also the Pharo commits. But let us look at it in details: When you download an image (imagine that this image contains the code of commit3 and that Pharo'repository is at commit5), the repair action will fetch all the commits (up to 5) and put them in your local repository. When you create your bottom branch and later from this one create the branch for your fixes (call it myfix), it means that when you will commit your myfix branch all the commits from myfixes and then 3 down will be pushed back to your fork. Now if you download the latest image (imagine with commit6 and that the pharo repo is at commit6 - yes this is the latest image!) when you will push your branch (which here point to commit6), automatically all the commits (6 down) will be pushed to your repo. So your fork will be in sync with Pharo's one. > On 15 Sep 2019, at 10:55, ducasse <stepharo(a)netcourrier.com> wrote: > > Hilaire > > > When you download an image (it can come from mars) so the system > does not know, where the sources are, to which commit it should point. > > So this is why you should either clone again or point to the source. > > Once you have downloaded or pointed to your fork (which can be old from a couple of centuries) > the system should fetch commits from Pharo first to make sure that locally you have > the same commits than in Pharo. > > Then it should find to which commit your image is from. > For doing that (your image may contain changes that are not committed) > it proposes you several options: > - the first one is to create a branch in your local repository to point to the current commit of your image > so that you can come back to it (let us call it bottom-xxx). > When you select it, it explains to you the situation and the consequences. > I will sit with the icebergers and do a pass on the explanation to make them even more lengthly. > > So at then end of this process you should have your image knowing to which commit it is from > and you have a branch to point to this place so that you can navigate. > > Now the process to commit is: (from the wiki section I added https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> > > Create a branch for the issue you want to work on. > Code, then commit, then push to YOUR fork > Issue a PullRequest from your fork to Pharo > Check out your Bottom-xxx branch and you can step 1 > > Is it clearer? > > > BTW I add a section on why we do not need to explictly sync your fork with the repo on Pharo > > > >> On 15 Sep 2019, at 09:18, Hilaire <hilaire(a)drgeo.eu <mailto:hilaire@drgeo.eu>> wrote: >> >> Forgot the screenshot about the repair options >> >> -- >> Dr. Geo >> http://drgeo.eu <http://drgeo.eu/> >> >> <WhatNext.png> >

Sept. 15, 2019

Re: [Pharo-dev] Help on Iceberg

by ducasse

Hilaire When you download an image (it can come from mars) so the system does not know, where the sources are, to which commit it should point. So this is why you should either clone again or point to the source. Once you have downloaded or pointed to your fork (which can be old from a couple of centuries) the system should fetch commits from Pharo first to make sure that locally you have the same commits than in Pharo. Then it should find to which commit your image is from. For doing that (your image may contain changes that are not committed) it proposes you several options: - the first one is to create a branch in your local repository to point to the current commit of your image so that you can come back to it (let us call it bottom-xxx). When you select it, it explains to you the situation and the consequences. I will sit with the icebergers and do a pass on the explanation to make them even more lengthly. So at then end of this process you should have your image knowing to which commit it is from and you have a branch to point to this place so that you can navigate. Now the process to commit is: (from the wiki section I added https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo Create a branch for the issue you want to work on. Code, then commit, then push to YOUR fork Issue a PullRequest from your fork to Pharo Check out your Bottom-xxx branch and you can step 1 Is it clearer? BTW I add a section on why we do not need to explictly sync your fork with the repo on Pharo > On 15 Sep 2019, at 09:18, Hilaire <hilaire(a)drgeo.eu> wrote: > > Forgot the screenshot about the repair options > > -- > Dr. Geo > http://drgeo.eu > > <WhatNext.png>

Sept. 15, 2019

Re: [Pharo-dev] Help on Iceberg

by Hilaire

Forgot the screenshot about the repair options -- Dr. Geo http://drgeo.eu

Sept. 15, 2019

Re: [Pharo-dev] Help on Iceberg

by Hilaire

What should I do next ? I install a newer P8, point the image repo to my existing repo in the local filesystem. Is it right? It seems I need to repair, but I don't understand why the repair dialog say and what option to pick up. I can't anticipate the consequences. Glossary, please (the one linked in the doc does not exist (https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary) * Image Commit? * working copy? * local change? * image changes? I would like to make proper PR, but I can't and the proposed solution did not worked. -- Dr. Geo http://drgeo.eu

Sept. 15, 2019

Re: [Pharo-dev] Allow selected special characters as part of unary and keyword selectors?

by Christopher Fuhrman

Crazy idea inspired by Spanish: Â¿even? On Sat, Sep 14, 2019 at 04:38 ducasse <stepharo(a)netcourrier.com> wrote: > > > On 13 Sep 2019, at 20:52, Tim Mackinnon <tim(a)testit.works> wrote: > > > I agree with Benâs reaction below , however the point that ? ! could be > repurposed for something if they werenât special characters is a good one. > Maybe there are other usages we are missing, and thatâs the point I guess. > > > Exactly. > I think that it would be nice to think a bit. > I like the idea that I do not have to read the code to understand if a > method is a predicate. > > odd? > even? > > Stef > > > Tim > > Sent from my iPhone > > On 13 Sep 2019, at 17:41, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Wed, 11 Sep 2019 at 15:10, ducasse <stepharo(a)netcourrier.com> wrote: > >> >> >> > On 11 Sep 2019, at 04:07, James Foster <Smalltalk(a)JGFoster.net> wrote: >> > >> > Would use of ? and ! in unary/keyword selectors be convention or >> somehow required? If simply convention, then we should start with renaming >> testing methods to be named is* or has*. >> > flag1 := anInteger even. ânot good" >> > > Agreed. That could "almost" be construed as converting a 3 to a 2 or 4. > > > > flag2 := anInteger isEven. âbetter" >> > > Agreed. It reads well. > > > > flag3 := anInteger even?. âhow much better?â >> > > For me, this doesn't read as well as flag2, but even though there is some > redundancy, for me a combination reads well... > flag3a := anInteger isEven? > Perhaps if "?"==>Boolean was a strong convention then there could be a > check when the value is returned rather than when it is used (or would that > complicate other things?) > > > > flag4 := #(1 2 3) includes?: 2. âhow much better?â >> > > My first impression is "yuck!", but then I think... "maybe" if there was a > definite benefit (i.e. optimization) from strong guarantees about the > return value being Boolean. > > > >> >> I think that I would use ? mainly for unary message >> >> Now Iâm sure that if you look carefully some people use >> >> include >> for the action >> includes >> for the tests >> >> I took include as an example and this is super not intention revealing. >> >> >> lineUpBlockBrackets >> >> lineUpBlockBrackets? >> Now I will rewrite them all as shouldLineUpBlockBrackets or >> isLineUpBlockBrackets and to me for unary message ? makes it a lot better. >> > > btw, some alternatives... > doBlockBracketsLineUp - reads well but "do" is already a loaded word > areBlockBracketsLinedUp - reads well with the past-tense phrasing > > cheers -ben > > > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

Sept. 14, 2019

Re: [Pharo-dev] Allow selected special characters as part of unary and keyword selectors?

by ducasse

> On 13 Sep 2019, at 20:52, Tim Mackinnon <tim(a)testit.works> wrote: > > > I agree with Benâs reaction below , however the point that ? ! could be repurposed for something if they werenât special characters is a good one. Maybe there are other usages we are missing, and thatâs the point I guess. Exactly. I think that it would be nice to think a bit. I like the idea that I do not have to read the code to understand if a method is a predicate. odd? even? Stef > > Tim > > Sent from my iPhone > > On 13 Sep 2019, at 17:41, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > >> >> >> On Wed, 11 Sep 2019 at 15:10, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: >> >> >> > On 11 Sep 2019, at 04:07, James Foster <Smalltalk(a)JGFoster.net <mailto:Smalltalk@JGFoster.net>> wrote: >> > >> > Would use of ? and ! in unary/keyword selectors be convention or somehow required? If simply convention, then we should start with renaming testing methods to be named is* or has*. >> > flag1 := anInteger even. ânot good" >> >> Agreed. That could "almost" be construed as converting a 3 to a 2 or 4. >> >> >> > flag2 := anInteger isEven. âbetter" >> >> Agreed. It reads well. >> >> >> > flag3 := anInteger even?. âhow much better?â >> >> For me, this doesn't read as well as flag2, but even though there is some redundancy, for me a combination reads well... >> flag3a := anInteger isEven? >> Perhaps if "?"==>Boolean was a strong convention then there could be a check when the value is returned rather than when it is used (or would that complicate other things?) >> >> >> > flag4 := #(1 2 3) includes?: 2. âhow much better?â >> >> My first impression is "yuck!", but then I think... "maybe" if there was a definite benefit (i.e. optimization) from strong guarantees about the return value being Boolean. >> >> >> >> I think that I would use ? mainly for unary message >> >> Now Iâm sure that if you look carefully some people use >> >> include >> for the action >> includes >> for the tests >> >> I took include as an example and this is super not intention revealing. >> >> >> lineUpBlockBrackets >> >> lineUpBlockBrackets? >> Now I will rewrite them all as shouldLineUpBlockBrackets or isLineUpBlockBrackets and to me for unary message ? makes it a lot better. >> >> btw, some alternatives... >> doBlockBracketsLineUp - reads well but "do" is already a loaded word >> areBlockBracketsLinedUp - reads well with the past-tense phrasing >> >> cheers -ben

Sept. 14, 2019