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

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Stephane Ducasse

Hi pavel Since I want to reuse my clone. I tried the following. But I have no idea about the name of my fork so I put the one of my fork = pharo and it seems that this is what should be done. Now when I execute this script I get 'You already have an Iceberg repository So hat should I do? Use already created clone ===================== repository := IceRepositoryCreator new location: ('pharo-core' asFileReference); subdirectory:'src'; createRepository. repository register. fork := repository remotes detect: [ :remote | remote remoteName = #pharo ]. repository pushRemote: fork. repository pullRemote: repository origin. repository checkoutBranch: 'development'. repository backend pullFrom: repository origin. repository push. repository checkoutBranch: (SystemVersion current commitHash). On Mon, Jun 26, 2017 at 1:14 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > this mail describes how to start to send pull requests to Pharo 7 Github > repository from Pharo 7. > > Preparations > ===================== > > - you need to have a Github account and set SSH keys. See > https://help.github.com/articles/connecting-to-github-with-ssh/ > - create own pharo-project/pharo repository fork. Go to > https://github.com/pharo-project/pharo, click on "Fork" button and follow > the instructions > > Get Pharo 7 image > ===================== > > The CI jobs for the Pharo 7 defelopment are currently not fully set and we > still do not publish Pharo 7 image to files.pharo.org so you cannot get it > using zero-conf scripts. But we have a provisional CI job that bootstraps > the Pharo 7 image. > > https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ > > There download a file named like Pharo7.0-32bit-hash.zip and decompress it. > Unlike Pharo 6 images, the archive contains three files. Image, changes and > sources. In Pharo 7 you have the sources file for every bootstrapped > version. It has a commit hash in the name and it cannot be shared between > different Pharo 7 imges, however it can be shared between images that were > created as snapshots with the same bootstrapped image as ancestor. > > Create local clone > ===================== > > You need a local clone of the Pharo repository. Because it contains a lot of > small files, it is not a good idea to have own clone for every image. You > can have only one and share them between images. But because of some current > Monticello constraints you need to have the clone placed in the image > directory in a folder with name 'pharo-core'. > > In this step we will clone the Pharo repository from pharo-project/pharo > Github repository and add your fork as default pull target. We will update > your fork repository to contain all latest commits from the Pharo repository > in the branch named 'development'. For latest stable version (Pharo 6) we > use the master branch. > In the end we will checkout the repository to a particular commit from which > the downloaded Pharo 7 image was bootstrapped. Imagine that you have a Pharo > 7 image that is several days old and the development branch has already some > commits that change code. If you would take this older image, checkout to > the development branch and then do your commit, your would revert all > changes done in not-loaded commits. The other option is to update your image > to correspond to the repository latest commit which requires packages > reloading. > If you checkout to a particular commit, you are in detached HEAD state. In > this state you cannot do commits directly. You need to firstly create new a > new branch which we will do anyway. > > Evaluate the following code. This functionality will be later direct part of > Iceberg UI. Do not forget to change the user name. > > username := 'YOUR-USER-NAME'. > repository := IceRepositoryCreator new > url: 'git@github.com:pharo-project/pharo.git'; > location: ('pharo-core' asFileReference ensureCreateDirectory); > subdirectory:'src'; > createRepository. > repository checkoutBranch: 'development'. > repository register. > > fork := (IceRemote name: 'myFork' url: ('git@github.com:{1}/pharo.git' > format: {username})). > repository addRemote: fork. > repository pushRemote: fork. > repository pullRemote: repository origin. > > "update fork" > repository backend pullFrom: repository origin. "use this low-level form to > prevent packages reloading" > repository push. > > "checkout to the commit from which the image was bootstrapped" > repository checkoutBranch: (SystemVersion current commitHash). > > Use already created clone > ===================== > > This is alternative to the previous step. Let's suppose that you already > have your local clone. You take some Pharo 7 image and you want to create > commits. Then you need to create a symlink or move/copy the repository into > your image directory. Remember, it must be named pharo-core (we do not use > the name 'pharo' to avoid collision with VM executable). > > In this step we will register an existing Pharo repository clone, set your > fork as the push target, update your fork and then switch to the particular > commit. > > repository := IceRepositoryCreator new > location: ('pharo-core' asFileReference); > subdirectory:'src'; > createRepository. > repository register. > > fork := repository remotes detect: [ :remote | remote remoteName = #myFork > ]. > repository pushRemote: fork. > repository pullRemote: repository origin. > > repository checkoutBranch: 'development'. > repository backend pullFrom: repository origin. > repository push. > > repository checkoutBranch: (SystemVersion current commitHash). > > Issue processing > ===================== > > - create new case on FogBugz to get the issue number > - open Iceberg and from the context menu on the 'pharo' repository do: Pharo > - Create new branch from FogBugz issue, enter the issue ID and it will fill > the full branch name for you > - create your changes (you can do it before the creation of the branch too) > - commit and push your changes in Iceberg, this way you will commit your > branch to your fork repository. Remember that the Iceberg commit window has > two buttons, one for local commit, the second for commit with immediate > push. They can be very long because they contain the full branch (issue) > name > - in Iceberg in the 'pharo' repository context menu do: Pharo - Create pull > request, fill your > - fill your Github credentials > - leave the PR title, comment is not required, check the pull request head > and base. The base MUST be pharo-project/pharo development. Create the pull > requests > - go to https://github.com/pharo-project/pharo/pulls, check your pull > requests and put URL of it into the issue record on FogBugz (as a comment). > Resolve the issue as Fix review needed > > Cheers, > -- Pavel >

June 30, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by tesonep＠gmail.com

It is an iceberg plugin. 100% Pharo Code, uses the github.com rest api. On 30 Jun 2017 09:25, "Stephane Ducasse" <stepharo.self(a)gmail.com> wrote: > What is the github plugin? an Iceberg Pharo code or a C plugin? > > On Wed, Jun 28, 2017 at 6:25 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > And if I only want to contribute by reviewing a fix. Do I have to go the > > git-path ? > > Or is there a way to just start up an image and load and review the > change? > > > > > > right now, you can review by going to github and seeing. > > I will add a âPR toolâ to view/load PRs into an image, but thatâs not > ready. > > If someone wants to take a hit on itâ¦ the idea is to extend the github > > plugin with it :) > > > > cheers! > > Esteban > > > > > > Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" > > <pavel.krivanek(a)gmail.com>: > > > > > > > > 2017-06-28 17:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> > >> Hi all, > >> > >> Just to be clear, in Pharo 7, if I want to get some code integrated: > >> - I *have to* use the pull request process described by Pavel > >> OR > >> - I *can* use the pull request process, but I can also use the old slice > >> monticello process > >> ? > >> > >> What is the answer to the first question now, and what will be the > answer > >> of this question in 6 months from now ? > > > > > > You should use the pull request process. > > > > It is possible to create a standard slice BUT it must be done from Pharo > 6 > > and then sent into Pharo60Inbox. And then you need to wait until somebody > > converts this slice to pull request. That means that it will be harder > and > > harder to contribute this way because the code-base is moving. > > > > No slice will be integrated into Pharo 7 with the old process directly. > > > > Cheers, > > -- Pavel > > > > > >> > >> > >> Thanks > >> > >> > >> On Wed, Jun 28, 2017 at 3:42 PM, Ben Coman <btc(a)openinworld.com> wrote: > >>> > >>> > >>> > >>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka < > juraj.kubelka(a)icloud.com> > >>> wrote: > >>>> > >>>> > >>>> El 28-06-2017, a las 02:57, Ben Coman <btc(a)openinworld.com> escribiÃ³: > >>>> > >>>> > >>>> > >>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek > >>>> <pavel.krivanek(a)gmail.com> wrote: > >>>>> > >>>>> > >>>>> > >>>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich > >>>>> <serge.stinckwich(a)gmail.com>: > >>>>>> > >>>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek > >>>>>> <pavel.krivanek(a)gmail.com> wrote: > >>>>>> > > >>>>>> > > >>>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich > >>>>>> > <serge.stinckwich(a)gmail.com>: > >>>>>> >> > >>>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek > >>>>>> >> <pavel.krivanek(a)gmail.com> wrote: > >>>>>> >> > Hi, > >>>>>> >> > > >>>>>> >> > this mail describes how to start to send pull requests to > Pharo 7 > >>>>>> >> > Github > >>>>>> >> > repository from Pharo 7. > >>>>>> >> > >>>>>> >> Thank you for the great explanation Pavel. > >>>>>> >> > >>>>>> >> > Preparations > >>>>>> >> > ===================== > >>>>>> >> > > >>>>>> >> > - you need to have a Github account and set SSH keys. See > >>>>>> >> > https://help.github.com/articles/connecting-to-github- > with-ssh/ > >>>>>> >> > - create own pharo-project/pharo repository fork. Go to > >>>>>> >> > https://github.com/pharo-project/pharo, click on "Fork" button > >>>>>> >> > and > >>>>>> >> > follow > >>>>>> >> > the instructions > >>>>>> >> > >>>>>> >> [ ... ] > >>>>>> >> > >>>>>> >> > Issue processing > >>>>>> >> > ===================== > >>>>>> >> > > >>>>>> >> > - create new case on FogBugz to get the issue number > >>>>>> >> > - open Iceberg and from the context menu on the 'pharo' > >>>>>> >> > repository do: > >>>>>> >> > Pharo > >>>>>> >> > - Create new branch from FogBugz issue, enter the issue ID and > it > >>>>>> >> > will > >>>>>> >> > fill > >>>>>> >> > the full branch name for you > >>>>>> >> > - create your changes (you can do it before the creation of the > >>>>>> >> > branch > >>>>>> >> > too) > >>>>>> >> > - commit and push your changes in Iceberg, this way you will > >>>>>> >> > commit your > >>>>>> >> > branch to your fork repository. Remember that the Iceberg > commit > >>>>>> >> > window > >>>>>> >> > has > >>>>>> >> > two buttons, one for local commit, the second for commit with > >>>>>> >> > immediate > >>>>>> >> > push. They can be very long because they contain the full > branch > >>>>>> >> > (issue) > >>>>>> >> > name > >>>>>> >> > - in Iceberg in the 'pharo' repository context menu do: Pharo - > >>>>>> >> > Create > >>>>>> >> > pull > >>>>>> >> > request, fill your > >>>>>> >> > - fill your Github credentials > >>>>>> >> > - leave the PR title, comment is not required, check the pull > >>>>>> >> > request > >>>>>> >> > head > >>>>>> >> > and base. The base MUST be pharo-project/pharo development. > >>>>>> >> > Create the > >>>>>> >> > pull > >>>>>> >> > requests > >>>>>> >> > - go to https://github.com/pharo-project/pharo/pulls, check > your > >>>>>> >> > pull > >>>>>> >> > requests and put URL of it into the issue record on FogBugz > (as a > >>>>>> >> > comment). > >>>>>> >> > Resolve the issue as Fix review needed > >>>>>> >> > >>>>>> >> It means, there is no PR without a corresponding FogBugz issue ? > >>>>>> > > >>>>>> > > >>>>>> > Yes, at least for code changes we would like to keep this > relation. > >>>>>> > If it is > >>>>>> > a really trivial change in readme or something like that, we can > >>>>>> > accept no > >>>>>> > related issue record. > >>>>>> > Please prefer to comment the issues instead of PRs directly to > have > >>>>>> > all > >>>>>> > information at one place. > >>>>>> > >>>>>> Thank you Pavel for the explanation. > >>>>>> > >>>>>> Maybe in the future, it will make sense to put everything in the PR > >>>>>> and use github issues. > >>>>>> You will use CI travis builds for all PR ? > >>>>> > >>>>> > >>>>> For now we will use FogBugz because it has a lot of nice features and > >>>>> good API. Maybe we will switch it in future but now we should not > change too > >>>>> many things at once :-) > >>>>> For several reasons we now prefer to use own infrastructure for > >>>>> checking of PRs (mainly because of MacOS issues on Travis). But > again, it > >>>>> can be changed in future. > >>>>> > >>>> > >>>> It would be interesting to see how this might fit in with our > >>>> workflow... > >>>> https://blog.fogcreek.com/fogbugz-github-integration/ > >>>> > >>>> > >>>> > >>>> What is the benefit of the integration? I do not understand it from > the > >>>> given link. > >>>> > >>> > >>> When you submit a PR on github, Fogbugz is automatically updated with a > >>> link to the PR. > >>> Presumably this makes it easier for people reviewing cases in Fogbugz > to > >>> identify the slice to test. > >>> This is a better link... > >>> > >>> https://blog.fogcreek.com/improved-github-integration- > automatically-create-bug-events-with-commits/ > >>> > >>> cheers -ben > >> > >> > > > > > > > >

June 30, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Stephane Ducasse

What is the github plugin? an Iceberg Pharo code or a C plugin? On Wed, Jun 28, 2017 at 6:25 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > And if I only want to contribute by reviewing a fix. Do I have to go the > git-path ? > Or is there a way to just start up an image and load and review the change? > > > right now, you can review by going to github and seeing. > I will add a âPR toolâ to view/load PRs into an image, but thatâs not ready. > If someone wants to take a hit on itâ¦ the idea is to extend the github > plugin with it :) > > cheers! > Esteban > > > Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" > <pavel.krivanek(a)gmail.com>: > > > > 2017-06-28 17:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >> Hi all, >> >> Just to be clear, in Pharo 7, if I want to get some code integrated: >> - I *have to* use the pull request process described by Pavel >> OR >> - I *can* use the pull request process, but I can also use the old slice >> monticello process >> ? >> >> What is the answer to the first question now, and what will be the answer >> of this question in 6 months from now ? > > > You should use the pull request process. > > It is possible to create a standard slice BUT it must be done from Pharo 6 > and then sent into Pharo60Inbox. And then you need to wait until somebody > converts this slice to pull request. That means that it will be harder and > harder to contribute this way because the code-base is moving. > > No slice will be integrated into Pharo 7 with the old process directly. > > Cheers, > -- Pavel > > >> >> >> Thanks >> >> >> On Wed, Jun 28, 2017 at 3:42 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> >>> >>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> >>> wrote: >>>> >>>> >>>> El 28-06-2017, a las 02:57, Ben Coman <btc(a)openinworld.com> escribiÃ³: >>>> >>>> >>>> >>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek >>>> <pavel.krivanek(a)gmail.com> wrote: >>>>> >>>>> >>>>> >>>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich >>>>> <serge.stinckwich(a)gmail.com>: >>>>>> >>>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>>>>> <pavel.krivanek(a)gmail.com> wrote: >>>>>> > >>>>>> > >>>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich >>>>>> > <serge.stinckwich(a)gmail.com>: >>>>>> >> >>>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>>>>> >> <pavel.krivanek(a)gmail.com> wrote: >>>>>> >> > Hi, >>>>>> >> > >>>>>> >> > this mail describes how to start to send pull requests to Pharo 7 >>>>>> >> > Github >>>>>> >> > repository from Pharo 7. >>>>>> >> >>>>>> >> Thank you for the great explanation Pavel. >>>>>> >> >>>>>> >> > Preparations >>>>>> >> > ===================== >>>>>> >> > >>>>>> >> > - you need to have a Github account and set SSH keys. See >>>>>> >> > https://help.github.com/articles/connecting-to-github-with-ssh/ >>>>>> >> > - create own pharo-project/pharo repository fork. Go to >>>>>> >> > https://github.com/pharo-project/pharo, click on "Fork" button >>>>>> >> > and >>>>>> >> > follow >>>>>> >> > the instructions >>>>>> >> >>>>>> >> [ ... ] >>>>>> >> >>>>>> >> > Issue processing >>>>>> >> > ===================== >>>>>> >> > >>>>>> >> > - create new case on FogBugz to get the issue number >>>>>> >> > - open Iceberg and from the context menu on the 'pharo' >>>>>> >> > repository do: >>>>>> >> > Pharo >>>>>> >> > - Create new branch from FogBugz issue, enter the issue ID and it >>>>>> >> > will >>>>>> >> > fill >>>>>> >> > the full branch name for you >>>>>> >> > - create your changes (you can do it before the creation of the >>>>>> >> > branch >>>>>> >> > too) >>>>>> >> > - commit and push your changes in Iceberg, this way you will >>>>>> >> > commit your >>>>>> >> > branch to your fork repository. Remember that the Iceberg commit >>>>>> >> > window >>>>>> >> > has >>>>>> >> > two buttons, one for local commit, the second for commit with >>>>>> >> > immediate >>>>>> >> > push. They can be very long because they contain the full branch >>>>>> >> > (issue) >>>>>> >> > name >>>>>> >> > - in Iceberg in the 'pharo' repository context menu do: Pharo - >>>>>> >> > Create >>>>>> >> > pull >>>>>> >> > request, fill your >>>>>> >> > - fill your Github credentials >>>>>> >> > - leave the PR title, comment is not required, check the pull >>>>>> >> > request >>>>>> >> > head >>>>>> >> > and base. The base MUST be pharo-project/pharo development. >>>>>> >> > Create the >>>>>> >> > pull >>>>>> >> > requests >>>>>> >> > - go to https://github.com/pharo-project/pharo/pulls, check your >>>>>> >> > pull >>>>>> >> > requests and put URL of it into the issue record on FogBugz (as a >>>>>> >> > comment). >>>>>> >> > Resolve the issue as Fix review needed >>>>>> >> >>>>>> >> It means, there is no PR without a corresponding FogBugz issue ? >>>>>> > >>>>>> > >>>>>> > Yes, at least for code changes we would like to keep this relation. >>>>>> > If it is >>>>>> > a really trivial change in readme or something like that, we can >>>>>> > accept no >>>>>> > related issue record. >>>>>> > Please prefer to comment the issues instead of PRs directly to have >>>>>> > all >>>>>> > information at one place. >>>>>> >>>>>> Thank you Pavel for the explanation. >>>>>> >>>>>> Maybe in the future, it will make sense to put everything in the PR >>>>>> and use github issues. >>>>>> You will use CI travis builds for all PR ? >>>>> >>>>> >>>>> For now we will use FogBugz because it has a lot of nice features and >>>>> good API. Maybe we will switch it in future but now we should not change too >>>>> many things at once :-) >>>>> For several reasons we now prefer to use own infrastructure for >>>>> checking of PRs (mainly because of MacOS issues on Travis). But again, it >>>>> can be changed in future. >>>>> >>>> >>>> It would be interesting to see how this might fit in with our >>>> workflow... >>>> https://blog.fogcreek.com/fogbugz-github-integration/ >>>> >>>> >>>> >>>> What is the benefit of the integration? I do not understand it from the >>>> given link. >>>> >>> >>> When you submit a PR on github, Fogbugz is automatically updated with a >>> link to the PR. >>> Presumably this makes it easier for people reviewing cases in Fogbugz to >>> identify the slice to test. >>> This is a better link... >>> >>> https://blog.fogcreek.com/improved-github-integration-automatically-create-… >>> >>> cheers -ben >> >> > > >

June 30, 2017

Re: [Pharo-dev] Stable Pharo VM for Linux?

by Eliot Miranda

Hi Alistair, > On Jun 29, 2017, at 1:23 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >> On Thu, Jun 29, 2017 at 07:50:11PM +0200, Luke Gorrie wrote: >> Thanks Alistair! >> >> How did you choose that specific commit? (How can I tell what is current next >> month, and the month after, etc?) > > I periodically download the current VM and check the version: > > > $ curl get.pharo.org | bash > $ ./pharo --version > 5.0-201705310241 Wed May 31 04:57:44 UTC 2017 gcc 4.6.3 [Production Spur ITHB VM] > CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2227 uuid: 7ea146b4-39ce-4de7-afa3-a76ed1d1da35 May 31 2017 > VM: 201705310241 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue May 30 19:41:27 2017 -0700 $ > Plugins: 201705310241 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Linux testing-gce-3510e247-0aff-4711-8b5e-035fd311d6b8 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 GNU/Linux > plugin path: /tmp/p6/pharo-vm/lib/pharo/5.0-201705310241 [default: /tmp/p6/pharo-vm/lib/pharo/5.0-201705310241/] > > > Looking through the text above you can see which repository was used for the build: > > VM: 201705310241 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > > and the timestamp from the commit: > > $ Date: Tue May 30 19:41:27 2017 -0700 $ > > > Clone the repository, check out the Cog branch, and search through the > log for the appropriate commit timestamp: > > commit 6a63f68a3dd4deb7c17dd2c7ac6e4dd4b0b6d937 > Author: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: Tue May 30 19:41:27 2017 -0700 Feel free to add a script to the scripts directory that automates this. e.g. scripts/checkoutVMbyDate ? > > > HTH, > Alistair > > > > >> On 29 June 2017 at 18:29, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Luke, >> >>> On 29 June 2017 at 18:23, Luke Gorrie <luke(a)snabb.co> wrote: >>> Howdy - >>> >>> Congratulations everybody on the Pharo 6.0 release! >>> >>> I want to package this up for NixOS Linux now. Can somebody please tell >> me >>> how to choose the right Git commit for the current stable Pharo 6.0 VM >> for >>> Linux? >>> >>> Currently I am using commit 1c38b03fb043a2962f30f080db5b1292b5b7badb but >> I >>> assume that a newer version is expected now & that more updates will >> follow >>> in the future. >> >> git clone https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> cd opensmalltalk-vm >> git checkout 6a63f68 >> >> Esteban has done some work on Iceberg and the 64 bit VM, so I'd expect >> a new one soon. >> >> Cheers, >> Alistair >

June 29, 2017

Re: [Pharo-dev] Stable Pharo VM for Linux?

by Alistair Grant

On Thu, Jun 29, 2017 at 07:50:11PM +0200, Luke Gorrie wrote: > Thanks Alistair! > > How did you choose that specific commit? (How can I tell what is current next > month, and the month after, etc?) I periodically download the current VM and check the version: $ curl get.pharo.org | bash $ ./pharo --version 5.0-201705310241 Wed May 31 04:57:44 UTC 2017 gcc 4.6.3 [Production Spur ITHB VM] CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2227 uuid: 7ea146b4-39ce-4de7-afa3-a76ed1d1da35 May 31 2017 VM: 201705310241 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue May 30 19:41:27 2017 -0700 $ Plugins: 201705310241 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Linux testing-gce-3510e247-0aff-4711-8b5e-035fd311d6b8 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 GNU/Linux plugin path: /tmp/p6/pharo-vm/lib/pharo/5.0-201705310241 [default: /tmp/p6/pharo-vm/lib/pharo/5.0-201705310241/] Looking through the text above you can see which repository was used for the build: VM: 201705310241 https://github.com/OpenSmalltalk/opensmalltalk-vm.git and the timestamp from the commit: $ Date: Tue May 30 19:41:27 2017 -0700 $ Clone the repository, check out the Cog branch, and search through the log for the appropriate commit timestamp: commit 6a63f68a3dd4deb7c17dd2c7ac6e4dd4b0b6d937 Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: Tue May 30 19:41:27 2017 -0700 HTH, Alistair > On 29 June 2017 at 18:29, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Luke, > > On 29 June 2017 at 18:23, Luke Gorrie <luke(a)snabb.co> wrote: > > Howdy - > > > > Congratulations everybody on the Pharo 6.0 release! > > > > I want to package this up for NixOS Linux now. Can somebody please tell > me > > how to choose the right Git commit for the current stable Pharo 6.0 VM > for > > Linux? > > > > Currently I am using commit 1c38b03fb043a2962f30f080db5b1292b5b7badb but > I > > assume that a newer version is expected now & that more updates will > follow > > in the future. > > git clone https://github.com/OpenSmalltalk/opensmalltalk-vm.git > cd opensmalltalk-vm > git checkout 6a63f68 > > Esteban has done some work on Iceberg and the 64 bit VM, so I'd expect > a new one soon. > > Cheers, > Alistair

June 29, 2017

Re: [Pharo-dev] Stable Pharo VM for Linux?

by Luke Gorrie

Thanks Alistair! How did you choose that specific commit? (How can I tell what is current next month, and the month after, etc?) On 29 June 2017 at 18:29, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Luke, > > On 29 June 2017 at 18:23, Luke Gorrie <luke(a)snabb.co> wrote: > > Howdy - > > > > Congratulations everybody on the Pharo 6.0 release! > > > > I want to package this up for NixOS Linux now. Can somebody please tell > me > > how to choose the right Git commit for the current stable Pharo 6.0 VM > for > > Linux? > > > > Currently I am using commit 1c38b03fb043a2962f30f080db5b1292b5b7badb > but I > > assume that a newer version is expected now & that more updates will > follow > > in the future. > > git clone https://github.com/OpenSmalltalk/opensmalltalk-vm.git > cd opensmalltalk-vm > git checkout 6a63f68 > > Esteban has done some work on Iceberg and the 64 bit VM, so I'd expect > a new one soon. > > Cheers, > Alistair > >

June 29, 2017

Re: [Pharo-dev] Stable Pharo VM for Linux?

by Alistair Grant

Hi Luke, On 29 June 2017 at 18:23, Luke Gorrie <luke(a)snabb.co> wrote: > Howdy - > > Congratulations everybody on the Pharo 6.0 release! > > I want to package this up for NixOS Linux now. Can somebody please tell me > how to choose the right Git commit for the current stable Pharo 6.0 VM for > Linux? > > Currently I am using commit 1c38b03fb043a2962f30f080db5b1292b5b7badb but I > assume that a newer version is expected now & that more updates will follow > in the future. git clone https://github.com/OpenSmalltalk/opensmalltalk-vm.git cd opensmalltalk-vm git checkout 6a63f68 Esteban has done some work on Iceberg and the 64 bit VM, so I'd expect a new one soon. Cheers, Alistair

June 29, 2017

Stable Pharo VM for Linux?

by Luke Gorrie

Howdy - Congratulations everybody on the Pharo 6.0 release! I want to package this up for NixOS Linux now. Can somebody please tell me how to choose the right Git commit for the current stable Pharo 6.0 VM for Linux? Currently I am using commit 1c38b03fb043a2962f30f080db5b1292b5b7badb but I assume that a newer version is expected now & that more updates will follow in the future. Cheers! -Luke

June 29, 2017

Re: [Pharo-dev] Pharo 7 - Method Version Browser does not include author name

by Juraj Kubelka

Thanks for the explanation. Juraj > El 29-06-2017, a las 14:22, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > > Yes, this is expected behavior. The metadata-less cypress format does not store method authors and timestamps and because we are bootstrapping from repository in this format, we do not have this information. > > I hope we will be able to get the method history later from Git. > > Cheers, > -- Pavel > > 2017-06-29 13:58 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>>: > Hi, > > I have just spotted that Pharo 7 does not include names in Method Version Browser. > > In Pharo 7: > > <Captura de pantalla 2017-06-29 a la(s) 13.54.31.png> > > In Pharo 6: > > <Captura de pantalla 2017-06-29 a la(s) 13.55.37.png> > > > Is it an expected behavior? I think it is good to know the developer name and also the time it was changed. > If there is any error, someone can check when it was changed and who is the author. > > What do you think? > Juraj > >

June 29, 2017

Re: [Pharo-dev] Early Pull Request Validation Process

by Stephane Ducasse

Tx guille for looking at this. On Thu, Jun 29, 2017 at 10:39 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hi all, > > As some/a lot of you have been asking how to contribute, I'm here to > answer some questions :). > > First of all, integrating fixes in Pharo has been "slowed down" because we > missed the Monkey for Pull Request (PR) integration. Some of you have seen > a travis job going around and checking. That was our initial solution, but > it has a main issue for us: it only works for unix because our build > process is long, uses lots of small files due to file tree and osx travis > support is REALLY SLOW with I/O access. This is why we chose to use good > old Jenkins. > > https://ci.inria.fr/pharo-ci-jenkins2/ > # Why it took so much time > > Just some explanation of why it took so much time (you can skip this if > you're not interested). > > I started working on integrating Jenkins with Pull Requests several weeks > ago (note that I'm part time on this, also working in other projects and > the deadlines of the past weeks like IWST were killing my time). We have > now a new and working Jenkins server for Pharo7. This jenkins server is > hosted in Inria, its url being > > - We chose to use Jenkins 2 because I managed to make the PR integration > plugin work only in Jenkins 2. > - This required the creation of a new jenkins server + slaves. The pharo > and pharo-contribution servers run with Jenkins 1.6 and I did not want to > migrate existing servers to not break existing jobs. > - At the same moment, the inria CI infrastructure was having some (lots?) > of hiccups because of storage limitations. I spent several weeks to create > the running slaves for each platform and connect jenkins to them because of > that. > - Finally, I spent some time to test the new Jenkins MultiJobs. These kind > of jobs allow to split a single job in sequential phases. And each phase > can have multiple jobs that run concurrently. This allows us to bootstrap > once (on unix) and test in all platforms. > > An example of the new multijob can be found here: > > https://ci.inria.fr/pharo-ci-jenkins2/job/Pharo-PullRequest-Pipeline/ > > # Current Design > > Right at this moment, we are validating PRs using Jenkins. The process is > as follows: > > 1) Github notifies about changes in PRs to Jenkins using webhooks. So far, > we have configured it to notify about PR changes (including comments) and > normal pushes (to capture merges into the #development branch). > > 2) Upon the reception of a GH notification, Jenkins will launch two > jobs/validations. The basic structure of both validations is the same so > far. Bootstrap once (unix) and test in many platforms. There are the > following two test configurations however. > > 2.1) Full Validation: tests 32 and 64 bits, for linux, osx and windows. > This configuration is not fully working right now because we found > a VM bug in 64 bits that prevents us from creating a full pharo image. > Bootstrap is Ok, but there is a segfault when loading a big Metacello > configuration. > > 2.2) Basic Validation: tests only 32 bits, for now in linux and osx (I'm > planning to do windows today). > This validation is to give us nevertheless a feedback of the build > even if the full is failing so far. > > 2.3) Others? We could easily add new validations to run some faster > tests i.e., just loading a patch on the previous image. > > 3) Jenkins takes control and notifies Github > > So far, Full validation is failing, and I plan to keep it running until it > gets green. I don't care if it's red right now, the idea is that we should > fix it, and we should remember it is broken :). > > On the other hand, the Basic Validation is working and running tests. Once > the tests runs are finished, Github PR state will be either a success (if > all tests went green) or a failure (if it failed or some tests failed). You > will see actually a message saying: > > Validation Failure. Please check test results. > 7782 tests run, 0 skipped, 6 failed. > > + a link to jenkins if you want to inspect results. > > You can see an example of it in action in here: > > https://github.com/pharo-project/pharo/pull/119 > > # Next points > > Right now we are missing: > - Fogbugz integration > - Publish new images in the file server when a push/merge happens in the > #development branch > (I should sit today with Esteban to do some ssh key configuration in a > server I have no access to) > - fixing the failing tests => TO HAVE A GREEN BUILD> :D > - Enhance tests? > > - your enhancement idea :) > > The current validation already gives us an idea of what works and what > does not work, what breaks the bootstrap, and if we have failing tests or > not. > > I'd like however that before integrating a fix, there is at least 2 people > that look at it and put a +1. Because Monkey validation and the ability to > merge does not mean much actually :). > > If you have some questions, enhancements, there is this thread, there is > the #bootstrap channel in discord also. > > Guille (in behalf of everybody that helped me with this) > > -- > > > > Guille Polito > > > Research Engineer > > 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> >

June 29, 2017