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

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

Re: [Pharo-dev] FileReference>>/ and path canonicalisation

by Stephane Ducasse

Hi alistair I'm not expert of file system. Now I like your idea to have explicit messages such as canonalize or expand. Stef On Tue, Jun 27, 2017 at 8:56 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Sven, > > On Tue, Jun 27, 2017 at 01:31:42PM +0200, Sven Van Caekenberghe wrote: >> Hi Alistair, >> >> I think it is great that you are working on FileSystem and are trying >> to contribute. I appreciate your effort to find consensus. > > :-) > > >> But, and please take this as positive criticism, I feel a bit uneasy >> when I read your reasoning, but maybe I am wrong. > > Thanks for taking the trouble to reply. Hopefully I can address some of > your unease below. > > >> You see, the way I understand FileSystem (what I think was the >> original design idea), it is a cross platform abstraction over >> concrete file systems and paths. > > It does appear to be the case that effort was put in to avoid specifying > a separator, but it makes an assumption that is incorrect. The class > comments of path state that the seperator can be part of a file name, > and this is incorrect for every disk file system Pharo supports (as far > as I know). > > > >> A FileReference holds a FileSystem and a Path. A Path is just a >> collection of elements that leads to a location, the leaf possibly >> being interpreted as a file with an extension (although that last >> point is just a convention). It seems great effort was put into >> avoiding the use of separators. > >> Pharo is an object oriented system with appropriate abstractions, >> FileSystem gives us one approach to this difficult problem. >> >> In your reasoning, your truth, your reference is always the Unix file >> system and the way paths are handled there. You expect a number of >> things based on that, but maybe that was/is not the design goal. > > I do have a bias towards the Unix filesystem, and you're correct that > all the examples I provided use the Unix file system, but I've tried to > make sure that the changes I've made apply equally to Windows file > systems (more below). > > >> I said this before, but I am not sure we should interpret the argument of #/. > > I'll come back to this later :-) > > >> I think that >> >> FileLocator root / 'foo' / 'bar' / 'readme.txt'. >> >> is more abstract (fitting to the original goal) then >> >> '/foo' asFileReference / 'bar/readme.txt'. >> >> because it totally avoids a reference to the platform dependent path separator. > > I wasn't trying to suggest that code would normally be written this way. > It is more likely that '/foo' asFileReference is created early in the > code, and much later an input is supplied which is 'bar/readme.txt'. At > that point, the natural thing to do is send #/ as above. > > The problem with only supporting the first case above is that it puts > the onus of parsing the string on the user. We could add a another > method that parses the supplied string, but that will just make the > interface more confusing, and we already have a steady stream of > messages to the list from people getting confused by this. > > >> The same goes for '..' as >> >> (FileLocator root / 'foo' / 'bar' / 'down') parent / 'readme.txt'. >> >> is a more object oriented way to write '/foo/bar/down/../readme.txt', IMO. > > Agreed, but as mentioned above, we also have to deal with input strings > from external sources. > > >> Windows is an important target for Pharo, they use $\ not $/. > > The patch handles that, so on windows I can do: > > ('C:\cygwin' asFileReference / 'usr\local\bin') parent " File @ C:\cygwin\usr\local" > > (just to be clear, this is an example of how the strings are handled, > I'm not expecting anyone to write code like the above). > > >> Do you see my point ? > > I think so, but... :-) > > >> BTW, I consider the fact that current, >> >> '/foo' asFileReference / 'bar/readme.txt' >> >> works with #exists even though 'bar/readme.txt' was not fully >> parsed/resolved a bug, or a happy coincidence at best. > > I agree that it is a happy coincedence, but it is also intuitive. > > >> Another point is the distinction between internal/external and/or >> concrete/abstract paths. Should something like '..' remain part of a >> path. Never, always, only when it can be resolved ? What about special >> characters ? > > I'm arguing that '..' should be left in the path unless explicitly told > to be removed, so that things like symbolic links are handled properly > (by the file system itself). (Thanks to Denis for reminding me about > this in an earlier email thread) > > While it's nice to be completely general, is there a supported file > system that doesn't interpret ".." as the parent directory? > > As an aside, another patch I'll be submitting fixes symbolic link > handling so we could conveivably write a #canonicalizeOnFileSystem that > would properly handle 'symboliclink/..', but it would be slow. > > >> Should we support ~ ? Sometimes I would like that too, but maybe >> >> FileLocator home >> >> is enough. > > As Subbu points out in a later message, things like '~' are handled by > the shell. We could consider adding something like #expand to handle > '~' and shell variables, e.g. $HOME, but I'd make that a separate patch. > > It would also need to be done carefully as $ and ~ are valid characters > within file names (only / and the null character are not allowed in > Posix file systems, Windows has more characters that are not allowed). > > > >> All this being said, I think FileSystem can and should be improved, >> but carefully. >> >> It would be good if more people joined this discussion. >> >> Sven > > I think I understand the original goals, and I don't disagree with them, > however: > > 1. they are based on an arguably incorrect assumption (the > separator character can be part of a file name), > > 2. they've caused quite a bit of confusion due to unexpected behaviour, > > 3. if support for a file system that allows the separator in file names > is ever added, we will still have to be able to parse a full path > correctly (which the current code wouldn't do) > > 4. I don't think these changes conflict with the original goals, all the > examples you provided above still function exactly the same. > > Does that help reduce your uneasiness? > > Thanks again, > Alistair > > > > >> > On 26 Jun 2017, at 10:12, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> > >> > Pharo's FileSystem behaviour is currently somewhat inconsistent in its >> > treatment of path strings. >> > >> > To be able to demonstrate the limitations and fixes, I'm assuming that >> > the following files and directories have been created (/dev/shm is a >> > memory based file system in Ubuntu): >> > >> > cd /dev/shm >> > mkdir -p d1/d2/d3/d4 >> > touch d1/t1.txt d1/d2/t2.txt d1/d2/d3/t3.txt d1/d2/d3/d4/t4.txt >> > pushd d1 && ln -s d2/d3 ./s3 && popd >> > >> > >> > >> > 1. Path's are canonicalised during initial creation, but are not when >> > extending the path, i.e. sending #/ >> > >> > E.g. >> > >> > '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/t1.txt" >> > >> > '/dev/shm/d1/' asFileReference / 'd2/../t1.txt' " File @ /dev/shm/d1/d2/../t1.txt" >> > >> > Automatic canonicalisation is problematic as the code doesn't handle >> > symbolic links in the path name: >> > >> > ('/dev/shm/d1/' asFileReference / 's3/../t2.txt') exists " true (correct answer)" >> > >> > '/dev/shm/d1/s3/../t2.txt' asFileReference exists " false (wrong answer)" >> > >> > >> > 2. In an attempt to be completely general, the argument to #/ is assumed >> > to be a single directory / file. This is incorrect as the path >> > delimiter is not allowed to be part of the file name. The result is >> > that path comparisons and operations such as #parent give unexpected >> > results. >> > >> > E.g. >> > >> > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') exists " true" >> > >> > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1" >> > >> > >> > My PR modified FileSystem so that: >> > >> > 1. Canonicalisation is separated out as an operation that has to be >> > manually requested: >> > >> > '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/d2/../t1.txt" >> > >> > '/dev/shm/d1/d2/../t1.txt' asFileReference canonicalize " File @ /dev/shm/d1/t1.txt" >> > >> > >> > 2. The argument to #/ can be either a single file / directory name or a >> > path. >> > >> > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1/d2/d3" >> > >> > >> > >> > 3. Adds unit tests to cover the changed behaviour. >> > >> > >> > While I believe that these changes improve Pharo overall, making it more >> > intuitive and consistent, modifying the path creation to remove >> > canonicalisation is not backward compatible and requires a change to >> > PathTest>>testRelativeFromStringNormalization and >> > PathTest>>testRelativeFromStringNormalizationParent to manually >> > canonicalise the paths. >> > >> > Before I submit the patch, does anyone have any strong objections to the >> > changes as described above? >> > >> > Thanks, >> > Alistair >

June 30, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Pavel Krivanek

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] FileReference>>/ and path canonicalisation

by Stephane Ducasse

Hi alistair I do not know if this is me that wrote a wrong path class comment. You should consider that theere were nearly no comment at all and I started to try to give more love to this great library. Stef On Tue, Jun 27, 2017 at 8:56 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Sven, > > On Tue, Jun 27, 2017 at 01:31:42PM +0200, Sven Van Caekenberghe wrote: >> Hi Alistair, >> >> I think it is great that you are working on FileSystem and are trying >> to contribute. I appreciate your effort to find consensus. > > :-) > > >> But, and please take this as positive criticism, I feel a bit uneasy >> when I read your reasoning, but maybe I am wrong. > > Thanks for taking the trouble to reply. Hopefully I can address some of > your unease below. > > >> You see, the way I understand FileSystem (what I think was the >> original design idea), it is a cross platform abstraction over >> concrete file systems and paths. > > It does appear to be the case that effort was put in to avoid specifying > a separator, but it makes an assumption that is incorrect. The class > comments of path state that the seperator can be part of a file name, > and this is incorrect for every disk file system Pharo supports (as far > as I know). > > > >> A FileReference holds a FileSystem and a Path. A Path is just a >> collection of elements that leads to a location, the leaf possibly >> being interpreted as a file with an extension (although that last >> point is just a convention). It seems great effort was put into >> avoiding the use of separators. > >> Pharo is an object oriented system with appropriate abstractions, >> FileSystem gives us one approach to this difficult problem. >> >> In your reasoning, your truth, your reference is always the Unix file >> system and the way paths are handled there. You expect a number of >> things based on that, but maybe that was/is not the design goal. > > I do have a bias towards the Unix filesystem, and you're correct that > all the examples I provided use the Unix file system, but I've tried to > make sure that the changes I've made apply equally to Windows file > systems (more below). > > >> I said this before, but I am not sure we should interpret the argument of #/. > > I'll come back to this later :-) > > >> I think that >> >> FileLocator root / 'foo' / 'bar' / 'readme.txt'. >> >> is more abstract (fitting to the original goal) then >> >> '/foo' asFileReference / 'bar/readme.txt'. >> >> because it totally avoids a reference to the platform dependent path separator. > > I wasn't trying to suggest that code would normally be written this way. > It is more likely that '/foo' asFileReference is created early in the > code, and much later an input is supplied which is 'bar/readme.txt'. At > that point, the natural thing to do is send #/ as above. > > The problem with only supporting the first case above is that it puts > the onus of parsing the string on the user. We could add a another > method that parses the supplied string, but that will just make the > interface more confusing, and we already have a steady stream of > messages to the list from people getting confused by this. > > >> The same goes for '..' as >> >> (FileLocator root / 'foo' / 'bar' / 'down') parent / 'readme.txt'. >> >> is a more object oriented way to write '/foo/bar/down/../readme.txt', IMO. > > Agreed, but as mentioned above, we also have to deal with input strings > from external sources. > > >> Windows is an important target for Pharo, they use $\ not $/. > > The patch handles that, so on windows I can do: > > ('C:\cygwin' asFileReference / 'usr\local\bin') parent " File @ C:\cygwin\usr\local" > > (just to be clear, this is an example of how the strings are handled, > I'm not expecting anyone to write code like the above). > > >> Do you see my point ? > > I think so, but... :-) > > >> BTW, I consider the fact that current, >> >> '/foo' asFileReference / 'bar/readme.txt' >> >> works with #exists even though 'bar/readme.txt' was not fully >> parsed/resolved a bug, or a happy coincidence at best. > > I agree that it is a happy coincedence, but it is also intuitive. > > >> Another point is the distinction between internal/external and/or >> concrete/abstract paths. Should something like '..' remain part of a >> path. Never, always, only when it can be resolved ? What about special >> characters ? > > I'm arguing that '..' should be left in the path unless explicitly told > to be removed, so that things like symbolic links are handled properly > (by the file system itself). (Thanks to Denis for reminding me about > this in an earlier email thread) > > While it's nice to be completely general, is there a supported file > system that doesn't interpret ".." as the parent directory? > > As an aside, another patch I'll be submitting fixes symbolic link > handling so we could conveivably write a #canonicalizeOnFileSystem that > would properly handle 'symboliclink/..', but it would be slow. > > >> Should we support ~ ? Sometimes I would like that too, but maybe >> >> FileLocator home >> >> is enough. > > As Subbu points out in a later message, things like '~' are handled by > the shell. We could consider adding something like #expand to handle > '~' and shell variables, e.g. $HOME, but I'd make that a separate patch. > > It would also need to be done carefully as $ and ~ are valid characters > within file names (only / and the null character are not allowed in > Posix file systems, Windows has more characters that are not allowed). > > > >> All this being said, I think FileSystem can and should be improved, >> but carefully. >> >> It would be good if more people joined this discussion. >> >> Sven > > I think I understand the original goals, and I don't disagree with them, > however: > > 1. they are based on an arguably incorrect assumption (the > separator character can be part of a file name), > > 2. they've caused quite a bit of confusion due to unexpected behaviour, > > 3. if support for a file system that allows the separator in file names > is ever added, we will still have to be able to parse a full path > correctly (which the current code wouldn't do) > > 4. I don't think these changes conflict with the original goals, all the > examples you provided above still function exactly the same. > > Does that help reduce your uneasiness? > > Thanks again, > Alistair > > > > >> > On 26 Jun 2017, at 10:12, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> > >> > Pharo's FileSystem behaviour is currently somewhat inconsistent in its >> > treatment of path strings. >> > >> > To be able to demonstrate the limitations and fixes, I'm assuming that >> > the following files and directories have been created (/dev/shm is a >> > memory based file system in Ubuntu): >> > >> > cd /dev/shm >> > mkdir -p d1/d2/d3/d4 >> > touch d1/t1.txt d1/d2/t2.txt d1/d2/d3/t3.txt d1/d2/d3/d4/t4.txt >> > pushd d1 && ln -s d2/d3 ./s3 && popd >> > >> > >> > >> > 1. Path's are canonicalised during initial creation, but are not when >> > extending the path, i.e. sending #/ >> > >> > E.g. >> > >> > '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/t1.txt" >> > >> > '/dev/shm/d1/' asFileReference / 'd2/../t1.txt' " File @ /dev/shm/d1/d2/../t1.txt" >> > >> > Automatic canonicalisation is problematic as the code doesn't handle >> > symbolic links in the path name: >> > >> > ('/dev/shm/d1/' asFileReference / 's3/../t2.txt') exists " true (correct answer)" >> > >> > '/dev/shm/d1/s3/../t2.txt' asFileReference exists " false (wrong answer)" >> > >> > >> > 2. In an attempt to be completely general, the argument to #/ is assumed >> > to be a single directory / file. This is incorrect as the path >> > delimiter is not allowed to be part of the file name. The result is >> > that path comparisons and operations such as #parent give unexpected >> > results. >> > >> > E.g. >> > >> > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') exists " true" >> > >> > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1" >> > >> > >> > My PR modified FileSystem so that: >> > >> > 1. Canonicalisation is separated out as an operation that has to be >> > manually requested: >> > >> > '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/d2/../t1.txt" >> > >> > '/dev/shm/d1/d2/../t1.txt' asFileReference canonicalize " File @ /dev/shm/d1/t1.txt" >> > >> > >> > 2. The argument to #/ can be either a single file / directory name or a >> > path. >> > >> > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1/d2/d3" >> > >> > >> > >> > 3. Adds unit tests to cover the changed behaviour. >> > >> > >> > While I believe that these changes improve Pharo overall, making it more >> > intuitive and consistent, modifying the path creation to remove >> > canonicalisation is not backward compatible and requires a change to >> > PathTest>>testRelativeFromStringNormalization and >> > PathTest>>testRelativeFromStringNormalizationParent to manually >> > canonicalise the paths. >> > >> > Before I submit the patch, does anyone have any strong objections to the >> > changes as described above? >> > >> > Thanks, >> > Alistair >

June 30, 2017