- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Stephane Ducasse

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

June 30, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by tesonep＠gmail.com

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

June 30, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Stephane Ducasse

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

June 30, 2017

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

by Eliot Miranda

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

June 29, 2017

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

by Alistair Grant

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

June 29, 2017

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

by Luke Gorrie

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

June 29, 2017

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

by Alistair Grant

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

June 29, 2017