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

Re: [Pharo-dev] Stuck trying to contribute

by Sven Van Caekenberghe

Alistair, Are steps 8 & 9 needed, since the latest image should be in sync with the latest dev version, no ? Sven @Pavel, thanks as well. A lot seems possible with the API. I hope to be able to try later tonight. > On 15 Nov 2017, at 21:53, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven, > > On 15 November 2017 at 20:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Yes, it is working for me too now, and it is actually pretty nice. >> >> I wonder though what the best way is to keep your personal fork up to date ? >> >> I managed to do it with a PR from the fork to the origin (or is it the reverse ?), like this >> >> https://github.com/svenvc/pharo/pull/1 >> >> but it felt a bit weird because obviously the diff is large and I had the impression that the CI process than had to process all this. >> >> Maybe there is a better/easier/more correct way ? > > I only update my fork when I'm starting from a fresh image - my > understanding is that upgrading an image is not supported at the > moment. > > Set up the repository: > > cd emptydirectory > wget 'the latest 7.0 image' > git clone git@github.com:pharo-project/pharo.git pharo-core > cd pharo-core > git remote add $username git@github.com:$username/pharo.git > cd .. > > Once the repository has been set up, the following script: > > 1. Configures Iceberg to show system repositories > 2. Finds the pharo repository. > 3. Finds the two remotes (origin and $username, from above) > 4. Configures Iceberg to pull from origin and push to $username by default. > 5. Checks out the development branch > > and finally does what you were asking about, updating the fork from the origin > > 6. Pull from origin > 7. Push to fork ($username) > 8, Checkout the images commit > 9. Reloads modified packages > > > | location username pharoRepository origin myfork | > > location := 'pharo-core'. > username := 'myusername'. > > Iceberg showSystemRepositories: true. > pharoRepository := IceRepository registry detect: [ :each | each name > = 'pharo' ]. > pharoRepository location: location asFileReference. > origin := pharoRepository remotes detect: [ :each | each remoteName = > 'origin' ]. > myfork := pharoRepository remotes detect: [ :each | each remoteName = > username ]. > pharoRepository pushRemote: myfork. > pharoRepository pullRemote: origin. > pharoRepository checkoutBranch: 'development'. > pharoRepository backend pullFrom: origin. > pharoRepository push. > pharoRepository checkoutBranch: (SystemVersion current commitHash). > [(pharoRepository savedPackages select: [:aPackage | aPackage isLoaded > and: [ aPackage isModified ]]) do: #reload ] on: MCMergeOrLoadWarning > do: [ :warning | warning resume: true ]. > > 'Loaded pharo-core' inspect. > > > I always have OSSubprocess loaded, so it would actually be easy to > automate the cloning and configuration of the repository. I might do > that next week. > > Cheers, > Alistair > > > >>> On 15 Nov 2017, at 20:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> Just to add a positive note to this discussion: >>> >>> After cloning the pharo repository, adding my fork as a remote and >>> using Guille's scripts from earlier this year to configure the >>> repositories in image, I was able to: >>> >>> - Create new branch from Fogbugz issue... >>> - Make the changes >>> - Push the changes up to my fork (Synchronise repository) >>> - Create pull request... >>> - Make some more changes >>> - Push changes to my fork >>> >>> All from within the image, without any problems. >>> >>> There's still plenty that is manual and outside the image, and it >>> would be nice to have a GUI that guided you through the process (at >>> the moment you need to know what steps to do and in what order), but >>> we have a good solid basis for moving forward. >>> >>> Cheers, >>> Alistair >>> >>> >>> >>> On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> >>>>> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>>> >>>>> Sven >>>>> >>>>> have a look at the TipsAndTricks new booklet available at http://books.pharo.org. There is a configuration for iceberg that sets and reduce >>>>> the pain for me. >>>> >>>> Ah, OK, found it. Thanks. >>>> >>>> Nice document BTW ;-) >>>> >>>>> Stef >>>>> >>>>> >>>>> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>> >>>>>> On 31 Oct 2017, at 10:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>>>> >>>>>> If you give me precise instructions I can update the post :) >>>>> >>>>> precise instructions is: >>>>> - do not use https, use ssh >>>>> - if you do not follow our recommendation and you insist on use https, add your credentials before doing any commit. >>>>> >>>>>> >>>>>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> I think I succeeded: >>>>>> >>>>>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments >>>>>> https://github.com/pharo-project/pharo/pull/420 >>>>>> >>>>>> It does contain 4 identical commits due to my troubles earlier on. >>>>>> I also did not see a confirmation by way of an #inform: after the pull request in Iceberg. >>>>>> >>>>>>> On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>>> >>>>>>>> hi, >>>>>>>> >>>>>>>> thing is, you should not use https authentication (and the guide should not point to it) >>>>>>>> Using SSH mode works out of the box. >>>>>>>> Using HTTPS there is currently a bug and the workaround is to introduce your credentials *before* trying to commit (in settings) >>>>>>> >>>>>>> Well, after entering my username/password in Settings > Tools > Software Configuration Management > Iceberg > Plaintext Credentials I am one step further - I managed to 'Commit & Push'. >>>>>>> >>>>>>> Thanks ! >>>>>>> >>>>>>>> Esteban >>>>>>>> >>>>>>>>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Sorry, but I am person 237 trying to contribute to Pharo 7 the new way. >>>>>>>>> >>>>>>>>> I was following https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… and I got stuck just before step 3, after trying to do "That will calculate the differences between the checked-out branch and your image, show you the tree with the differences and let you commit (and push)". Specifically, the 'and push' fails. >>>>>>>>> >>>>>>>>> $ sw_vers >>>>>>>>> ProductName: Mac OS X >>>>>>>>> ProductVersion: 10.13 >>>>>>>>> BuildVersion: 17A405 >>>>>>>>> >>>>>>>>> $ curl get.pharo.org/70+vm | bash >>>>>>>>> ... >>>>>>>>> >>>>>>>>> $ ./pharo-ui Pharo.image >>>>>>>>> >>>>>>>>> I now have the following setup, which is correct I think. >>>>>>>>> >>>>>>>>> <Screen Shot 2017-10-30 at 20.28.05.png> >>>>>>>>> >>>>>>>>> I can commit on my local branch (left button), but when I try to do the 'and Push' (right button), things hang after I enter my credentials. >>>>>>>>> >>>>>>>>> Locally, I see >>>>>>>>> >>>>>>>>> $ git status >>>>>>>>> On branch 20613-Improve-some-UUID-comments >>>>>>>>> nothing to commit, working tree clean >>>>>>>>> >>>>>>>>> with the new code already committed >>>>>>>>> >>>>>>>>> $ cat src/Network-UUID.package/UUID.class/class/new.st >>>>>>>>> instance creation >>>>>>>>> new >>>>>>>>> "Create and return a new UUID" >>>>>>>>> >>>>>>>>> "self new" >>>>>>>>> >>>>>>>>> ^ (self new: 16) >>>>>>>>> >>>>>>>>> What did I do wrong ? How do I proceed ? >>>>>>>>> >>>>>>>>> Sven >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> 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 >>>>>> >>>>>> Web: http://guillep.github.io >>>>>> Phone: +33 06 52 70 66 13

Nov. 15, 2017

Re: [Pharo-dev] Stuck trying to contribute

by Alistair Grant

Hi Sven, On 15 November 2017 at 20:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, it is working for me too now, and it is actually pretty nice. > > I wonder though what the best way is to keep your personal fork up to date ? > > I managed to do it with a PR from the fork to the origin (or is it the reverse ?), like this > > https://github.com/svenvc/pharo/pull/1 > > but it felt a bit weird because obviously the diff is large and I had the impression that the CI process than had to process all this. > > Maybe there is a better/easier/more correct way ? I only update my fork when I'm starting from a fresh image - my understanding is that upgrading an image is not supported at the moment. Set up the repository: cd emptydirectory wget 'the latest 7.0 image' git clone git@github.com:pharo-project/pharo.git pharo-core cd pharo-core git remote add $username git@github.com:$username/pharo.git cd .. Once the repository has been set up, the following script: 1. Configures Iceberg to show system repositories 2. Finds the pharo repository. 3. Finds the two remotes (origin and $username, from above) 4. Configures Iceberg to pull from origin and push to $username by default. 5. Checks out the development branch and finally does what you were asking about, updating the fork from the origin 6. Pull from origin 7. Push to fork ($username) 8, Checkout the images commit 9. Reloads modified packages | location username pharoRepository origin myfork | location := 'pharo-core'. username := 'myusername'. Iceberg showSystemRepositories: true. pharoRepository := IceRepository registry detect: [ :each | each name = 'pharo' ]. pharoRepository location: location asFileReference. origin := pharoRepository remotes detect: [ :each | each remoteName = 'origin' ]. myfork := pharoRepository remotes detect: [ :each | each remoteName = username ]. pharoRepository pushRemote: myfork. pharoRepository pullRemote: origin. pharoRepository checkoutBranch: 'development'. pharoRepository backend pullFrom: origin. pharoRepository push. pharoRepository checkoutBranch: (SystemVersion current commitHash). [(pharoRepository savedPackages select: [:aPackage | aPackage isLoaded and: [ aPackage isModified ]]) do: #reload ] on: MCMergeOrLoadWarning do: [ :warning | warning resume: true ]. 'Loaded pharo-core' inspect. I always have OSSubprocess loaded, so it would actually be easy to automate the cloning and configuration of the repository. I might do that next week. Cheers, Alistair >> On 15 Nov 2017, at 20:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Just to add a positive note to this discussion: >> >> After cloning the pharo repository, adding my fork as a remote and >> using Guille's scripts from earlier this year to configure the >> repositories in image, I was able to: >> >> - Create new branch from Fogbugz issue... >> - Make the changes >> - Push the changes up to my fork (Synchronise repository) >> - Create pull request... >> - Make some more changes >> - Push changes to my fork >> >> All from within the image, without any problems. >> >> There's still plenty that is manual and outside the image, and it >> would be nice to have a GUI that guided you through the process (at >> the moment you need to know what steps to do and in what order), but >> we have a good solid basis for moving forward. >> >> Cheers, >> Alistair >> >> >> >> On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>> Sven >>>> >>>> have a look at the TipsAndTricks new booklet available at http://books.pharo.org. There is a configuration for iceberg that sets and reduce >>>> the pain for me. >>> >>> Ah, OK, found it. Thanks. >>> >>> Nice document BTW ;-) >>> >>>> Stef >>>> >>>> >>>> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> >>>>> On 31 Oct 2017, at 10:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>>> >>>>> If you give me precise instructions I can update the post :) >>>> >>>> precise instructions is: >>>> - do not use https, use ssh >>>> - if you do not follow our recommendation and you insist on use https, add your credentials before doing any commit. >>>> >>>>> >>>>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> I think I succeeded: >>>>> >>>>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments >>>>> https://github.com/pharo-project/pharo/pull/420 >>>>> >>>>> It does contain 4 identical commits due to my troubles earlier on. >>>>> I also did not see a confirmation by way of an #inform: after the pull request in Iceberg. >>>>> >>>>>> On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>> >>>>>>> hi, >>>>>>> >>>>>>> thing is, you should not use https authentication (and the guide should not point to it) >>>>>>> Using SSH mode works out of the box. >>>>>>> Using HTTPS there is currently a bug and the workaround is to introduce your credentials *before* trying to commit (in settings) >>>>>> >>>>>> Well, after entering my username/password in Settings > Tools > Software Configuration Management > Iceberg > Plaintext Credentials I am one step further - I managed to 'Commit & Push'. >>>>>> >>>>>> Thanks ! >>>>>> >>>>>>> Esteban >>>>>>> >>>>>>>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Sorry, but I am person 237 trying to contribute to Pharo 7 the new way. >>>>>>>> >>>>>>>> I was following https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… and I got stuck just before step 3, after trying to do "That will calculate the differences between the checked-out branch and your image, show you the tree with the differences and let you commit (and push)". Specifically, the 'and push' fails. >>>>>>>> >>>>>>>> $ sw_vers >>>>>>>> ProductName: Mac OS X >>>>>>>> ProductVersion: 10.13 >>>>>>>> BuildVersion: 17A405 >>>>>>>> >>>>>>>> $ curl get.pharo.org/70+vm | bash >>>>>>>> ... >>>>>>>> >>>>>>>> $ ./pharo-ui Pharo.image >>>>>>>> >>>>>>>> I now have the following setup, which is correct I think. >>>>>>>> >>>>>>>> <Screen Shot 2017-10-30 at 20.28.05.png> >>>>>>>> >>>>>>>> I can commit on my local branch (left button), but when I try to do the 'and Push' (right button), things hang after I enter my credentials. >>>>>>>> >>>>>>>> Locally, I see >>>>>>>> >>>>>>>> $ git status >>>>>>>> On branch 20613-Improve-some-UUID-comments >>>>>>>> nothing to commit, working tree clean >>>>>>>> >>>>>>>> with the new code already committed >>>>>>>> >>>>>>>> $ cat src/Network-UUID.package/UUID.class/class/new.st >>>>>>>> instance creation >>>>>>>> new >>>>>>>> "Create and return a new UUID" >>>>>>>> >>>>>>>> "self new" >>>>>>>> >>>>>>>> ^ (self new: 16) >>>>>>>> >>>>>>>> What did I do wrong ? How do I proceed ? >>>>>>>> >>>>>>>> Sven >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> 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 >>>>> >>>>> Web: http://guillep.github.io >>>>> Phone: +33 06 52 70 66 13 >>>> >>>> >>> >>> >> > >

Nov. 15, 2017

Re: [Pharo-dev] Stuck trying to contribute

by Pavel Krivanek

I use something like this: pharoRepository := IceRepository registry detect: [ :each | each name = 'pharo' ]. pharoRepository checkoutBranch: 'development'. pharoRepository backend pullFrom: pharoRepository origin. pharoRepository push. Beware, it switches the branch and you can loose non-committed work. It supposes origin to be pharo-project/pharo and your fork to be set as default push remote. -- Pavel 2017-11-15 20:44 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Yes, it is working for me too now, and it is actually pretty nice. > > I wonder though what the best way is to keep your personal fork up to date > ? > > I managed to do it with a PR from the fork to the origin (or is it the > reverse ?), like this > > https://github.com/svenvc/pharo/pull/1 > > but it felt a bit weird because obviously the diff is large and I had the > impression that the CI process than had to process all this. > > Maybe there is a better/easier/more correct way ? > > > On 15 Nov 2017, at 20:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Just to add a positive note to this discussion: > > > > After cloning the pharo repository, adding my fork as a remote and > > using Guille's scripts from earlier this year to configure the > > repositories in image, I was able to: > > > > - Create new branch from Fogbugz issue... > > - Make the changes > > - Push the changes up to my fork (Synchronise repository) > > - Create pull request... > > - Make some more changes > > - Push changes to my fork > > > > All from within the image, without any problems. > > > > There's still plenty that is manual and outside the image, and it > > would be nice to have a GUI that guided you through the process (at > > the moment you need to know what steps to do and in what order), but > > we have a good solid basis for moving forward. > > > > Cheers, > > Alistair > > > > > > > > On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> > >>> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >>> > >>> Sven > >>> > >>> have a look at the TipsAndTricks new booklet available at > http://books.pharo.org. There is a configuration for iceberg that sets > and reduce > >>> the pain for me. > >> > >> Ah, OK, found it. Thanks. > >> > >> Nice document BTW ;-) > >> > >>> Stef > >>> > >>> > >>> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano < > estebanlm(a)gmail.com> wrote: > >>> > >>> > >>>> On 31 Oct 2017, at 10:37, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >>>> > >>>> If you give me precise instructions I can update the post :) > >>> > >>> precise instructions is: > >>> - do not use https, use ssh > >>> - if you do not follow our recommendation and you insist on use https, > add your credentials before doing any commit. > >>> > >>>> > >>>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>> I think I succeeded: > >>>> > >>>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments > >>>> https://github.com/pharo-project/pharo/pull/420 > >>>> > >>>> It does contain 4 identical commits due to my troubles earlier on. > >>>> I also did not see a confirmation by way of an #inform: after the > pull request in Iceberg. > >>>> > >>>>> On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>>> > >>>>> > >>>>> > >>>>>> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >>>>>> > >>>>>> hi, > >>>>>> > >>>>>> thing is, you should not use https authentication (and the guide > should not point to it) > >>>>>> Using SSH mode works out of the box. > >>>>>> Using HTTPS there is currently a bug and the workaround is to > introduce your credentials *before* trying to commit (in settings) > >>>>> > >>>>> Well, after entering my username/password in Settings > Tools > > Software Configuration Management > Iceberg > Plaintext Credentials I am > one step further - I managed to 'Commit & Push'. > >>>>> > >>>>> Thanks ! > >>>>> > >>>>>> Esteban > >>>>>> > >>>>>>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> Sorry, but I am person 237 trying to contribute to Pharo 7 the new > way. > >>>>>>> > >>>>>>> I was following https://github.com/guillep/ > PharoIntegrationProcess/wiki/Contribute-a-fix-to-Pharo and I got stuck > just before step 3, after trying to do "That will calculate the differences > between the checked-out branch and your image, show you the tree with the > differences and let you commit (and push)". Specifically, the 'and push' > fails. > >>>>>>> > >>>>>>> $ sw_vers > >>>>>>> ProductName: Mac OS X > >>>>>>> ProductVersion: 10.13 > >>>>>>> BuildVersion: 17A405 > >>>>>>> > >>>>>>> $ curl get.pharo.org/70+vm | bash > >>>>>>> ... > >>>>>>> > >>>>>>> $ ./pharo-ui Pharo.image > >>>>>>> > >>>>>>> I now have the following setup, which is correct I think. > >>>>>>> > >>>>>>> <Screen Shot 2017-10-30 at 20.28.05.png> > >>>>>>> > >>>>>>> I can commit on my local branch (left button), but when I try to > do the 'and Push' (right button), things hang after I enter my credentials. > >>>>>>> > >>>>>>> Locally, I see > >>>>>>> > >>>>>>> $ git status > >>>>>>> On branch 20613-Improve-some-UUID-comments > >>>>>>> nothing to commit, working tree clean > >>>>>>> > >>>>>>> with the new code already committed > >>>>>>> > >>>>>>> $ cat src/Network-UUID.package/UUID.class/class/new.st > >>>>>>> instance creation > >>>>>>> new > >>>>>>> "Create and return a new UUID" > >>>>>>> > >>>>>>> "self new" > >>>>>>> > >>>>>>> ^ (self new: 16) > >>>>>>> > >>>>>>> What did I do wrong ? How do I proceed ? > >>>>>>> > >>>>>>> Sven > >>>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> 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 > >>>> > >>>> Web: http://guillep.github.io > >>>> Phone: +33 06 52 70 66 13 > >>> > >>> > >> > >> > > > > >

Nov. 15, 2017

Re: [Pharo-dev] Stuck trying to contribute

by Sven Van Caekenberghe

Yes, it is working for me too now, and it is actually pretty nice. I wonder though what the best way is to keep your personal fork up to date ? I managed to do it with a PR from the fork to the origin (or is it the reverse ?), like this https://github.com/svenvc/pharo/pull/1 but it felt a bit weird because obviously the diff is large and I had the impression that the CI process than had to process all this. Maybe there is a better/easier/more correct way ? > On 15 Nov 2017, at 20:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Just to add a positive note to this discussion: > > After cloning the pharo repository, adding my fork as a remote and > using Guille's scripts from earlier this year to configure the > repositories in image, I was able to: > > - Create new branch from Fogbugz issue... > - Make the changes > - Push the changes up to my fork (Synchronise repository) > - Create pull request... > - Make some more changes > - Push changes to my fork > > All from within the image, without any problems. > > There's still plenty that is manual and outside the image, and it > would be nice to have a GUI that guided you through the process (at > the moment you need to know what steps to do and in what order), but > we have a good solid basis for moving forward. > > Cheers, > Alistair > > > > On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Sven >>> >>> have a look at the TipsAndTricks new booklet available at http://books.pharo.org. There is a configuration for iceberg that sets and reduce >>> the pain for me. >> >> Ah, OK, found it. Thanks. >> >> Nice document BTW ;-) >> >>> Stef >>> >>> >>> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>>> On 31 Oct 2017, at 10:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>> >>>> If you give me precise instructions I can update the post :) >>> >>> precise instructions is: >>> - do not use https, use ssh >>> - if you do not follow our recommendation and you insist on use https, add your credentials before doing any commit. >>> >>>> >>>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> I think I succeeded: >>>> >>>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments >>>> https://github.com/pharo-project/pharo/pull/420 >>>> >>>> It does contain 4 identical commits due to my troubles earlier on. >>>> I also did not see a confirmation by way of an #inform: after the pull request in Iceberg. >>>> >>>>> On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> >>>>> >>>>>> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>> >>>>>> hi, >>>>>> >>>>>> thing is, you should not use https authentication (and the guide should not point to it) >>>>>> Using SSH mode works out of the box. >>>>>> Using HTTPS there is currently a bug and the workaround is to introduce your credentials *before* trying to commit (in settings) >>>>> >>>>> Well, after entering my username/password in Settings > Tools > Software Configuration Management > Iceberg > Plaintext Credentials I am one step further - I managed to 'Commit & Push'. >>>>> >>>>> Thanks ! >>>>> >>>>>> Esteban >>>>>> >>>>>>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Sorry, but I am person 237 trying to contribute to Pharo 7 the new way. >>>>>>> >>>>>>> I was following https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… and I got stuck just before step 3, after trying to do "That will calculate the differences between the checked-out branch and your image, show you the tree with the differences and let you commit (and push)". Specifically, the 'and push' fails. >>>>>>> >>>>>>> $ sw_vers >>>>>>> ProductName: Mac OS X >>>>>>> ProductVersion: 10.13 >>>>>>> BuildVersion: 17A405 >>>>>>> >>>>>>> $ curl get.pharo.org/70+vm | bash >>>>>>> ... >>>>>>> >>>>>>> $ ./pharo-ui Pharo.image >>>>>>> >>>>>>> I now have the following setup, which is correct I think. >>>>>>> >>>>>>> <Screen Shot 2017-10-30 at 20.28.05.png> >>>>>>> >>>>>>> I can commit on my local branch (left button), but when I try to do the 'and Push' (right button), things hang after I enter my credentials. >>>>>>> >>>>>>> Locally, I see >>>>>>> >>>>>>> $ git status >>>>>>> On branch 20613-Improve-some-UUID-comments >>>>>>> nothing to commit, working tree clean >>>>>>> >>>>>>> with the new code already committed >>>>>>> >>>>>>> $ cat src/Network-UUID.package/UUID.class/class/new.st >>>>>>> instance creation >>>>>>> new >>>>>>> "Create and return a new UUID" >>>>>>> >>>>>>> "self new" >>>>>>> >>>>>>> ^ (self new: 16) >>>>>>> >>>>>>> What did I do wrong ? How do I proceed ? >>>>>>> >>>>>>> Sven >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> 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 >>>> >>>> Web: http://guillep.github.io >>>> Phone: +33 06 52 70 66 13 >>> >>> >> >> >

Nov. 15, 2017

Re: [Pharo-dev] Stuck trying to contribute

by Alistair Grant

Just to add a positive note to this discussion: After cloning the pharo repository, adding my fork as a remote and using Guille's scripts from earlier this year to configure the repositories in image, I was able to: - Create new branch from Fogbugz issue... - Make the changes - Push the changes up to my fork (Synchronise repository) - Create pull request... - Make some more changes - Push changes to my fork All from within the image, without any problems. There's still plenty that is manual and outside the image, and it would be nice to have a GUI that guided you through the process (at the moment you need to know what steps to do and in what order), but we have a good solid basis for moving forward. Cheers, Alistair On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Sven >> >> have a look at the TipsAndTricks new booklet available at http://books.pharo.org. There is a configuration for iceberg that sets and reduce >> the pain for me. > > Ah, OK, found it. Thanks. > > Nice document BTW ;-) > >> Stef >> >> >> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >>> On 31 Oct 2017, at 10:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>> If you give me precise instructions I can update the post :) >> >> precise instructions is: >> - do not use https, use ssh >> - if you do not follow our recommendation and you insist on use https, add your credentials before doing any commit. >> >>> >>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> I think I succeeded: >>> >>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments >>> https://github.com/pharo-project/pharo/pull/420 >>> >>> It does contain 4 identical commits due to my troubles earlier on. >>> I also did not see a confirmation by way of an #inform: after the pull request in Iceberg. >>> >>> > On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > >>> > >>> > >>> >> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >> >>> >> hi, >>> >> >>> >> thing is, you should not use https authentication (and the guide should not point to it) >>> >> Using SSH mode works out of the box. >>> >> Using HTTPS there is currently a bug and the workaround is to introduce your credentials *before* trying to commit (in settings) >>> > >>> > Well, after entering my username/password in Settings > Tools > Software Configuration Management > Iceberg > Plaintext Credentials I am one step further - I managed to 'Commit & Push'. >>> > >>> > Thanks ! >>> > >>> >> Esteban >>> >> >>> >>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>> >>> Hi, >>> >>> >>> >>> Sorry, but I am person 237 trying to contribute to Pharo 7 the new way. >>> >>> >>> >>> I was following https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… and I got stuck just before step 3, after trying to do "That will calculate the differences between the checked-out branch and your image, show you the tree with the differences and let you commit (and push)". Specifically, the 'and push' fails. >>> >>> >>> >>> $ sw_vers >>> >>> ProductName: Mac OS X >>> >>> ProductVersion: 10.13 >>> >>> BuildVersion: 17A405 >>> >>> >>> >>> $ curl get.pharo.org/70+vm | bash >>> >>> ... >>> >>> >>> >>> $ ./pharo-ui Pharo.image >>> >>> >>> >>> I now have the following setup, which is correct I think. >>> >>> >>> >>> <Screen Shot 2017-10-30 at 20.28.05.png> >>> >>> >>> >>> I can commit on my local branch (left button), but when I try to do the 'and Push' (right button), things hang after I enter my credentials. >>> >>> >>> >>> Locally, I see >>> >>> >>> >>> $ git status >>> >>> On branch 20613-Improve-some-UUID-comments >>> >>> nothing to commit, working tree clean >>> >>> >>> >>> with the new code already committed >>> >>> >>> >>> $ cat src/Network-UUID.package/UUID.class/class/new.st >>> >>> instance creation >>> >>> new >>> >>> "Create and return a new UUID" >>> >>> >>> >>> "self new" >>> >>> >>> >>> ^ (self new: 16) >>> >>> >>> >>> What did I do wrong ? How do I proceed ? >>> >>> >>> >>> Sven >>> >>> >>> >> >>> > >>> >>> >>> >>> >>> >>> -- >>> >>> 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 >>> >>> Web: http://guillep.github.io >>> Phone: +33 06 52 70 66 13 >> >> > >

Nov. 15, 2017

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Thomas Dupriez

Here they are: https://github.com/dupriezt/Pharo-RunToSelectionDebuggerFeature Le 15/11/2017 Ã 10:47, Guillermo Polito a Ã©critÂ : > Thomas, can you try writing some real test cases in SUnit? > > I don't care if they are originally red (they will be because it is > not working). > > The idea is that we capture all these different scenarios and have a > way to know automatically in the future if > Â - we fixed all them > Â - or we have a regression and broke some. > > On Wed, Nov 15, 2017 at 10:44 AM, Thomas Dupriez > <thomas.dupriez(a)ens-paris-saclay.fr > <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: > > > > Le 15/11/2017 Ã 01:19, Ben Coman a Ã©critÂ : >> >> >> On 14 November 2017 at 23:55, Thomas Dupriez >> <thomas.dupriez(a)ens-paris-saclay.fr >> <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: >> >> While working on writing a test, I discovered that just using >> stepThrough instead of stepOver may not be the definitive >> solution. >> >> # Example1: When using the `value` message directly (instead >> of calling a method that does that as in my previous >> example), the RunToHere moves the debugSession to the `value` >> message and not the inside of the block. >> >> `meth2 >> Â Â Â self halt. >> Â Â Â [ >> Â Â Â Â Â Â 1+1. >> Â Â Â Â Â Â 2+2."< cursor before the RunToHere" >> Â Â Â ] ">"value"<result of the RunToHere". >> Â Â Â 3+3. >> Â Â Â "Two stepInto are required after the RunToHere to reach >> the cursor (the `+2` message)"` >> >> # Example2: Going back to using a dedicated method for >> evaluating the block, but increasing the block's size. The >> RunToHere moves the debugSession to the first message of the >> block instead of the pointed one. >> >> `meth3 >> Â Â Â self halt. >> Â Â Â MyClass new evalBlock: >> Â Â Â [ >> Â Â Â Â Â Â 1">"+1"< result of the RunToHere". >> Â Â Â Â Â Â 2+2."< cursor before the RunToHere" >> Â Â Â ]. >> Â Â Â 3+3. >> Â Â Â "One stepInto is required after the RunToHere to reach >> the cursor (the `+2` message)"` >> >> cheers -thomas >> >> >> In both cases, what happens with an additional step-Through? >> >> cheers -ben > # Example1*: > Operation: RunToHere with cursor at the end of the `2+2.` line + 1 > stepThrough. > Result: DebugSession at the `+1`, first instruction of the block > but not the intended position. > Note: Doing an additional stepThrough brings the debugSession to > the intended `+2`. > > `meth2 > Â Â Â self halt. > Â Â Â [ > Â Â Â Â Â Â 1">"+1"<"."result of the RunToHere + 1 stepThrough" > Â Â Â Â Â Â 2+2."< cursor before the RunToHere" > Â Â Â ] ">"value"<result of the RunToHere". > Â Â Â 3+3. > Â Â Â "Two stepInto are required after the RunToHere to reach the > cursor (the `+2` message)"` > > # Example2*: > Operation: RunToHere with cursor at the end of the `2+2.` line + 1 > stepThrough > Result: DebugSession at the intended `+2` position. > Note: The additional stepThrough just moves the DebugSession to > the next instruction. See Example3 for what happens when the > target instruction is further away. > > `meth3 > Â Â Â self halt. > Â Â Â MyClass new evalBlock: > Â Â Â [ > Â Â Â Â Â Â 1">"+1"< result of the RunToHere". > Â Â Â Â Â Â 2">"+2"<result of RunToHere+1stepThrough"."< cursor before > the RunToHere" > Â Â Â ]. > Â Â Â 3+3. > Â Â Â "One stepInto is required after the RunToHere to reach the > cursor (the `+2` message)"` > > > # Example3: > Operation: RunToHere with cursor at the end of the `3+3.` line. + > 1 stepThrough. > Result: DebugSession is at the `+2` instruction, not the intended > `+3` one. > > `meth4 > Â Â Â self halt. > Â Â Â MyClass new evalBlock: > Â Â Â [ > Â Â Â Â Â Â 1">"+1"< result of the RunToHere". > Â Â Â Â Â Â 2">"+2"<result of RunToHere+1stepThrough". > Â Â Â Â Â Â 3">"+3"<result of RunToHere+2stepThrough"."< cursor before > the RunToHere" > Â Â Â ]. > Â Â Â 4+4. > Â Â Â "One stepInto is required after the RunToHere to reach the > cursor (the `+2` message)"` > > cheers -thomas > >> Le 13/11/2017 Ã 17:23, Thomas Dupriez a Ã©critÂ : >>> >>> >>> >>> Le 13/11/2017 Ã 15:56, Ben Coman a Ã©critÂ : >>>> >>>> >>>> On Mon, Nov 13, 2017 at 9:32 PM, Thomas Dupriez >>>> <thomas.dupriez(a)ens-paris-saclay.fr >>>> <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: >>>> >>>> >>>> >>>> Le 13/11/2017 Ã 14:08, Ben Coman a Ã©critÂ : >>>>> >>>>> >>>>> On Mon, Nov 13, 2017 at 8:40 PM, Thomas Dupriez >>>>> <thomas.dupriez(a)ens-paris-saclay.fr >>>>> <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: >>>>> >>>>> I dug a bit in this issue. Here are the results: >>>>> >>>>> >>>>> # Problem raised by Stephanne >>>>> Code like the following is open in the debugger: >>>>> >>>>> Â Â Â `myMethod >>>>> Â Â Â Â Â Â 1+1. <PROGRAMCOUNTER> >>>>> MyClass new myEvalBlock: [ >>>>> 2+2. <CURSOR> >>>>> Â Â Â Â Â Â ]. >>>>> Â Â Â Â Â Â 3+3.` >>>>> >>>>> The program counter is on the 1+1, the cursor is >>>>> at the end of the 2+2 line. >>>>> Right-click, "Run to here". >>>>> -> the program counter moves to the 3+3, and does >>>>> not stop at the 2+2 (where the cursor is). Even >>>>> though the 2+2 does get evaluated (the myEvalBlock >>>>> method evaluates the blocks it receives). >>>>> If there was no code after the block, the debugger >>>>> would jump back to the caller of myMethod. >>>>> >>>>> # Why this happens >>>>> The implementation of RunToHere (source code >>>>> below) is basically to stepOver until the context >>>>> is different or the source code position of the >>>>> program counter is higher or equal to the source >>>>> code position of the cursor/selection. >>>>> >>>>> Since the debugger uses stepOver, it executes >>>>> myEvalBlock without stopping, reaches the 3+3 and >>>>> see it has gone further than the source code >>>>> position of the cursorm so it stops. >>>>> >>>>> Source code of >>>>> DebugSession>>#runToSelection:inContext: >>>>> >>>>> `runToSelection: selectionInterval inContext: aContext >>>>> "Attempt to step over instructions in >>>>> selectedContext until the >>>>> execution reaches the selected instruction. This >>>>> happens when the >>>>> program counter passes the begining of >>>>> selectionInterval. >>>>> >>>>> Â Â Â Â Â Â A not nill and valid interval is expected." >>>>> >>>>> Â Â Â Â Â Â (self pcRangeForContext: aContext) first >>>>> >= selectionInterval first >>>>> ifTrue: [ ^self ]. >>>>> Â Â Â Â Â Â self stepOver: aContext. >>>>> Â Â Â Â Â Â [ aContext == self interruptedContext and: >>>>> [ (self pcRangeForContext: aContext) first < >>>>> selectionInterval first ] ] >>>>> whileTrue: [ self stepOver: aContext ]` >>>>> >>>>> # Observations and thoughts >>>>> - Replacing the stepOver with a stepInto -> This >>>>> made the RunToHere stops when resolving the 'new' >>>>> message (because the context changes). >>>>> >>>>> >>>>> Thanks for looking into this Thomas. >>>>> What happens if you use stepThrough rather than stepInto? >>>>> >>>>> cheers -ben >>>> >>>> Using `stepThrough: aContext` instead of `stepInto: >>>> aContext`, the RunToHere in the block stops at the >>>> intended place: the 2+2. >>>> Printing the sequence of `self pcRangeForContext: >>>> aContext` yields the following. It doesn't show >>>> precisely the stop in the block, and instead shows an >>>> interval encompassing the whole block. That's what I >>>> was using to see where the execution was going during >>>> the RunToHere loop so I guess that's not a precise >>>> enough indicator for this situation... >>>> (21 to: 22)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60) >>>> >>>> I also tried the case where the block does not get >>>> evaluated (changing myEvalBlock so that it does >>>> nothing). In this situation, the RunToHere with a >>>> stepThrough ends up at the intended place, the 3+3. >>>> >>>> So... just use stepThrough for the RunToHere I guess? >>>> >>>> >>>> Seems like expected behaviour. >>>> Could you create an Issue/Pull Request to provide some >>>> concrete code to review? >>>> >>>> Now the trick will be if you can devise some tests to go >>>> with this. >>>> For examples perhaps look at senders of >>>> newDebugSessionNamed:startedAt: >>>> including SpecDebugger>>testBasic. >>>> >>>> cheers -ben >>>> >>> I opened an issue on FogBugz: >>> https://pharo.fogbugz.com/f/cases/20687/ >>> <https://pharo.fogbugz.com/f/cases/20687/> >>> >>> Attached are the file out of the test code (MyClass.st) and >>> the fixed runToSelection:inContext: >>> (DebugSession-runToSelectioninContext). >>> I'll make a pull request tomorrow. >>> >>> For the test, I'm thinking about something like the >>> following, that checks the source code position of the pc >>> after the runToSelection. (It's not working yet) >>> Now that I think of it, the source code position of the pc >>> will maybe be the whole block (as experienced earlier) so >>> this approach may end up not working. >>> I'll come back to that tomorrow. >>> >>> Draft for a test: >>> Â Â Â `testRunToSelectionInContext >>> Â Â Â |context_ process_ session_| >>> Â Â Â "The variable names have an underscore to distinguish >>> them from those declared in the setUp method of this >>> TestCase (DebuggerModelTest), which are not suited for this >>> test (because not making a debug session out of suitable code)" >>> Â Â Â context_ := [1+1. >>> Â Â Â Â Â Â self evalBlock:[2+2]. >>> Â Â Â Â Â Â 3+3. >>> Â Â Â ] asContext. >>> Â Â Â process_ := Process >>> Â Â Â Â Â Â forContext: context_ >>> Â Â Â Â Â Â priority: Processor userInterruptPriority. >>> >>> Â Â Â session_:= process_ newDebugSessionNamed: 'test session' >>> startedAt: context_. >>> Â Â Â session_ runToSelection: (Interval from: 28 to: 27) >>> inContext: context_. >>> Â Â Â self assert: ((session_ pcRangeForContext: context_) >>> first == 3)` >>> >>> cheers - Thomas >>> >>>> >>>> Thomas >>>> >>>> >>>>> >>>>> - Replacing the stepOver with stepInto and >>>>> removing the equal condition on contexts -> The >>>>> RunToHere goes to the 3+3. Looking at the source >>>>> code position of the program counter, it doesn't >>>>> enter the block and seems to resolve it in a >>>>> single step. I don't really get why that is, >>>>> considering using the stepInto button of the >>>>> debugger does enter the block. Here is the series >>>>> of source code positions of the program counter >>>>> during the RunToHere: (21 to: 22)(34 to: 36)(34 >>>>> to: 36)(49 to: 60)(38 to: 60)(38 to: 60)(65 to: 66). >>>>> However, removing the equal condition on contexts >>>>> means that if the method call returns before >>>>> reaching the cursor, it won't stop! >>>>> >>>>> - An idea could be to have the RunToHere place a >>>>> metalink on the selected node and let the >>>>> execution run until it hits the metalink, which >>>>> then updates the debugger. Potential problems are >>>>> that it implies installing a metalink on a method >>>>> that is already on the stack, which may not be >>>>> that easy to do properly (in particular, it >>>>> affects the program counter since it changes the >>>>> bytecode), and there is the potential case where >>>>> the metalink is never reached (for example imagine >>>>> the myEvalBlock: method of my example is just >>>>> storing the block and not evaluating it). >>>>> >>>>> >>>>> Cheers, >>>>> Thomas >>>>> >>>>> >>>>> >>>>> Le 09/11/2017 Ã 22:06, Stephane Ducasse a Ã©critÂ : >>>>> >>>>> Agreed. Thomas? It would be a good bone to ... >>>>> (Un bon os a ronger) . >>>>> >>>>> Stef >>>>> >>>>> On Thu, Nov 9, 2017 at 4:32 AM, Tudor Girba >>>>> <tudor(a)tudorgirba.com >>>>> <mailto:tudor@tudorgirba.com>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> The basic tools, such as debugger, are >>>>> expected to work. If something does not >>>>> work, itâs a bug. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On Nov 8, 2017, at 11:59 PM, Tim >>>>> Mackinnon <tim(a)testit.works> >>>>> <mailto:tim@testit.works> wrote: >>>>> >>>>> I think it's broken in Pharo 6 too, as >>>>> I often find it unreliable. >>>>> >>>>> It's hard to know what should work >>>>> anymore - we really need a >>>>> stabilisation release to let the dust >>>>> settle. >>>>> >>>>> I'm always a bit reticent to report >>>>> things as I'm not sure what you expect >>>>> to work. >>>>> >>>>> Tim >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 8 Nov 2017, at 20:40, Stephane >>>>> Ducasse <stepharo.self(a)gmail.com >>>>> <mailto:stepharo.self@gmail.com>> >>>>> wrote: >>>>> >>>>> Hi >>>>> >>>>> I have the following method and I >>>>> have my cursor -MY CURSOR HERE- >>>>> I select the menu run to here and >>>>> .... I exit the method. >>>>> :( >>>>> >>>>> Is run to here working in Pharo 70? >>>>> I start to get worry about the >>>>> number of bugs I get when using >>>>> Pharo70. >>>>> >>>>> Stef >>>>> >>>>> >>>>> fileOut >>>>> "File out the receiver, to a file >>>>> whose name is a function of the >>>>> change-set name and a unique >>>>> numeric tag." >>>>> >>>>> | nameToUse | >>>>> self halt. >>>>> self class >>>>> promptForDefaultChangeSetDirectoryIfNecessary. >>>>> nameToUse := (self >>>>> defaultChangeSetDirectory / self >>>>> name , 'cs') >>>>> nextVersion basename. >>>>> UIManager default >>>>> showWaitCursorWhile: >>>>> [ >>>>> | internalStream | >>>>> internalStream := (String new: >>>>> 10000) writeStream. >>>>> >>>>> -MY CURSOR HERE- >>>>> >>>>> internalStream >>>>> header; >>>>> timeStamp. >>>>> self fileOutPreambleOn: >>>>> internalStream. >>>>> self fileOutOn: internalStream. >>>>> self fileOutPostscriptOn: >>>>> internalStream. >>>>> CodeExporter >>>>> writeSourceCodeFrom: internalStream >>>>> baseName: (nameToUse copyFrom: 1 >>>>> to: nameToUse size - 3) >>>>> isSt: false ] >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com <http://www.tudorgirba.com> >>>>> www.feenk.com <http://www.feenk.com> >>>>> >>>>> "Value is always contextual." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > > > > > -- > > > > 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_ > > > *Web:* _http://guillep.github.io_ > > *Phone: *+33 06 52 70 66 13 >

Nov. 15, 2017

[Pharo 7.0-dev] Build #296: 20689-Make-Pharo-bootstrap-independent-on-source-repository

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

There is a new Pharo build available! The status of the build #296 was: SUCCESS. The Pull Request #479 was integrated: "20689-Make-Pharo-bootstrap-independent-on-source-repository" Pull request url: https://github.com/pharo-project/pharo/pull/479 Issue Url: https://pharo.fogbugz.com/f/cases/20689 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 15, 2017

[ANN] Lifeware upgraded to Platinum Membership

by Marcus Denker

The Pharo Consortium is very happy to announce that Lifeware has upgraded to Platinum Member status. About - Lifeware: http://www.lifeware.ch - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

Nov. 15, 2017

[Pharo 7.0-dev] Build #295: 20693-Incorrect-basename-of-empty-relative-path

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

There is a new Pharo build available! The status of the build #295 was: SUCCESS. The Pull Request #481 was integrated: "20693-Incorrect-basename-of-empty-relative-path" Pull request url: https://github.com/pharo-project/pharo/pull/481 Issue Url: https://pharo.fogbugz.com/f/cases/20693 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 15, 2017

[Pharo 7.0-dev] Build #294: 20678-selecting-of-a-method-version-causes-DNU

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

There is a new Pharo build available! The status of the build #294 was: SUCCESS. The Pull Request #482 was integrated: "20678-selecting-of-a-method-version-causes-DNU" Pull request url: https://github.com/pharo-project/pharo/pull/482 Issue Url: https://pharo.fogbugz.com/f/cases/20678 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 15, 2017