April 2018 - Pharo-dev - lists.pharo.org

[Pharo70 alpha] Store settings raise a DNU primFlush

by Stephane Ducasse

Hi I do not know if this is related to the OldStreamCleaningEffort but when I press store settings in the Settings browser I get a primitive failed. https://pharo.fogbugz.com/f/cases/21699/Store-settings-raise-a-DNU-primFlush Stef

April 13, 2018

Re: [Pharo-dev] updating preference to iceberg2 help needed :)

by Cyril Ferlicot

On ven. 13 avr. 2018 at 20:32, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Any idea for this one? > > IceRepository > shareRepositoriesBetweenImages: true; > sharedRepositoriesLocationString: > '/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/'. > > Hi! See my startup script update: https://github.com/jecisc/pharo-scripts/commit/4eedd32ad9c321af320b08a48cbc… (Fast answer from my phone) -- Cyril Ferlicot https://ferlicot.fr

April 13, 2018

updating preference to iceberg2 help needed :)

by Stephane Ducasse

Any idea for this one? IceRepository shareRepositoriesBetweenImages: true; sharedRepositoriesLocationString: '/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/'.

April 13, 2018

[OT] Reminder about quoting/top-posting

by Esteban A. Maringolo

Hi, Please apologize the digression, but these days there were a lot of interesting threads with LOTS of replies from different members. Can I ask for more trimming of the quoted text and/or emails replied to? The follow up of some replies was hard because they were nested deep into a chain of previous quotes, or in the case of top-posters, they keep the replied emails accumulating in the bottom, causing a scroll down to find nothing else was there. Thanks! -- Esteban A. Maringolo

April 13, 2018

[Pharo 7.0-dev] Build #765: 21692-StdioStream-incorrectly-delegates-atEnd-and-position-to-file

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

There is a new Pharo build available! The status of the build #765 was: SUCCESS. The Pull Request #1193 was integrated: "21692-StdioStream-incorrectly-delegates-atEnd-and-position-to-file" Pull request url: https://github.com/pharo-project/pharo/pull/1193 Issue Url: https://pharo.fogbugz.com/f/cases/21692 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 13, 2018

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

by Guillermo Polito

On Fri, Apr 13, 2018 at 7:34 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 14 April 2018 at 01:10, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> >> >> On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> >>> >>> On 13 April 2018 at 23:15, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>>> On 13 April 2018 at 17:07, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> >>>> wrote: >>>> > >>>> > >>>> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito < >>>> guillermopolito(a)gmail.com> wrote: >>>> >> >>>> >> >>>> >> The thing is that the best way to do it is to clone your own fork... >>>> And each one has her/his one. >>>> >>> >>> I know, but momentarily forgot while trying to work on my first Issue >>> with the new UI. >>> However I discovered something cool... >>> >>> I had directly cloned "git@github.com:pharo-project/pharo.git" >>> successfully brought that "Up to date" >>> then in the "Working copy of pharo" window, clicked <New Issue> and >>> filled in details, >>> made my code change, >>> then clicked <Commit> >>> then clicked <Push> bringing me to a window titled "Push >>> pharo/21686-.../21686..." >>> where the only option to "Push to remote: " was "origin (git(a)github.com: >>> pharo-project/pharo.git)" >>> and clicking <Push> of course produced an error "LGit_GIT_EEOF: ERROR: >>> Permission to pharo-project/pharo.git denied to bencoman." >>> Fair enough! >>> >> >> Have to gracefully manage that error. Could you open an issue? >> >> >>> >>> But then...!!! >>> Back in the "Repositories" window, >>> "pharo" > right-click > Repository > Add Remote >>> Remote name = bencoman >>> Remote URL = git@github.com:pharo-project/pharo.git >>> And back in the "Working copy of pharo" window >>> clicked <Push> bringing again me to a window titled "Push >>> pharo/21686-.../21686..." >>> but now I had an extra option "bencoman <git@github.com:bencoman/pharo >>> .git>" >>> and selecting that and clicking <Push> worked!!!! >>> >>> https://github.com/bencoman/pharo/tree/21686-Setting-backgro >>> und-images-doesnt-work-on-Pharo-70 >>> >> >> Esteban is working on adding the add remote to the pull/push windows >> >> https://github.com/pharo-vcs/iceberg/issues/624 >> >> so you will have less clicks to do there ;) >> >> >>> >>> >>> Now the key thing here is that I **didn't** have to first >>> synchronise github.com:bencoman/pharo.git with github.com: >>> pharo-project/pharo.git >>> and remember to clone github.com: bencoman/pharo.git . >>> I just pushed to my repo **after-the-fact**. >>> >>> I haven't submitted many fixes lately to get familiar with Iceberg, >>> and maybe I missed something in the old workflow, >>> but previously it seemed that my pharo github repo needed to be up to >>> date, >>> and I must clone from there. >>> >> >> Well, it depends. >> >> Scenario 1) If you're not planning to reuse your clone, you don't need to >> care about synchronize. >> - just reclone pharo from pharo >> - add your fork as remote >> - you're set >> >> Scenario 2) If you want to reuse your clone you may not synchronize them. >> - pull from pharo from time to time >> - start a new branch from the current commit >> - you're set >> >> But then, there is people that may want/need to have some other workflow. >> For example: >> - I start from scenario 1 >> - make a branch >> - commit some work >> - tomorrow I come back and I download a new image >> * a couple of integrations may have happened in between!! >> * but I want to continue working in my branch >> >> Then the scenario could be solved as: >> - fetch from pharo >> - if you're in detached mode, just use the merge image into branch >> action and select your branch >> - or if you want to do it manually: >> - checkout your branch in your image without loading packages >> - merge pharo/development into your branch >> - continue working >> >> Now, what I would like is that we detect such "common rough scenarios" >> and discuss how we could have a better UI support for them. >> Maybe we need as a part of the Pharo plugin a wizard that takes you >> through the "synchronize my image again please"? >> Or could it be solved with some strategy that is general enough to be >> reused in any repository? >> >> >>> >>> The new UI is intuitive and made it east to clone from pharo-project, >>> make fix the push to bencoman. >>> I worked this out from just a small bit of trial & error. >>> >>> >>> One request... >>> In attached snapshot where the remotes show "origin", >>> please consider showing that as "pharo-project" >>> The term "origin" is useful for generic documentation and for examples, >>> but there is *nothing* special about that label from a git perspective. >>> A remote is a remote is a remote. >>> >> >> Well that's mostly a libgit thing. It does it by default I think when you >> clone, and I'm pretty sure that a lot of people would be against breaking >> such default because that's how git works also. >> > > Its not "the" way git works. Its just the "default". > Any name can be used to refer to the upstream repo. > i.e... > --origin <name> > Instead of using the remote name origin to keep track of the > upstream repository, use <name>. > https://git-scm.com/docs/git-clone > I know it's the default name git gives by default :). But changing that may confuse people that are used to git also... So I'm just thinking what would be the less surprising thing for most of the people https://en.wikipedia.org/wiki/Principle_of_least_astonishment > > > but never-mind, you've got bigger fish to fry :) > > cheers -ben > > > >> What could maybe be done is to enhance the "New repository" dialog to be >> able to provide a remote name using origin by default? >> Like that people could be able to override it to their convenience? >> >> >>> >>> Since mostly pharo development workflow will follow a triangle, >>> from remote pharo-project repo, to remote personal repo, PR to remote >>> pharo-project repo, >>> it would be more useful conceptually >>> to have the pharo-project remote labelled "pharo-project" rather than >>> labelled "origin". >>> >> -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 13, 2018

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

by Ben Coman

On 14 April 2018 at 01:10, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On 13 April 2018 at 23:15, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >>> On 13 April 2018 at 17:07, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> >>> wrote: >>> > >>> > >>> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >> >>> >> >>> >> The thing is that the best way to do it is to clone your own fork... >>> And each one has her/his one. >>> >> >> I know, but momentarily forgot while trying to work on my first Issue >> with the new UI. >> However I discovered something cool... >> >> I had directly cloned "git@github.com:pharo-project/pharo.git" >> successfully brought that "Up to date" >> then in the "Working copy of pharo" window, clicked <New Issue> and >> filled in details, >> made my code change, >> then clicked <Commit> >> then clicked <Push> bringing me to a window titled "Push >> pharo/21686-.../21686..." >> where the only option to "Push to remote: " was "origin (git(a)github.com: >> pharo-project/pharo.git)" >> and clicking <Push> of course produced an error "LGit_GIT_EEOF: ERROR: >> Permission to pharo-project/pharo.git denied to bencoman." >> Fair enough! >> > > Have to gracefully manage that error. Could you open an issue? > > >> >> But then...!!! >> Back in the "Repositories" window, >> "pharo" > right-click > Repository > Add Remote >> Remote name = bencoman >> Remote URL = git@github.com:pharo-project/pharo.git >> And back in the "Working copy of pharo" window >> clicked <Push> bringing again me to a window titled "Push >> pharo/21686-.../21686..." >> but now I had an extra option "bencoman <git@github.com:bencoman/pharo >> .git>" >> and selecting that and clicking <Push> worked!!!! >> >> https://github.com/bencoman/pharo/tree/21686-Setting-backgro >> und-images-doesnt-work-on-Pharo-70 >> > > Esteban is working on adding the add remote to the pull/push windows > > https://github.com/pharo-vcs/iceberg/issues/624 > > so you will have less clicks to do there ;) > > >> >> >> Now the key thing here is that I **didn't** have to first >> synchronise github.com:bencoman/pharo.git with github.com: >> pharo-project/pharo.git >> and remember to clone github.com: bencoman/pharo.git . >> I just pushed to my repo **after-the-fact**. >> >> I haven't submitted many fixes lately to get familiar with Iceberg, >> and maybe I missed something in the old workflow, >> but previously it seemed that my pharo github repo needed to be up to >> date, >> and I must clone from there. >> > > Well, it depends. > > Scenario 1) If you're not planning to reuse your clone, you don't need to > care about synchronize. > - just reclone pharo from pharo > - add your fork as remote > - you're set > > Scenario 2) If you want to reuse your clone you may not synchronize them. > - pull from pharo from time to time > - start a new branch from the current commit > - you're set > > But then, there is people that may want/need to have some other workflow. > For example: > - I start from scenario 1 > - make a branch > - commit some work > - tomorrow I come back and I download a new image > * a couple of integrations may have happened in between!! > * but I want to continue working in my branch > > Then the scenario could be solved as: > - fetch from pharo > - if you're in detached mode, just use the merge image into branch action > and select your branch > - or if you want to do it manually: > - checkout your branch in your image without loading packages > - merge pharo/development into your branch > - continue working > > Now, what I would like is that we detect such "common rough scenarios" > and discuss how we could have a better UI support for them. > Maybe we need as a part of the Pharo plugin a wizard that takes you > through the "synchronize my image again please"? > Or could it be solved with some strategy that is general enough to be > reused in any repository? > > >> >> The new UI is intuitive and made it east to clone from pharo-project, >> make fix the push to bencoman. >> I worked this out from just a small bit of trial & error. >> >> >> One request... >> In attached snapshot where the remotes show "origin", >> please consider showing that as "pharo-project" >> The term "origin" is useful for generic documentation and for examples, >> but there is *nothing* special about that label from a git perspective. >> A remote is a remote is a remote. >> > > Well that's mostly a libgit thing. It does it by default I think when you > clone, and I'm pretty sure that a lot of people would be against breaking > such default because that's how git works also. > Its not "the" way git works. Its just the "default". Any name can be used to refer to the upstream repo. i.e... --origin <name> Instead of using the remote name origin to keep track of the upstream repository, use <name>. https://git-scm.com/docs/git-clone but never-mind, you've got bigger fish to fry :) cheers -ben > What could maybe be done is to enhance the "New repository" dialog to be > able to provide a remote name using origin by default? > Like that people could be able to override it to their convenience? > > >> >> Since mostly pharo development workflow will follow a triangle, >> from remote pharo-project repo, to remote personal repo, PR to remote >> pharo-project repo, >> it would be more useful conceptually >> to have the pharo-project remote labelled "pharo-project" rather than >> labelled "origin". >> >

April 13, 2018

[Pharo 7.0-dev] Build #764: Fix Case 21686 Setting background images doesn't work on Pharo 7.0

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

There is a new Pharo build available! The status of the build #764 was: SUCCESS. The Pull Request #1197 was integrated: "Fix Case 21686 Setting background images doesn't work on Pharo 7.0" Pull request url: https://github.com/pharo-project/pharo/pull/1197 Issue Url: https://pharo.fogbugz.com/f/cases/21686 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 13, 2018

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

by Guillermo Polito

On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 13 April 2018 at 23:15, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >> On 13 April 2018 at 17:07, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> >> wrote: >> > >> > >> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >> >> >> >> >> The thing is that the best way to do it is to clone your own fork... >> And each one has her/his one. >> > > I know, but momentarily forgot while trying to work on my first Issue with > the new UI. > However I discovered something cool... > > I had directly cloned "git@github.com:pharo-project/pharo.git" > successfully brought that "Up to date" > then in the "Working copy of pharo" window, clicked <New Issue> and filled > in details, > made my code change, > then clicked <Commit> > then clicked <Push> bringing me to a window titled "Push > pharo/21686-.../21686..." > where the only option to "Push to remote: " was "origin (git(a)github.com: > pharo-project/pharo.git)" > and clicking <Push> of course produced an error "LGit_GIT_EEOF: ERROR: > Permission to pharo-project/pharo.git denied to bencoman." > Fair enough! > Have to gracefully manage that error. Could you open an issue? > > But then...!!! > Back in the "Repositories" window, > "pharo" > right-click > Repository > Add Remote > Remote name = bencoman > Remote URL = git@github.com:pharo-project/pharo.git > And back in the "Working copy of pharo" window > clicked <Push> bringing again me to a window titled "Push > pharo/21686-.../21686..." > but now I had an extra option "bencoman <git@github.com:bencoman/ > pharo.git>" > and selecting that and clicking <Push> worked!!!! > > https://github.com/bencoman/pharo/tree/21686-Setting- > background-images-doesnt-work-on-Pharo-70 > Esteban is working on adding the add remote to the pull/push windows https://github.com/pharo-vcs/iceberg/issues/624 so you will have less clicks to do there ;) > > > Now the key thing here is that I **didn't** have to first > synchronise github.com:bencoman/pharo.git with github.com: > pharo-project/pharo.git > and remember to clone github.com: bencoman/pharo.git . > I just pushed to my repo **after-the-fact**. > > I haven't submitted many fixes lately to get familiar with Iceberg, > and maybe I missed something in the old workflow, > but previously it seemed that my pharo github repo needed to be up to > date, > and I must clone from there. > Well, it depends. Scenario 1) If you're not planning to reuse your clone, you don't need to care about synchronize. - just reclone pharo from pharo - add your fork as remote - you're set Scenario 2) If you want to reuse your clone you may not synchronize them. - pull from pharo from time to time - start a new branch from the current commit - you're set But then, there is people that may want/need to have some other workflow. For example: - I start from scenario 1 - make a branch - commit some work - tomorrow I come back and I download a new image * a couple of integrations may have happened in between!! * but I want to continue working in my branch Then the scenario could be solved as: - fetch from pharo - if you're in detached mode, just use the merge image into branch action and select your branch - or if you want to do it manually: - checkout your branch in your image without loading packages - merge pharo/development into your branch - continue working Now, what I would like is that we detect such "common rough scenarios" and discuss how we could have a better UI support for them. Maybe we need as a part of the Pharo plugin a wizard that takes you through the "synchronize my image again please"? Or could it be solved with some strategy that is general enough to be reused in any repository? > > The new UI is intuitive and made it east to clone from pharo-project, make > fix the push to bencoman. > I worked this out from just a small bit of trial & error. > > > One request... > In attached snapshot where the remotes show "origin", > please consider showing that as "pharo-project" > The term "origin" is useful for generic documentation and for examples, > but there is *nothing* special about that label from a git perspective. > A remote is a remote is a remote. > Well that's mostly a libgit thing. It does it by default I think when you clone, and I'm pretty sure that a lot of people would be against breaking such default because that's how git works also. What could maybe be done is to enhance the "New repository" dialog to be able to provide a remote name using origin by default? Like that people could be able to override it to their convenience? > > Since mostly pharo development workflow will follow a triangle, > from remote pharo-project repo, to remote personal repo, PR to remote > pharo-project repo, > it would be more useful conceptually > to have the pharo-project remote labelled "pharo-project" rather than > labelled "origin". > > cheers -ben > > > >> >> >> > >> > >> > What your can do is display the list of forks and ask to select the >> right one. Then it will create the Pharo repo with the two remotes. >> >> >> I was going to suggest prompting for the git username. You can >> substitute it in to: >> >> git@github.com:{username}/pharo.git >> >> and add upstream (pharo-project). >> >> >> Cheers, >> Alistair >> >> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 13, 2018

Re: [Pharo-dev] request Calypso added as a "project" in Fogbugz

by Ben Coman

On 13 April 2018 at 21:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Ben Coman wrote > > However I have some concerns about scattering Issues away from Fogbugz > > since this makes it harder to get an overview of outstanding issues > > Point taken, but: > - IIUC we will be soon moving to *all* github issues anyway > - duplication has it's own negative consequences > - There are significant benefits to GH issues for GH code like all the > auto-references (issues, commits, etc) What is lacking from the Git/Fogbugz integration? Is it just that it hasn't been used/promoted much? (Is it enabled?) cheers -ben

April 13, 2018