On Sat, Apr 15, 2017 at 02:14:26PM +0200, Luke Gorrie wrote:
> On 15 April 2017 at 11:53, Alistair Grant <[hidden email]> wrote: > > (actually, I'm not sure why you're bothering since 6 should > be out before the end of the month, but that's your choice :-)). > > > I just want something stable and reasonably modern for running existing > applications and building new ones. > > If that means waiting for Pharo 6.0 release then that is okay with me. > > > The (V6) linux install relies on a number of bash scripts to launch pharo > (bin/pharo, bin/pharo-ui and bin/pharo-vm/pharo). How are you producing > these, or are you doing something else? > > > Here is where those scripts are generated in the existing pharo-vm packaging: > https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/pharo/vm/ > build-vm.nix#L50-L70 Ahh, so Nix is doing its own thing, not using the ZeroConf scripts. > (I didn't write the nix packaging code but I have volunteered to maintain it so > if it's out of date then I should fix that.) It will be for V6. Esteban has changed the scripts to ensure that Pharo versions of libraries are loaded (from memory)(this is also partly why I would like to use the full build process). > git clone https://github.com/pharo-project/pharo-vm.git > git checkout <the stable code...> > cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build > ./mvm > -- > > BTW: HEAD is currently eaf13db484ac87720d8454e66b5ce92f51c01036, and my > experience is that it is significantly less stable than the latest > binary, which is from 1c38b03fb043a2962f30f080db5b1292b5b7badb > > > This is really the bleeding edge :-) both of those commits were pushed within > the past three days! Yep, V6 is still in testing. :-) Cheers, Alistair |
this belongs to pharo-dev, please continue there :)
|
On 15 April 2017 at 14:45, Esteban Lorenzano <[hidden email]> wrote:
Looks to me like I should make a small replacement for mvm that is for nix. Nix indeed does its own thing. The downside is that it's restricted: the build runs in a sandbox, can't touch the network, has to declare the sha256 of any dependencies that it needs. Nothing - not one byte - is allowed to change from one build to the next without being accounted for and that breaks the mvm script. On the plus side it will supply all of the dependencies, with exactly the expected version and exactly the expected build options, so that is less work for mvm to do i.e. the third-party stuff should be taken care of automatically. I'm taking a poke now. However, I must remind myself that this is a distraction, since I am trying to get a _stable_ VM for Pharo 5.0. Somehow I have been swept up in this enthusiasm for building the bleeding edge Pharo 6.0 VM that is not actually of any practical use to me :-) although it will be in the near future. |
In reply to this post by Luke Gorrie
On Sat, Apr 15, 2017 at 12:43 PM, Luke Gorrie <[hidden email]> wrote:
> > On 14 April 2017 at 22:20, Stephane Ducasse <[hidden email]> wrote: >> >> This is what we always have when we release and we freeze it. >> The vm 60 will be compatible with latest pharo 60 image. > > > It is possible that I have misunderstood the whole situation and there is no problem at all. That would be awesome. Let's check :-) here is my understanding of the state of the world right now: > > The latest stable image release is Pharo-50771.image. > The latest stable VM source release is pharo-vm-2016.02.18. > These two releases are not compatible: This interpreter (vers. 6505) cannot read image file (vers. 6521). > > So the problem is that if a distribution packages the latest VM source release then the users won't be able to run the Pharo 5 VM that they download from pharo.org or via the pharo-launcher image. > > Is that correct? If so that's fine and hopefully we can fix it for Pharo 6.0. But if I am misunderstanding and a fix is available today that would also be good to know. > > I am looking for the "latest VM source release" in http://files.pharo.org/vm/src/vm-unix-sources/ > and assuming that non-spur is the stable option for pre-6.0 images. That is not correct. Pharo 5 used a Spur-VM since build 50496 circa 2015-12-14. * http://files.pharo.org/image/50-preSpur/ * http://files.pharo.org/image/50/ cheers -ben |
Whoops, now copied to pharo-dev to continue discussion there.
On Sun, Apr 16, 2017 at 9:13 PM, Ben Coman <[hidden email]> wrote: > On Sat, Apr 15, 2017 at 12:43 PM, Luke Gorrie <[hidden email]> wrote: >> >> On 14 April 2017 at 22:20, Stephane Ducasse <[hidden email]> wrote: >>> >>> This is what we always have when we release and we freeze it. >>> The vm 60 will be compatible with latest pharo 60 image. >> >> >> It is possible that I have misunderstood the whole situation and there is no problem at all. That would be awesome. Let's check :-) here is my understanding of the state of the world right now: >> >> The latest stable image release is Pharo-50771.image. >> The latest stable VM source release is pharo-vm-2016.02.18. >> These two releases are not compatible: This interpreter (vers. 6505) cannot read image file (vers. 6521). >> >> So the problem is that if a distribution packages the latest VM source release then the users won't be able to run the Pharo 5 VM that they download from pharo.org or via the pharo-launcher image. >> >> Is that correct? If so that's fine and hopefully we can fix it for Pharo 6.0. But if I am misunderstanding and a fix is available today that would also be good to know. >> >> I am looking for the "latest VM source release" in http://files.pharo.org/vm/src/vm-unix-sources/ > >> and assuming that non-spur is the stable option for pre-6.0 images. > > That is not correct. Pharo 5 used a Spur-VM since build 50496 circa 2015-12-14. > * http://files.pharo.org/image/50-preSpur/ > * http://files.pharo.org/image/50/ > > cheers -ben |
In reply to this post by Luke Gorrie
On Sat, Apr 15, 2017 at 8:53 PM, Luke Gorrie <[hidden email]> wrote:
> On 15 April 2017 at 14:45, Esteban Lorenzano <[hidden email]> wrote: >> >> this belongs to pharo-dev, please continue there :) > > > Looks to me like I should make a small replacement for mvm that is for nix. > > Nix indeed does its own thing. > > The downside is that it's restricted: the build runs in a sandbox, can't > touch the network, has to declare the sha256 of any dependencies that it > needs. Nothing - not one byte - is allowed to change from one build to the > next without being accounted for and that breaks the mvm script. > > On the plus side it will supply all of the dependencies, with exactly the > expected version and exactly the expected build options, so that is less > work for mvm to do i.e. the third-party stuff should be taken care of > automatically. > > I'm taking a poke now. > > However, I must remind myself that this is a distraction, since I am trying > to get a _stable_ VM for Pharo 5.0. Somehow I have been swept up in this > enthusiasm for building the bleeding edge Pharo 6.0 VM that is not actually > of any practical use to me :-) although it will be in the near future. I'm not sure if this provides a stable option for VM for Pharo 5, but with latest Pharo 5 image, build 50771 (2017-04-02) and recent VM Unix built 201703031554 https://github.com/pharo-project/pharo-vm.git TestRunner reports... 13696 run, 13640 passes, 17 skipped, 52 expected failures, 4 failures, 0 errors, 0 unexpected passes Failures: ReleaseTest>>#testUnpackagedClasses ReleaseTest>>#testObsoleteClasses ReleaseTest>>#testMethodsWithUnboundGlobals FileHandleTest(FileSystemHandleTest)>>#testTruncate cheers -ben |
Free forum by Nabble | Edit this page |