December 2017 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #386: 20872-WidgetExamples-classexampleDialogs-is-broken-in-Pharo-7

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

There is a new Pharo build available! The status of the build #386 was: SUCCESS. The Pull Request #610 was integrated: "20872-WidgetExamples-classexampleDialogs-is-broken-in-Pharo-7" Pull request url: https://github.com/pharo-project/pharo/pull/610 Issue Url: https://pharo.fogbugz.com/f/cases/20872 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2017

Re: [Pharo-dev] Does pharo build not retry anymore?

by Stephane Ducasse

tx pavel On Sat, Dec 16, 2017 at 9:25 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > The problems were related UIManager initialization and consequences of > the opening of the Welcome window. > > -- Pavel > > 2017-12-16 9:12 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> Pavel what was the problem? >> >> Stef >> >> >> On Tue, Dec 12, 2017 at 9:34 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com >> > wrote: >> >>> The variable value was reverted to the original value. Thanks. >>> >>> -- Pavel >>> >>> 2017-12-12 20:13 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> >>>> Yes, with Marcus we decreased the retryTimes variable two weeks ago to >>>> 1 because in that time the validations were in really bad shape and >>>> literally every validation failed on some random issue and the retries >>>> caused enormous build times. It was producing more troubles than profit. It >>>> probably can be reverted now because the main problem of the validation >>>> instability was suppressed. I will prepare a PR. >>>> >>>> -- Pavel >>>> >>>> 2017-12-12 18:52 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com> >>>> : >>>> >>>>> I see that we are retrying tests only once, which is causing most (if >>>>> not all) pull requests to fail sporadically... >>>>> >>>>> Maybe it got lost because of a mistake? >>>>> >>>>> Also, I'd like that changes in the build process are discussed in the >>>>> mailing list from time to time... I've put a lot of effort into making it >>>>> work and if we have regressions I'd like to understand them... >>>>> >>>>> Guille >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> 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 <+33%206%2052%2070%2066%2013> >>>>> >>>> >>>> >>> >> >

Dec. 16, 2017

Re: [Pharo-dev] Do we have this iterator?

by Stephane Ducasse

So true :) Stef On Sat, Dec 16, 2017 at 12:12 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 16 December 2017 at 17:28, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> Never try to read regexp, it's write only > > > its highly susceptible to Kernighan's Lever to shoot yourself in the foot... > "You separate the bullet from the gun with a hyperoptimized regexp, > and then you transport it to your foot using several typeglobs. > However, the program fails to run and you can't correct it since > you don't understand what the hell it is you've written." > http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html > > cheers -ben > > >> >> >> 2017-12-16 9:09 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>> ouaaahhhhhh ;) >>> My problem was that I had complex lines as elements. and I will not be >>> able to remember and express anything with regex >>> >>> On Tue, Dec 12, 2017 at 4:36 PM, Martin Dias <tinchodias(a)gmail.com> >>> wrote: >>> > If your input was a string instead of a list of lines, you had: >>> > >>> > '[^4]*4|.+' asRegex matchesIn: '1234123123456' >>> >>>> >>> > "an OrderedCollection('1234' '1231234' '56')" >>> > >>> > MartÃn >>> > >>> > On Tue, Dec 12, 2017 at 9:33 AM, Stephane Ducasse >>> > <stepharo.self(a)gmail.com> >>> > wrote: >>> >> >>> >> Thanks sean. >>> >> I will build it because for example I had list of lines and I needed >>> >> to split the input depending >>> >> on patterns inside the lines.... and sadly this was not for an advent >>> >> of >>> >> code. >>> >> >>> >> Rmoders suggested >>> >> aggregateRuns: >>> >> splitOn: >>> >> but this is not the same. >>> >> >>> >> >>> >> Stef >>> >> >>> >> On Tue, Dec 12, 2017 at 2:33 AM, Sean P. DeNigris >>> >> <sean(a)clipperadams.com> >>> >> wrote: >>> >> > Stephane Ducasse-3 wrote >>> >> >> #(1 2 3 4 1 2 3 5 6 ) consumeUntil: [:each | each = 4) >>> >> >>>>> {#(1 2 3 4) . #( 1 2 3 5 6 )} >>> >> > >>> >> > The shortest kernel thing I could come up with took two steps: `{ >>> >> > #(1 2 >>> >> > 3 4 >>> >> > 1 2 3 5 6 ) copyUpThrough: 4. >>> >> > #(1 2 3 4 1 2 3 5 6 ) copyAfter: 4 }`. The splitting messages seem >>> >> > to >>> >> > all >>> >> > eat the separator. >>> >> > >>> >> > >>> >> > >>> >> > ----- >>> >> > Cheers, >>> >> > Sean >>> >> > -- >>> >> > Sent from: >>> >> > http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> >> > >>> >> >>> > >>> >> >

Dec. 16, 2017

Re: [Pharo-dev] Do we have this iterator?

by Ben Coman

On 16 December 2017 at 17:28, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Never try to read regexp, it's write only > its highly susceptible to Kernighan's Lever to shoot yourself in the foot... "You separate the bullet from the gun with a hyperoptimized regexp, and then you transport it to your foot using several typeglobs. However, the program fails to run and you can't correct it since you don't understand what the hell it is you've written." http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html cheers -ben > > 2017-12-16 9:09 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> ouaaahhhhhh ;) >> My problem was that I had complex lines as elements. and I will not be >> able to remember and express anything with regex >> >> On Tue, Dec 12, 2017 at 4:36 PM, Martin Dias <tinchodias(a)gmail.com> >> wrote: >> > If your input was a string instead of a list of lines, you had: >> > >> > '[^4]*4|.+' asRegex matchesIn: '1234123123456' >> >>>> >> > "an OrderedCollection('1234' '1231234' '56')" >> > >> > MartÃn >> > >> > On Tue, Dec 12, 2017 at 9:33 AM, Stephane Ducasse < >> stepharo.self(a)gmail.com> >> > wrote: >> >> >> >> Thanks sean. >> >> I will build it because for example I had list of lines and I needed >> >> to split the input depending >> >> on patterns inside the lines.... and sadly this was not for an advent >> of >> >> code. >> >> >> >> Rmoders suggested >> >> aggregateRuns: >> >> splitOn: >> >> but this is not the same. >> >> >> >> >> >> Stef >> >> >> >> On Tue, Dec 12, 2017 at 2:33 AM, Sean P. DeNigris < >> sean(a)clipperadams.com> >> >> wrote: >> >> > Stephane Ducasse-3 wrote >> >> >> #(1 2 3 4 1 2 3 5 6 ) consumeUntil: [:each | each = 4) >> >> >>>>> {#(1 2 3 4) . #( 1 2 3 5 6 )} >> >> > >> >> > The shortest kernel thing I could come up with took two steps: `{ >> #(1 2 >> >> > 3 4 >> >> > 1 2 3 5 6 ) copyUpThrough: 4. >> >> > #(1 2 3 4 1 2 3 5 6 ) copyAfter: 4 }`. The splitting messages seem to >> >> > all >> >> > eat the separator. >> >> > >> >> > >> >> > >> >> > ----- >> >> > Cheers, >> >> > Sean >> >> > -- >> >> > Sent from: >> >> > http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >> > >> >> >> > >> >> >

Dec. 16, 2017

Re: [Pharo-dev] Do we have this iterator?

by Nicolas Cellier

Never try to read regexp, it's write only 2017-12-16 9:09 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > ouaaahhhhhh ;) > My problem was that I had complex lines as elements. and I will not be > able to remember and express anything with regex > > On Tue, Dec 12, 2017 at 4:36 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > If your input was a string instead of a list of lines, you had: > > > > '[^4]*4|.+' asRegex matchesIn: '1234123123456' > >>>> > > "an OrderedCollection('1234' '1231234' '56')" > > > > MartÃn > > > > On Tue, Dec 12, 2017 at 9:33 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> > > wrote: > >> > >> Thanks sean. > >> I will build it because for example I had list of lines and I needed > >> to split the input depending > >> on patterns inside the lines.... and sadly this was not for an advent of > >> code. > >> > >> Rmoders suggested > >> aggregateRuns: > >> splitOn: > >> but this is not the same. > >> > >> > >> Stef > >> > >> On Tue, Dec 12, 2017 at 2:33 AM, Sean P. DeNigris < > sean(a)clipperadams.com> > >> wrote: > >> > Stephane Ducasse-3 wrote > >> >> #(1 2 3 4 1 2 3 5 6 ) consumeUntil: [:each | each = 4) > >> >>>>> {#(1 2 3 4) . #( 1 2 3 5 6 )} > >> > > >> > The shortest kernel thing I could come up with took two steps: `{ #(1 > 2 > >> > 3 4 > >> > 1 2 3 5 6 ) copyUpThrough: 4. > >> > #(1 2 3 4 1 2 3 5 6 ) copyAfter: 4 }`. The splitting messages seem to > >> > all > >> > eat the separator. > >> > > >> > > >> > > >> > ----- > >> > Cheers, > >> > Sean > >> > -- > >> > Sent from: > >> > http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >> > > >> > > > >

Dec. 16, 2017

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

> On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Esteban, > > On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> >>> On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> Hi Esteban, >>> >>> I had no problems following the process (Ubuntu 16.04, >>> Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-) >>> >>> I guess that you have already thought of this, but... Is there any >>> reason why we can't just put up a dialog asking for the user's github >>> credentials and fogbugz issue number and then automatically clone the >>> repository, configure the upstream remote and create the issue branch. >>> That would remove most of the remaining manual steps. >>> >>> I realise that it only works for option 1, although where people >>> configure a common pharo-local, it could check for a pre-existing >>> clone and use that one. >> >> "I realiseâ means you tried and it didnât work? >> because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :) >> >> Esteban > > The contribution process works fine (even on linux :-)). > > The "I realise" paragraph is a comment on my suggestion to try and > reduce the number of manual steps required (and is actually wrong). > Just to rephrase (and extend) the suggestion, I think we could create > a single dialog that currently covers the following steps (from your > instructions): > > 1. Clone a fresh repository, or point to an existing repository. > 2. Tell Iceberg about pharo-project > 3. Create a new branch from the fogbugz issue ah, I got lost in translation ;) Esteban > > Cheers, > Alistair > > > >>> >>> Cheers, >>> Alistair >>> >>> On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> Hi! >>>> >>>> Iâm working on simplifying the contribution process, after collecting >>>> opinions/experiences last couple of months. >>>> As you know, Pharo contribution process is still WIP and we aim to have it >>>> as smooth as possible for Pharo 7.0 release. Now, after observe the idea of >>>> the âsystem repositoriesâ was a bad idea because it introduced extra and non >>>> standard âpathâ to contribution, I managed to remove that to reestablish >>>> âthe regular wayâ: you will now need to add pharo repository just as any >>>> other repository you add, by cloning or adding local repository. >>>> >>>> I took Guilleâs doc and moved it to pharo project (it does not has sense to >>>> have it living in a contributorâs repository when is so important). You can >>>> find it here: >>>> >>>> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >>>> >>>> This document is also updated to reveal this new process, please read it. >>>> >>>> How to update your startup scripts? >>>> Some people has added startup scripts to easy the first part of >>>> contribution. Instead enabling system repositories, etc. you now need to >>>> replace that with this: >>>> >>>> (IceRepositoryCreator new >>>> location: '/path/to/pharo-project/pharo' asFileReference; >>>> subdirectory: 'src'; >>>> createRepository) >>>> register >>>> >>>> PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is very >>>> important that document reflects new process and works reliable in different >>>> scenarios (I validated it on macOS and Windows, and assumed it worked fine >>>> on linux but you knowâ¦ bad assumptions is the base of failure ;) ) >>>> >>>> Iâm eager to hear your feedback and continue enhancing the process. >>>> >>>> (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) >>>> >>>> cheers! >>>> Esteban

Dec. 16, 2017

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Alistair Grant

Hi Esteban, On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Esteban, >> >> I had no problems following the process (Ubuntu 16.04, >> Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-) >> >> I guess that you have already thought of this, but... Is there any >> reason why we can't just put up a dialog asking for the user's github >> credentials and fogbugz issue number and then automatically clone the >> repository, configure the upstream remote and create the issue branch. >> That would remove most of the remaining manual steps. >> >> I realise that it only works for option 1, although where people >> configure a common pharo-local, it could check for a pre-existing >> clone and use that one. > > "I realiseâ means you tried and it didnât work? > because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :) > > Esteban The contribution process works fine (even on linux :-)). The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions): 1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue Cheers, Alistair >> >> Cheers, >> Alistair >> >> On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> Hi! >>> >>> Iâm working on simplifying the contribution process, after collecting >>> opinions/experiences last couple of months. >>> As you know, Pharo contribution process is still WIP and we aim to have it >>> as smooth as possible for Pharo 7.0 release. Now, after observe the idea of >>> the âsystem repositoriesâ was a bad idea because it introduced extra and non >>> standard âpathâ to contribution, I managed to remove that to reestablish >>> âthe regular wayâ: you will now need to add pharo repository just as any >>> other repository you add, by cloning or adding local repository. >>> >>> I took Guilleâs doc and moved it to pharo project (it does not has sense to >>> have it living in a contributorâs repository when is so important). You can >>> find it here: >>> >>> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >>> >>> This document is also updated to reveal this new process, please read it. >>> >>> How to update your startup scripts? >>> Some people has added startup scripts to easy the first part of >>> contribution. Instead enabling system repositories, etc. you now need to >>> replace that with this: >>> >>> (IceRepositoryCreator new >>> location: '/path/to/pharo-project/pharo' asFileReference; >>> subdirectory: 'src'; >>> createRepository) >>> register >>> >>> PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is very >>> important that document reflects new process and works reliable in different >>> scenarios (I validated it on macOS and Windows, and assumed it worked fine >>> on linux but you knowâ¦ bad assumptions is the base of failure ;) ) >>> >>> Iâm eager to hear your feedback and continue enhancing the process. >>> >>> (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) >>> >>> cheers! >>> Esteban >> > >

Dec. 16, 2017

Re: [Pharo-dev] Does pharo build not retry anymore?

by Pavel Krivanek

The problems were related UIManager initialization and consequences of the opening of the Welcome window. -- Pavel 2017-12-16 9:12 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Pavel what was the problem? > > Stef > > > On Tue, Dec 12, 2017 at 9:34 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> The variable value was reverted to the original value. Thanks. >> >> -- Pavel >> >> 2017-12-12 20:13 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> >>> Yes, with Marcus we decreased the retryTimes variable two weeks ago to >>> 1 because in that time the validations were in really bad shape and >>> literally every validation failed on some random issue and the retries >>> caused enormous build times. It was producing more troubles than profit. It >>> probably can be reverted now because the main problem of the validation >>> instability was suppressed. I will prepare a PR. >>> >>> -- Pavel >>> >>> 2017-12-12 18:52 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>>> I see that we are retrying tests only once, which is causing most (if >>>> not all) pull requests to fail sporadically... >>>> >>>> Maybe it got lost because of a mistake? >>>> >>>> Also, I'd like that changes in the build process are discussed in the >>>> mailing list from time to time... I've put a lot of effort into making it >>>> work and if we have regressions I'd like to understand them... >>>> >>>> Guille >>>> >>>> -- >>>> >>>> >>>> >>>> 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 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >> >

Dec. 16, 2017

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Stephane Ducasse

Yes now I have some pending commits that I do not want to lose so I will fileout them and publish them. Stef On Sat, Dec 16, 2017 at 9:19 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 16 Dec 2017, at 09:15, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > download latest image and follow the steps explained here: > > https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > > > side note: please do not try to adapt this steps to what you already know. > is better if you try this steps âblindlyâ and later you do a synthesis > between what you learned and what you know :) > > Esteban > > > Esteban > > On 16 Dec 2017, at 09:07, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > esteban > > to try the new way. What should I do? > Just download a new version or reclone? May be I will refork and > reclone to be sure. > > Stef > > On Sat, Dec 16, 2017 at 9:05 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Esteban, > > I had no problems following the process (Ubuntu 16.04, > Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-) > > I guess that you have already thought of this, but... Is there any > reason why we can't just put up a dialog asking for the user's github > credentials and fogbugz issue number and then automatically clone the > repository, configure the upstream remote and create the issue branch. > That would remove most of the remaining manual steps. > > I realise that it only works for option 1, although where people > configure a common pharo-local, it could check for a pre-existing > clone and use that one. > > > "I realiseâ means you tried and it didnât work? > because in my tests it worked as good as the first one (I tested on > windows), but that may need to be âre-validatedâ :) > > Esteban > > > Cheers, > Alistair > > On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi! > > Iâm working on simplifying the contribution process, after collecting > opinions/experiences last couple of months. > As you know, Pharo contribution process is still WIP and we aim to have it > as smooth as possible for Pharo 7.0 release. Now, after observe the idea of > the âsystem repositoriesâ was a bad idea because it introduced extra and non > standard âpathâ to contribution, I managed to remove that to reestablish > âthe regular wayâ: you will now need to add pharo repository just as any > other repository you add, by cloning or adding local repository. > > I took Guilleâs doc and moved it to pharo project (it does not has sense to > have it living in a contributorâs repository when is so important). You can > find it here: > > https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > > This document is also updated to reveal this new process, please read it. > > How to update your startup scripts? > Some people has added startup scripts to easy the first part of > contribution. Instead enabling system repositories, etc. you now need to > replace that with this: > > (IceRepositoryCreator new > location: '/path/to/pharo-project/pharo' asFileReference; > subdirectory: 'src'; > createRepository) > register > > PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is very > important that document reflects new process and works reliable in different > scenarios (I validated it on macOS and Windows, and assumed it worked fine > on linux but you knowâ¦ bad assumptions is the base of failure ;) ) > > Iâm eager to hear your feedback and continue enhancing the process. > > (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) > > cheers! > Esteban > > > > > > >

Dec. 16, 2017

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

> On 16 Dec 2017, at 09:15, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > download latest image and follow the steps explained here: > > https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> side note: please do not try to adapt this steps to what you already know. is better if you try this steps âblindlyâ and later you do a synthesis between what you learned and what you know :) Esteban > > Esteban > >> On 16 Dec 2017, at 09:07, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: >> >> esteban >> >> to try the new way. What should I do? >> Just download a new version or reclone? May be I will refork and >> reclone to be sure. >> >> Stef >> >> On Sat, Dec 16, 2017 at 9:05 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> >>>> On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710(a)gmail.com <mailto:akgrant0710@gmail.com>> wrote: >>>> >>>> Hi Esteban, >>>> >>>> I had no problems following the process (Ubuntu 16.04, >>>> Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-) >>>> >>>> I guess that you have already thought of this, but... Is there any >>>> reason why we can't just put up a dialog asking for the user's github >>>> credentials and fogbugz issue number and then automatically clone the >>>> repository, configure the upstream remote and create the issue branch. >>>> That would remove most of the remaining manual steps. >>>> >>>> I realise that it only works for option 1, although where people >>>> configure a common pharo-local, it could check for a pre-existing >>>> clone and use that one. >>> >>> "I realiseâ means you tried and it didnât work? >>> because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :) >>> >>> Esteban >>> >>>> >>>> Cheers, >>>> Alistair >>>> >>>> On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>>> Hi! >>>>> >>>>> Iâm working on simplifying the contribution process, after collecting >>>>> opinions/experiences last couple of months. >>>>> As you know, Pharo contribution process is still WIP and we aim to have it >>>>> as smooth as possible for Pharo 7.0 release. Now, after observe the idea of >>>>> the âsystem repositoriesâ was a bad idea because it introduced extra and non >>>>> standard âpathâ to contribution, I managed to remove that to reestablish >>>>> âthe regular wayâ: you will now need to add pharo repository just as any >>>>> other repository you add, by cloning or adding local repository. >>>>> >>>>> I took Guilleâs doc and moved it to pharo project (it does not has sense to >>>>> have it living in a contributorâs repository when is so important). You can >>>>> find it here: >>>>> >>>>> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> >>>>> >>>>> This document is also updated to reveal this new process, please read it. >>>>> >>>>> How to update your startup scripts? >>>>> Some people has added startup scripts to easy the first part of >>>>> contribution. Instead enabling system repositories, etc. you now need to >>>>> replace that with this: >>>>> >>>>> (IceRepositoryCreator new >>>>> location: '/path/to/pharo-project/pharo' asFileReference; >>>>> subdirectory: 'src'; >>>>> createRepository) >>>>> register >>>>> >>>>> PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is very >>>>> important that document reflects new process and works reliable in different >>>>> scenarios (I validated it on macOS and Windows, and assumed it worked fine >>>>> on linux but you knowâ¦ bad assumptions is the base of failure ;) ) >>>>> >>>>> Iâm eager to hear your feedback and continue enhancing the process. >>>>> >>>>> (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) >>>>> >>>>> cheers! >>>>> Esteban >>>> >>> >>> >> >

Dec. 16, 2017