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

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

by Stephane Ducasse

I committed my code for issue 20861 and I do not understand what I see I do not understand why I get local changes with empty packages. :( Stef On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I did a little pass on the wiki to make the flow clearer > > > On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> In the tutorial: >> >> - Put a little heading before >> >> "You need to add pharo repository as a remote >> (git@github.com:pharo-project/pharo.git)." >> >> On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> I double clicked and it did a massive amount of stuff and finally told >>> me that it is up to date. >>> >>> >>> On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>>> OK so I restarted everything from scratch: >>>> - deleted my fork >>>> - reforked >>>> - clone pharo again >>>> - here is some feedback >>>> >>>> In the tutorial add /pharo + src in the screenshot >>>> >>>> >>>> Then when I add the local repository I get uncommited changes and I do >>>> not understand why? >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>> >>>>> 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> 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 Stephane Ducasse

I did a little pass on the wiki to make the flow clearer On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > In the tutorial: > > - Put a little heading before > > "You need to add pharo repository as a remote > (git@github.com:pharo-project/pharo.git)." > > On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> I double clicked and it did a massive amount of stuff and finally told >> me that it is up to date. >> >> >> On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> OK so I restarted everything from scratch: >>> - deleted my fork >>> - reforked >>> - clone pharo again >>> - here is some feedback >>> >>> In the tutorial add /pharo + src in the screenshot >>> >>> >>> Then when I add the local repository I get uncommited changes and I do >>> not understand why? >>> >>> >>> >>> >>> >>> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> >>>> 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> 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 Stephane Ducasse

In the tutorial: - Put a little heading before "You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)." On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I double clicked and it did a massive amount of stuff and finally told > me that it is up to date. > > > On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> OK so I restarted everything from scratch: >> - deleted my fork >> - reforked >> - clone pharo again >> - here is some feedback >> >> In the tutorial add /pharo + src in the screenshot >> >> >> Then when I add the local repository I get uncommited changes and I do >> not understand why? >> >> >> >> >> >> On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>> 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> 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 Stephane Ducasse

I double clicked and it did a massive amount of stuff and finally told me that it is up to date. On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > OK so I restarted everything from scratch: > - deleted my fork > - reforked > - clone pharo again > - here is some feedback > > In the tutorial add /pharo + src in the screenshot > > > Then when I add the local repository I get uncommited changes and I do > not understand why? > > > > > > On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> 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> 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 Stephane Ducasse

OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback In the tutorial add /pharo + src in the screenshot Then when I add the local repository I get uncommited changes and I do not understand why? On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > 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> 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] [Pharo 7.0-dev] Build #381: 20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference

by Alistair Grant

Hi Stef, On 16 December 2017 at 16:58, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > So I would like to understand (sincerly) what was the problem and what > is the gain? > I learned that we can ask a collection a readStream and writeStream already. > And now we can do anyCollection readStreamDo: and writeStreamDo: > Why not? Cyril proposed this, so may chime in with more information, but... Take a look at http://forum.world.st/Polymorphism-between-Strings-and-FileReference-tt5059… The advantages are: - provides polymorphism with FileReference - you don't need to know whether the stream needs to be closed or not as read/writeStreamDo: takes care of it for you. > On Sat, Dec 16, 2017 at 4:42 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Hi >> >> Do we really want this? >> I do not understand why a string is a fileReference? >> String has far too many methods and we are even adding more and I do >> not understand why. Can you clarify what you're asking (about "why a string is a fileReference")? To be clear, SequencableCollection>>read/writeStreamDo: open a stream on the receiver (typically a string) and then pass it to the supplied block. Nothing to do with a fileReference (apart from the polymorphism). Cheers, Alistair

Dec. 16, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #381: 20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference

by Stephane Ducasse

So I would like to understand (sincerly) what was the problem and what is the gain? I learned that we can ask a collection a readStream and writeStream already. And now we can do anyCollection readStreamDo: and writeStreamDo: Why not? On Sat, Dec 16, 2017 at 4:42 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > Do we really want this? > I do not understand why a string is a fileReference? > String has far too many methods and we are even adding more and I do > not understand why. > > Stef > > > On Thu, Dec 14, 2017 at 12:01 PM, <ci-pharo-ci-jenkins2(a)inria.fr> wrote: >> There is a new Pharo build available! >> >> The status of the build #381 was: SUCCESS. >> >> The Pull Request #605 was integrated: "20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference" >> Pull request url: https://github.com/pharo-project/pharo/pull/605 >> >> Issue Url: https://pharo.fogbugz.com/f/cases/20796 >> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #381: 20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference

by Stephane Ducasse

Hi Do we really want this? I do not understand why a string is a fileReference? String has far too many methods and we are even adding more and I do not understand why. Stef On Thu, Dec 14, 2017 at 12:01 PM, <ci-pharo-ci-jenkins2(a)inria.fr> wrote: > There is a new Pharo build available! > > The status of the build #381 was: SUCCESS. > > The Pull Request #605 was integrated: "20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference" > Pull request url: https://github.com/pharo-project/pharo/pull/605 > > Issue Url: https://pharo.fogbugz.com/f/cases/20796 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2017

Re: [Pharo-dev] Epicea feedback - save points

by Martin Dias

El 16 dic. 2017 5:04 AM, "Stephane Ducasse" <stepharo.self(a)gmail.com> escribiÃ³: I love epicea :) Did you see that now people use my extension to generate docs :) no i didnt! how could i see that? Stef On Sat, Dec 16, 2017 at 9:03 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Thanks Martin!!! > > On Wed, Dec 13, 2017 at 1:29 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >> Hi >> >> When you "save and close" or "save as..." then next changes will go to a new >> log file. Then, they will have a new item of the left of the browser (as >> Stef said). >> When you just "save", I agree I'd like that. It was there originally but I >> disabled it because of a bug related with the announcement. Apparently now >> it can be re-enabled: >> https://pharo.fogbugz.com/f/cases/18754/Epicea-should-log-image-saving >> >> MartÃn >> >> On Wed, Dec 13, 2017 at 8:52 AM, Stephane Ducasse < stepharo.self(a)gmail.com> >> wrote: >>> >>> Ok so we should check because it should not be complex to add that. >>> The model is quite nice. >>> >>> On Wed, Dec 13, 2017 at 11:47 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> > Hi Stef, >>> > >>> > I think that is incorrect. Its easy to be certain... >>> > 1. Open Epicea >>> > 2. Save and continue >>> > 3. Open Epicea and observe there is no difference >>> > >>> > cheers -ben >>> > >>> > >>> > On 13 December 2017 at 17:59, Stephane Ducasse < stepharo.self(a)gmail.com> >>> > wrote: >>> >> >>> >> I think that epicea save point are the list elements on the left. >>> >> >>> >> >>> >> On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl <norbert(a)hartl.name> >>> >> wrote: >>> >> > Same for me. I thought the last save point would be the last session >>> >> > in >>> >> > the list but I donât think that is really true. So Iâm confused by >>> >> > Epicea, >>> >> > too. >>> >> > >>> >> > Norbert >>> >> > >>> >> >> Am 13.12.2017 um 08:27 schrieb Ben Coman <btc(a)openinworld.com>: >>> >> >> >>> >> >> When I'm in need Epicea, the common scenario is that I've working in >>> >> >> the same session of an Image most of the day, or even days, and I've >>> >> >> done >>> >> >> something stupid to lock up the UI, and its only been an hour since >>> >> >> my last >>> >> >> save point (force of habit). When I review Epicea, "Filter > Show >>> >> >> latest >>> >> >> changes" its still ahrd to determine which changes I'm missing. >>> >> >> What I've >>> >> >> just realised is I miss the visibility of the Save Point in the old >>> >> >> changes >>> >> >> system. I'd find it really useful for the save points to be show in >>> >> >> the >>> >> >> changes list, and also a filter I'd find really useful is "Shows >>> >> >> latest >>> >> >> changes since last save". >>> >> >> >>> >> >> >>> >> >> cheers -ben >>> >> > >>> >> >>> > >>> >>

Dec. 16, 2017

[Pharo 7.0-dev] Build #387: 20870-Spec-FastTable-badly-support-drag-and-drop

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

There is a new Pharo build available! The status of the build #387 was: FAILURE. The Pull Request #608 was integrated: "20870-Spec-FastTable-badly-support-drag-and-drop" Pull request url: https://github.com/pharo-project/pharo/pull/608 Issue Url: https://pharo.fogbugz.com/f/cases/20870 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2017