- Pharo-dev - lists.pharo.org

Reviewing of the pull requests

by Pavel Krivanek

Hi, the reviewing of the pull requests is currently not as easy as we would like to have. For simple changes it should be enough to go to the pull requests list (https://github.com/pharo-project/pharo/pulls) and review the changes from the GitHub web interface. In case that the PR passes tests and bootstrapping, it should be fine. However if you want to play with an image that contains the PR code, your options are more complicated. The basic and the most clean one is to bootstrap from the repository with the PR applied on it. But it takes A LOT of time (over 20 mins). You can use this script that you will run inside the clone. set -e export PR=122 export BRANCH=development export PHARO_VERSION=60 export BOOTSTRAP_ARCH=32 git fetch origin $BRANCH git fetch origin refs/pull/$PR/head git checkout -b pullrequest FETCH_HEAD git merge --no-edit origin/$BRANCH #git diff origin/$BRANCH..pullrequest > pullrequest.diff wget -O - get.pharo.org/${PHARO_VERSION}+vm | bash ./pharo Pharo.image --no-default-preferences ./bootstrap/scripts/ prepare_image.st --save --quit ./pharo Pharo.image --no-default-preferences ./bootstrap/scripts/ bootstrap.st --ARCH=${BOOTSTRAP_ARCH} --quit bash ./bootstrap/scripts/build.sh The other option is to take existing Pharo 7 image, have pharo-project/pharo clone next to it in a folder named 'pharo-core' and then create a new branch with the merged pull request. Currently it cannot be done from Iceberg directly so you need to use Git. You can use this script: set -e PR=119 COMMIT=2225314a7404c9e00fe71e70d41fc59d4ba78e2d cd pharo-core git fetch origin refs/pull/$PR/head git checkout -b pr$PR-local FETCH_HEAD git checkout $COMMIT git checkout -b pr$PR-merged git merge --no-edit pr$PR-local #git diff $COMMIT...pr$PR-merged > pr$PR.diff Set the pull request name to the variable PR and the image commmit hash to the variable named COMMIT. It can be obtained by "SystemVersion current commitHash". As the result you are in a merged branch created for this pull requests (e.g. pr122-merged) and you need to reload all packages. It can be done from Iceberg where you will need to confirm several dialogs, or by this script: repo := MCFileTreeRepository new directory: './pharo-core/src' asFileReference; yourself. versions := OrderedCollection new. repo allFileNames do: [ :packageName | | wc | wc := MCWorkingCopy allManagers detect: [ :each | each packageName = (packageName withoutSuffix: '.package') ] ifNone: [nil]. wc ifNotNil: [ [(repo loadVersionFromFileNamed: packageName) load] on: MCMergeOrLoadWarning do: [:w | w resume ] ]] displayingProgress: [:e | e ]. The other option is to let display the classical Monticello merging window. For that you can use this script: repo := MCFileTreeRepository new directory: './pharo-core/src' asFileReference; yourself. versions := OrderedCollection new. repo allFileNames do: [ :packageName | | wc | wc := MCWorkingCopy allManagers detect: [ :each | each packageName = (packageName withoutSuffix: '.package') ] ifNone: [nil]. wc ifNotNil: [ versions add: (repo loadVersionFromFileNamed: packageName) ]] displayingProgress: [:e | e ]. merger := MCVersionMerger new. versions do: [:each | merger addVersion: each ]. merger mergeWithNameLike: 'merged'. merger gatherChanges. (merger instVarNamed: #records) do: [ :each | each mergePatch operations do: [:operation | operation chooseRemote.]]. (merger instVarNamed: #merger) operations do: #chooseRemote. merger resolveConflicts. However I have seen cases where for example the PR deleted some class and the MC merging tool was not able to see this change. So be careful with this approach. We need to look at that. Do not look on this mail as something final. It's only a hint for brave sprinters. To find a good workflow how properly review our PR should be one of our priorities. Cheers, -- Pavel

June 30, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Pavel Krivanek

Unfortunately you cannot share the repository the way you try because it always needs to be in the image working directory in a folder named 'pharo-core'. Without it the Monticello will not be able to see changes int the packages. On one location place Pharo 7 image and execute the first script that clones the repository and sets the remote fork. Then into some other repository take a fresh Pharo 7 image, create symlink to the 'pharo-core' folder in the original directory and then execute the second script that only registers this repository into Iceberg and sets proper pull and push targets on it. Cheers, -- Pavel 2017-06-30 10:04 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > So I do not understand > > Now if I do > > repository := IceRepositoryCreator new > location: ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/ > Pharo/PharoCodeBase/pharo-core' > asFileReference); > subdirectory:'src'; > createRepository. > repository register. > > > it works but doing it twice breaks. How can I get access to the repo? > Because > fork := repository remotes detect: [ :remote | remote remoteName = #pharo > ]. > > Does not work :( > And my github fork is name pharo I tried with 'pharo' but it failed too. > > > "origin (git@github.com:Ducasse/pharo.git)" > > > "upstream (git@github.com:pharo-project/pharo.git)" > > ;( > > > > > On Fri, Jun 30, 2017 at 9:56 AM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > No I did it from a freshly donwloaded image. Pharo7.0-32bit-70f3b57.zip > > > > On Fri, Jun 30, 2017 at 9:47 AM, Pavel Krivanek > > <pavel.krivanek(a)gmail.com> wrote: > >> The script in section "Use already created clone" is supposed to be > used by > >> a fresh Pharo 7 image. Maybe you are trying it on an image that already > has > >> the repository set? Even if I tried to use the name 'pharo' instead of > >> 'myFork', the scripts work. > >> > >> Cheers, > >> -- Pavel > >> > >> > >> 2017-06-30 9:34 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >>> > >>> 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] The new implementation of current working directory

by Guillermo Polito

On Fri, Jun 30, 2017 at 9:56 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Rajula, thanks for your write-up. > > As the person who pushed Rajula to send his email I feel I should > respond. > > While I'm in favour of Rajula's proposed changes, scripting in > particular will be much easier, I think we need to make the change > generally known as it will not always be obvious, e.g. at the moment I > can rely on: > > '../init/mystartup.st' asFileReference fileIn > > to always work with the current definition since my init directory is > always next to the image directory. After Rajula's changes I > will need to do something like: > > (FileLocator imageDirectory resolve: '../init/mystartup.st') fileIn > That's not true. It depends from where the image is launched. If you're running from the command line, $ pharo Pharo.image eval " 'someFile' asFileReference fullName " will be a file relative to the path of the image, if you open the image from where it is located (ie, working directory = image directory). This is yes different when you're 1) deploying the image in one directory, but you're using it from another one $ someDir/pharo someOtherDir/Pharo.image eval " 'someFile' asFileReference fullName " But then, why working directory should be image directory and not VM directory? Just historical reasons? That's a buggy convention. And people who know what a working directory is will perceive it as even buggier. 2) starting the process from a graphical environment (ie, double click in an executable app) In that case, the OS usually sets as working directory the current user home directory, or the user "desktop" directory. In any case, - we should have a good default, I think that following the principle of least surprise we should use as working directory what the OS means by working directory. - Applications in general should be explicit with their file management. Each OS has different locations to store different things (data, settings, libraries, executables)... FileLocator helps by reducing the noise between different OSs, but we should use it! > Cheers, > Alistair > > -- 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

June 30, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Stephane Ducasse

DoIt ^ repository remotes detect: [ :remote | self halt. remote remoteName = 'pharo' ] remote remoteName returns 'origin' and not the name of the fork so what is upstream? Pharo on github origin? the one local? Stef On Fri, Jun 30, 2017 at 10:04 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > So I do not understand > > Now if I do > > repository := IceRepositoryCreator new > location: ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core' > asFileReference); > subdirectory:'src'; > createRepository. > repository register. > > > it works but doing it twice breaks. How can I get access to the repo? > Because > fork := repository remotes detect: [ :remote | remote remoteName = #pharo ]. > > Does not work :( > And my github fork is name pharo I tried with 'pharo' but it failed too. > > > "origin (git@github.com:Ducasse/pharo.git)" > > > "upstream (git@github.com:pharo-project/pharo.git)" > > ;( > > > > > On Fri, Jun 30, 2017 at 9:56 AM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> No I did it from a freshly donwloaded image. Pharo7.0-32bit-70f3b57.zip >> >> On Fri, Jun 30, 2017 at 9:47 AM, Pavel Krivanek >> <pavel.krivanek(a)gmail.com> wrote: >>> The script in section "Use already created clone" is supposed to be used by >>> a fresh Pharo 7 image. Maybe you are trying it on an image that already has >>> the repository set? Even if I tried to use the name 'pharo' instead of >>> 'myFork', the scripts work. >>> >>> Cheers, >>> -- Pavel >>> >>> >>> 2017-06-30 9:34 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>> >>>> 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] Stable Pharo VM for Linux?

by Luke Gorrie

On 29 June 2017 at 18:29, Alistair Grant <akgrant0710(a)gmail.com> wrote: > git clone https://github.com/OpenSmalltalk/opensmalltalk-vm.git > cd opensmalltalk-vm > git checkout 6a63f68 > Just in quick happy testing... The 32-bit VM seems to be fine the 64-bit VM is not working properly since I updated to this commit. I open Pharo64-60465.image and initially it looks okay - Pharo logo and dark theme - but when I try to open windows - world menu, playground, spotter - the graphics are garbled for the screen areas that should be updated. I am tempted to ignore this problem for now because I don't know how stable the 64-bit VM is supposed to be, how backwards compatible it is supposed to be with slightly older images, what test suite I should run to check its basic functions, etc. Tips welcome! I will gladly improve this in the future. Cheers, -Luke

June 30, 2017

Re: [Pharo-dev] The new implementation of current working directory

by Max Leske

Thanks for the detailed explanation Rajula. I think it makes perfect sense to separate working and image directories from each other. What you didn't mention is how the current working directory is resolved when an image is not started from the command line but by using the operating systems file browser (e.g. double clicking). There's also the special case of the one-click image: should the working directory be the image directory (which on OS X would be inside of the application bundle (which sucks))? Could you elaborate on that? Cheers, Max > On 29 Jun 2017, at 14:42, Rajula Vineet <Vineet.Reddy(a)iiitb.org> wrote: > > Hi all, > > As I have already been posting about my GSoC work and updates on my blog > <https://vineetreddy.wordpress.com> and on the mailing list > <http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=12947…> > . In this post, I would like to go in depth of my work on 'the working > directory' so that I can get valuable feedback and suggestions from > everyone. This discussion was started on an github PR > <https://github.com/pharo-project/pharo/pull/96> which was conflicting my > PR. > > Firstly, I would like to go through the current implementation of the > working directory. With this implementation, when you use the > defaultWorkingDirectory method, the directory in which the running image is > present in, is returned. This is not a completely good working because when > you run the image from a different directory like './pharo ../Pharo.image' > the working directory is the one in which your image resides. But that isn`t > your actual working directory. Due to this, > > 1. Pharo cannot be installed as a normal application in a read-only > environment. > 2. Pharo wrongly reads and writes files relative to the 'working directory'. > 3. It also makes scripting difficult. > > In the FogBugz issue here > <https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory> , there > is an example which explains the problem. > > Let say the Pharo VM and Image are in the directory "~/Pharo", > and I wrote a script in "~/Documents/Pharo-scripts" called > "perfect-numbers.st" > > I have 2 possibilities: > > cd ~/Pharo && pharo Pharo.image st > ~/Documents/Pharo-scripts/perfect-numbers.st // works > > or > > cd ~/Documents/Pharo-scripts && pharo ~/Pharo/Pharo.image st > perfect-numbers.st // doesn't work... > > It doesn't work because when pharo wants to load the file, > it tries to locate it with: FileSystem disk workingDirectory !!! > which is NOT the current working directory." > > I hope you get the problem. > > So for the new implementation <https://github.com/rajula96reddy/pharo-cli> > with the help of Guille I researched about $PWD and getcwd() for a while and > wrote a new implementation. This is how it goes > 1. I have written new methods in OSPlatorm 'getPwdFromFFI' and > 'getPwdFromFFIwithsize:'. These call the getcwd() function using the UFFI > 2. And a new method currentWorkingDirectoryPath and > currentWorkingDirectoryPathWithBufferSize: in OSPlatform which uses the > above method and gets the working directory. > 3. To integrate this, I have patched the DiskStore method > 'defaultWorkingDirectory' to use the new methods in OSPlatform. > > I have checked all the sendors of the 'defaultWorkingDirectory' for any > issue. And I also wrote some unit tests. So, the new implementation is > working fine. With this, now I am able to get the right working directory. > The example mentioned above works perfectly. > > But, there may be a few cases where it can break interoperability between > Pharo and other Smalltalk dialects like squeak etc. And the 'pharo-local' > directory and its methods should also be patched subsequently. In fact, > these problems can be tackled by running image from its own directory itself > (which is obvious ;) ) or by using the method imageDirectory in FileLocator > class explicitly when necessary. But overall a good thing is this is will > ensure the system will behave as in other languages. > > I have completed this implementation and submitted a PR > <https://github.com/pharo-project/pharo/pull/92> to github. But because of > some dependency issue, it has not yet been merged. With the help of my > mentor, I am working on the problem. > > Thanks for reading all this. Please give your feedback and comments on this > new implementation. Your suggestions help me in learning more about the > project and also about the organization. > > Thanks, > Rajula > > > > -- > View this message in context: http://forum.world.st/The-new-implementation-of-current-working-directory-t… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 30, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Stephane Ducasse

So I do not understand Now if I do repository := IceRepositoryCreator new location: ('/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/pharo-core' asFileReference); subdirectory:'src'; createRepository. repository register. it works but doing it twice breaks. How can I get access to the repo? Because fork := repository remotes detect: [ :remote | remote remoteName = #pharo ]. Does not work :( And my github fork is name pharo I tried with 'pharo' but it failed too. "origin (git@github.com:Ducasse/pharo.git)" "upstream (git@github.com:pharo-project/pharo.git)" ;( On Fri, Jun 30, 2017 at 9:56 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > No I did it from a freshly donwloaded image. Pharo7.0-32bit-70f3b57.zip > > On Fri, Jun 30, 2017 at 9:47 AM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> The script in section "Use already created clone" is supposed to be used by >> a fresh Pharo 7 image. Maybe you are trying it on an image that already has >> the repository set? Even if I tried to use the name 'pharo' instead of >> 'myFork', the scripts work. >> >> Cheers, >> -- Pavel >> >> >> 2017-06-30 9:34 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>> 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] The new implementation of current working directory

by Sven Van Caekenberghe

> On 30 Jun 2017, at 09:56, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Rajula, thanks for your write-up. > > As the person who pushed Rajula to send his email I feel I should > respond. > > While I'm in favour of Rajula's proposed changes, scripting in > particular will be much easier, I think we need to make the change > generally known as it will not always be obvious, e.g. at the moment I > can rely on: > > '../init/mystartup.st' asFileReference fileIn > > to always work with the current definition since my init directory is > always next to the image directory. After Rajula's changes I > will need to do something like: > > (FileLocator imageDirectory resolve: '../init/mystartup.st') fileIn I haven't read everything (sorry), but we do have FileLocator workingDirectory So the question is, what should be the default when no known location is used ? Also, it feels to me as if, when file paths are passed via command line, it would make sense to use the workingDirectory as default. > Cheers, > Alistair >

June 30, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Stephane Ducasse

No I did it from a freshly donwloaded image. Pharo7.0-32bit-70f3b57.zip On Fri, Jun 30, 2017 at 9:47 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > The script in section "Use already created clone" is supposed to be used by > a fresh Pharo 7 image. Maybe you are trying it on an image that already has > the repository set? Even if I tried to use the name 'pharo' instead of > 'myFork', the scripts work. > > Cheers, > -- Pavel > > > 2017-06-30 9:34 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> 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] The new implementation of current working directory

by Alistair Grant

Rajula, thanks for your write-up. As the person who pushed Rajula to send his email I feel I should respond. While I'm in favour of Rajula's proposed changes, scripting in particular will be much easier, I think we need to make the change generally known as it will not always be obvious, e.g. at the moment I can rely on: '../init/mystartup.st' asFileReference fileIn to always work with the current definition since my init directory is always next to the image directory. After Rajula's changes I will need to do something like: (FileLocator imageDirectory resolve: '../init/mystartup.st') fileIn Cheers, Alistair

June 30, 2017