Hi Everyone, I've made a snap package for Pharo 6 which I think is far enough along for some wider testing. To get Pharo up and running on Ubuntu 16.04: # Install Pharo $ sudo snap install --edge pharo --classic # If your system isn't configured for threaded heartbeat: $ sudo pharo.config # Download the latest Pharo 6 image $ pharo.getimage # Go... $ pharo.ui Pharo.image # or: $ pharo Pharo.image eval 4+3 To get a list of available commands: $ snap info pharo If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see https://snapcraft.io/docs/core/install The VM is the threaded heartbeat, dated 201704101933. The installation flags are: --edge - The edge channel is for development versions. It progresses to beta, candidate and then stable. --classic - Snap packages are normally sandboxed for security reasons. Since Pharo is a development environment in which we want to be able to run any executable, or load any library, it is installed with access to the entire system (as the running user). Why use snap packages? - They include all dependencies. In particular, for the 32 bit versions, this means that it isn't necessary to install all the 32 bit architecture and associated dependencies. - Including dependencies means that there shouldn't be any problems with incompatible library versions when upgrading. Why not use snap packages? - It's a relatively new technology, with a number of rough edges. - There may still be issues with its sandboxing that I haven't discovered yet. - Please let me know of any others to be listed here. - Because the package uses classic confinement, it isn't cross-distribution in practice (unfortunately). If you don't trust me to configure your system correctly (which requires sudo): - All the scripts that make up the sub-commands are visible, e.g. pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG The packaging code is at: https://github.com/akgrant43/pharo-snap I'm interested to know if people would like to see this eventually become a supported package format. Cheers, Alistair
Thanks for this Alistair. Having more self contained package options, is good. I'm also interested in the upcoming Nix package initiative that has been announced in the list recently, which also deals with installing dependencies in a Linux distribution neutral fashion. Cheers, Offray On 12/04/17 09:03, Alistair Grant wrote:
Hi Everyone,
I've made a snap package for Pharo 6 which I think is far enough along for some wider testing.
To get Pharo up and running on Ubuntu 16.04:
# Install Pharo $ sudo snap install --edge pharo --classic # If your system isn't configured for threaded heartbeat: $ sudo pharo.config # Download the latest Pharo 6 image $ pharo.getimage # Go... $ pharo.ui Pharo.image # or: $ pharo Pharo.image eval 4+3
To get a list of available commands:
$ snap info pharo
If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see https://snapcraft.io/docs/core/install
The VM is the threaded heartbeat, dated 201704101933.
The installation flags are:
--edge - The edge channel is for development versions. It progresses to beta, candidate and then stable. --classic - Snap packages are normally sandboxed for security reasons. Since Pharo is a development environment in which we want to be able to run any executable, or load any library, it is installed with access to the entire system (as the running user).
Why use snap packages?
- They include all dependencies. In particular, for the 32 bit versions, this means that it isn't necessary to install all the 32 bit architecture and associated dependencies. - Including dependencies means that there shouldn't be any problems with incompatible library versions when upgrading.
Why not use snap packages?
- It's a relatively new technology, with a number of rough edges. - There may still be issues with its sandboxing that I haven't discovered yet. - Please let me know of any others to be listed here. - Because the package uses classic confinement, it isn't cross-distribution in practice (unfortunately).
If you don't trust me to configure your system correctly (which requires sudo):
- All the scripts that make up the sub-commands are visible, e.g. pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG
The packaging code is at: https://github.com/akgrant43/pharo-snap
I'm interested to know if people would like to see this eventually become a supported package format.
Cheers, Alistair
On 12 April 2017 at 16:43, Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:
I'm also interested in the upcoming Nix package initiative that has been announced in the list recently, which also deals with installing dependencies in a Linux distribution neutral fashion.
This can only happen if the Pharo community somehow products a new release of the VM that I can package. The suggestion from the list was that I pick a commit from the pharo-project/pharo-vm#master branch, but I have browsed the commit history and that is way too much of a moving target for me to ship onwards to Nix/NixOS users. Pharo community: Please - somehow - make a new source release of your bloomin' VM!
Hi luke We will do that. Now we are under stress for the release :) And PharoDays. Great conference! Stef On Wed, Apr 12, 2017 at 4:57 PM, Luke Gorrie <luke@snabb.co> wrote:
On 12 April 2017 at 16:43, Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:
I'm also interested in the upcoming Nix package initiative that has been announced in the list recently, which also deals with installing dependencies in a Linux distribution neutral fashion.
This can only happen if the Pharo community somehow products a new release of the VM that I can package.
The suggestion from the list was that I pick a commit from the pharo-project/pharo-vm#master branch, but I have browsed the commit history and that is way too much of a moving target for me to ship onwards to Nix/NixOS users.
Pharo community: Please - somehow - make a new source release of your bloomin' VM!
On 13 April 2017 at 12:20, Stephane Ducasse <stepharo.self@gmail.com> wrote:
We will do that.
Thank you! I will wait :). Now we are under stress for the release :)
And PharoDays. Great conference!
Thank you for explaining. I am new around here ("oh, are you working on a release now?") so it helps me to have this kind of hint about short-term issues (e.g. busy period) vs long term ones (e.g. no longer making source releases of the VM for some reason.)
We always try to have a major release around mid/end of april and this is in addition we have pharodays + several people moving to new houses :). And deadline for projects on top. On Thu, Apr 13, 2017 at 12:39 PM, Luke Gorrie <luke@snabb.co> wrote:
On 13 April 2017 at 12:20, Stephane Ducasse <stepharo.self@gmail.com> wrote:
We will do that.
Thank you! I will wait :).
Now we are under stress for the release :)
And PharoDays. Great conference!
Thank you for explaining. I am new around here ("oh, are you working on a release now?") so it helps me to have this kind of hint about short-term issues (e.g. busy period) vs long term ones (e.g. no longer making source releases of the VM for some reason.)
On 14 April 2017 at 08:53, Stephane Ducasse <stepharo.self@gmail.com> wrote:
We always try to have a major release around mid/end of april
Once the dust settles, I think it would be wonderful to have this invariant: - The latest Pharo VM source release is compatible with the latest Pharo image. This would make it easy for me to help nix users. My job will be to package the latest source release of the VM, period, and I will know that users can use this to run the latest image. I don't have much scope to screw things up and make people sad e.g. by shipping a bad commit from the master branch. (Of course it makes life harder for you upstream Pharo maintainers. Now updating the VM source release is a blocker for releasing a new image. Could be that this is too constraining in practice, I dunno. I'm just a guy who wants to setup a stable Pharo that I can use to build an application :-))
This is what we always have when we release and we freeze it. The vm 60 will be compatible with latest pharo 60 image. On Fri, Apr 14, 2017 at 12:09 PM, Luke Gorrie <luke@snabb.co> wrote:
On 14 April 2017 at 08:53, Stephane Ducasse <stepharo.self@gmail.com> wrote:
We always try to have a major release around mid/end of april
Once the dust settles, I think it would be wonderful to have this invariant:
- The latest Pharo VM source release is compatible with the latest Pharo image.
This would make it easy for me to help nix users. My job will be to package the latest source release of the VM, period, and I will know that users can use this to run the latest image. I don't have much scope to screw things up and make people sad e.g. by shipping a bad commit from the master branch.
(Of course it makes life harder for you upstream Pharo maintainers. Now updating the VM source release is a blocker for releasing a new image. Could be that this is too constraining in practice, I dunno. I'm just a guy who wants to setup a stable Pharo that I can use to build an application :-))
On 14 April 2017 at 22:20, Stephane Ducasse <stepharo.self@gmail.com> 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. Cheers! -Luke
On Sat, Apr 15, 2017 at 06:43:39AM +0200, Luke Gorrie wrote:
On 14 April 2017 at 22:20, Stephane Ducasse <stepharo.self@gmail.com> 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:
I think so...
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).
Is this from a VM you built yourself? What's the output of: $ pharo --version I just downloaded: $ curl http://get.pharo.org/50+vm | bash And it started without problem. The VM is dated Wed May 4 11:54:28 CEST 2016.
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.
Occasional bugs aside, my understanding is that V5.0 VMs will work with V5.0 images. They should at least start up OK. Cheers, Alistair
On 15 April 2017 at 09:12, Alistair Grant <akgrant0710@gmail.com> wrote:
On Sat, Apr 15, 2017 at 06:43:39AM +0200, Luke Gorrie wrote:
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).
Is this from a VM you built yourself?
This is a VM built from source during packaging for NixOS Linux. What's the output of:
$ pharo --version
Here it is: $ pharo-vm-nox --version 3.9-7 #1 Tue Mar 28 16:26:45 UTC 2017 gcc 5.4.0 [Production ITHB VM] NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 5 2016 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 5 2016 https://github.com/pharo-project/pharo-vm.git Commit: ba1aa855f546b084ec0ebdeb85a36f2352f97b49 Date: 2016-02-18 17:17:13 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #15040 Linux localhost 4.4.23 #1-NixOS SMP Fri Sep 30 08:20:43 UTC 2016 i686 GNU/Linux plugin path: /nix/store/5bm2pwrkd1083sb1f1rf0jz20cw87yya-pharo-vm-i386-2016.02.18/lib/pharo-vm-i386-2016.02.18/ [default: /nix/store/5bm2pwrkd1083sb1f1rf0jz20cw87yya-pharo-vm-i386-2016.02.18/lib/pharo-vm-i386-2016.02.18/] Note that the date 2016-02-18 corresponds with the latest non-spur source tarball release at http://files.pharo.org/vm/src/vm-unix-sources/ I just downloaded:
$ curl http://get.pharo.org/50+vm | bash
And it started without problem.
I *think* the difference is that you are downloading the VM as a binary and I am downloading it as source code, and we get different versions because pharo.org is regularly shipping updated binaries but not updating the source code releases at the same time. So the source releases lag behind over time and now it's at the point that they can't run the 5.0 image.
On Sat, Apr 15, 2017 at 09:50:29AM +0200, Luke Gorrie wrote:
On 15 April 2017 at 09:12, Alistair Grant <akgrant0710@gmail.com> wrote:
On Sat, Apr 15, 2017 at 06:43:39AM +0200, Luke Gorrie wrote: > 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).
Is this from a VM you built yourself?
This is a VM built from source during packaging for NixOS Linux.
What's the output of:
$ pharo --version
Here it is:
$ pharo-vm-nox --version 3.9-7 #1 Tue Mar 28 16:26:45 UTC 2017 gcc 5.4.0 [Production ITHB VM] NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 5 2016 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 5 2016 https://github.com/pharo-project/pharo-vm.git Commit: ba1aa855f546b084ec0ebdeb85a36f2352f97b49 Date: 2016-02-18 17:17:13 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #15040 Linux localhost 4.4.23 #1-NixOS SMP Fri Sep 30 08:20:43 UTC 2016 i686 GNU/ Linux plugin path: /nix/store/ 5bm2pwrkd1083sb1f1rf0jz20cw87yya-pharo-vm-i386-2016.02.18/lib/ pharo-vm-i386-2016.02.18/ [default: /nix/store/ 5bm2pwrkd1083sb1f1rf0jz20cw87yya-pharo-vm-i386-2016.02.18/lib/ pharo-vm-i386-2016.02.18/]
Note that the date 2016-02-18 corresponds with the latest non-spur source tarball release at http://files.pharo.org/vm/src/vm-unix-sources/
I just downloaded:
$ curl http://get.pharo.org/50+vm | bash
And it started without problem.
I *think* the difference is that you are downloading the VM as a binary and I am downloading it as source code, and we get different versions because pharo.org is regularly shipping updated binaries but not updating the source code releases at the same time. So the source releases lag behind over time and now it's at the point that they can't run the 5.0 image.
How about trying: $ git clone https://github.com/pharo-project/pharo-vm.git $ cd pharo-vm $ git checkout b8ec25a570d7539653e1d793e97609adb509aaed and build that? It should be the source code for the binary VM on get.pharo.org. Cheers, Alistair
On 15 April 2017 at 10:08, Alistair Grant <akgrant0710@gmail.com> wrote:
How about trying:
$ git clone https://github.com/pharo-project/pharo-vm.git $ cd pharo-vm $ git checkout b8ec25a570d7539653e1d793e97609adb509aaed
and build that? It should be the source code for the binary VM on get.pharo.org.
First, thanks for taking the time to play along with me here, it really helps to make sure I don't hold things up due to a misunderstanding. Grabbing the source directly from Git is attractive if (a) I know that I am choosing a good version and (b) I am able to build it in a good way. Seems like a workable solution to (a) is to periodically check for a new binary release, work out which commit it is based off, and build that. This seems fairly reasonable and is probably also possible to automate. (I suppose you got the commit-id from --version or from checking Jenkins.) I see (b) as problematic though. The source tarball releases have a simple build procedure ("make") while the Git checkouts require a more involved one (bootstrapping the VM from an existing Pharo image.) So I would need to revise the nix build scripts quite a bit if I want to build from Git instead of the tarballs. However, it seems that on the master branch last week the VM build procedure has been reworked so that it is _not_ necessary to run the bootstrapping procedure anymore, which sounds great to me, except that I understand this new build procedure to be quite bleeding edge and not yet documented or used for a binary release (it's not included in the commit that you cite above.) So what to make of all that? Just right now I see only bad alternatives: sticking with the source release means not supporting Pharo 5.0, updating the build scripts to do bootstrapping takes effort and is already obsoleted by changes on the VM master branch, and shipping the VM master branch means making a pseudo-release without any QA and potentially causing problems for people downstream (there are lots of commits landing on that branch and I have no idea which ones are important/stable.) So the most reasonable course of action from my point of view seems to be to sit and wait for a better solution to come along e.g. a new source release of the VM or a "blessed" Git commit ID that includes the updated build scripts. The downside is that meanwhile NixOS users can't run the 5.0 image. Could be that Pharo 6.0 will resolve this and that is fine for me -- but of course I'd take a solution sooner if there is a simple one.
Hi Luke, On Sat, Apr 15, 2017 at 10:34:31AM +0200, Luke Gorrie wrote:
On 15 April 2017 at 10:08, Alistair Grant <akgrant0710@gmail.com> wrote:
How about trying:
$ git clone https://github.com/pharo-project/pharo-vm.git $ cd pharo-vm $ git checkout b8ec25a570d7539653e1d793e97609adb509aaed
and build that? It should be the source code for the binary VM on get.pharo.org.
First, thanks for taking the time to play along with me here, it really helps to make sure I don't hold things up due to a misunderstanding.
No problem. My answers below relate to Pharo 6, I haven't tried building V5 (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 :-)).
Grabbing the source directly from Git is attractive if (a) I know that I am choosing a good version and
The Pharo50-stable tag points to this commit. Presumably it is kept at the latest build, but someone else would have to confirm. If the same isn't already done for V6, I'll certainly be pushing for it (either a moving tag, or release numbers).
(b) I am able to build it in a good way.
Seems like a workable solution to (a) is to periodically check for a new binary release, work out which commit it is based off, and build that. This seems fairly reasonable and is probably also possible to automate. (I suppose you got the commit-id from --version or from checking Jenkins.)
I see (b) as problematic though. The source tarball releases have a simple build procedure ("make") while the Git checkouts require a more involved one (bootstrapping the VM from an existing Pharo image.) So I would need to revise the nix build scripts quite a bit if I want to build from Git instead of the tarballs. However, it seems that on the master branch last week the VM build procedure has been reworked so that it is _not_ necessary to run the bootstrapping procedure anymore, which sounds great to me, except that I understand this new build procedure to be quite bleeding edge and not yet documented or used for a binary release (it's not included in the commit that you cite above.)
So what to make of all that? Just right now I see only bad alternatives: sticking with the source release means not supporting Pharo 5.0, updating the build scripts to do bootstrapping takes effort and is already obsoleted by changes on the VM master branch, and shipping the VM master branch means making a pseudo-release without any QA and potentially causing problems for people downstream (there are lots of commits landing on that branch and I have no idea which ones are important/stable.)
So the most reasonable course of action from my point of view seems to be to sit and wait for a better solution to come along e.g. a new source release of the VM or a "blessed" Git commit ID that includes the updated build scripts. The downside is that meanwhile NixOS users can't run the 5.0 image. Could be that Pharo 6.0 will resolve this and that is fine for me -- but of course I'd take a solution sooner if there is a simple one.
I agree that the build seems a bit messy at the moment. Given how busy everyone is with the release, I'm keeping quiet for now, but afterwards I'd like to get my snap package completely automated. Personally, I think getting the build working reliably from git is worth the trouble (can test any commit, test patches before submitting pull request, etc). 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? I'd prefer to get the build using the image working properly as that is where these scripts are generated (I think). If you just want to build a single V6 pharo executable (no scripts, linux 64 bit in the example below): -- #!/bin/bash set -e 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 Cheers, Alistair
On Sat, Apr 15, 2017 at 09:53:49AM +0000, Alistair Grant wrote:
If you just want to build a single V6 pharo executable (no scripts, linux 64 bit in the example below):
-- #!/bin/bash set -e
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 --
And remembered that this will produce dragons, hopefully this will work: -- #!/bin/bash set -e git clone https://github.com/pharo-project/pharo-vm.git git checkout <the stable code...> cd pharo-vm ../genVersion.sh cd opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build ./mvm -- where genVersion.sh is: -- #! /bin/bash echo "`cat opensmalltalk-vm/platforms/Cross/vm/sqSCCSVersion.h | opensmalltalk-vm/.git_filters/RevDateURL.smudge`" > opensmalltalk-vm/platforms/Cross/vm/sqSCCSVersion.h echo "`cat opensmalltalk-vm/platforms/Cross/plugins/sqPluginsSCCSVersion.h | opensmalltalk-vm/.git_filters/RevDateURL.smudge`" > opensmalltalk-vm/platforms/Cross/plugins/sqPluginsSCCSVersion.h -- In case the mailer does formatting: there are only two lines of code, each beginning with echo. Cheers, Alistair
On 15 April 2017 at 11:53, Alistair Grant <akgrant0710@gmail.com> 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 (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.) 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! I will take a look at the ./mvm script now.
On Sat, Apr 15, 2017 at 02:14:26PM +0200, Luke Gorrie wrote:
On 15 April 2017 at 11:53, Alistair Grant <akgrant0710@gmail.com> 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 Apr 2017, at 14:25, Alistair Grant <akgrant0710@gmail.com> wrote:
On Sat, Apr 15, 2017 at 02:14:26PM +0200, Luke Gorrie wrote:
On 15 April 2017 at 11:53, Alistair Grant <akgrant0710@gmail.com> 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 <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
On 15 April 2017 at 14:45, Esteban Lorenzano <estebanlm@gmail.com> 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.
On Sat, Apr 15, 2017 at 8:53 PM, Luke Gorrie <luke@snabb.co> wrote:
On 15 April 2017 at 14:45, Esteban Lorenzano <estebanlm@gmail.com> 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
On Sat, Apr 15, 2017 at 12:43 PM, Luke Gorrie <luke@snabb.co> wrote:
On 14 April 2017 at 22:20, Stephane Ducasse <stepharo.self@gmail.com> 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 <btc@openinworld.com> wrote:
On Sat, Apr 15, 2017 at 12:43 PM, Luke Gorrie <luke@snabb.co> wrote:
On 14 April 2017 at 22:20, Stephane Ducasse <stepharo.self@gmail.com> 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
On Friday 14 April 2017 03:39 PM, Luke Gorrie wrote:
- The latest Pharo VM source release is compatible with the latest Pharo image.
This is too strong a condition. For the OS, an image is just a filesystem within a file. It is sufficient if the VM does not use the same executable name if it cannot execute the same image. After all, the VM is a machine and is not likely evolve as rapidly as the image it runs. If it cannot handle an image format then it should not reuse that VM's name. Linux already supports binfmt_misc fs to handle such images. VMMaker can generate magic(5) file in addition to src/* files from which package post-installers can register multiple interpreters in /proc/sys/fs/binfmt_misc/. Python and Qemu use this to run different bytecode and instruction sets. BTW, I am attaching a magic pattern file generated automatically from ImageFormat class in VMMaker image to illustrate my point. Regards .. Subbu
On Wednesday 12 April 2017 07:33 PM, Alistair Grant wrote:
Hi Everyone,
I've made a snap package for Pharo 6 which I think is far enough along for some wider testing.
Just tried it now. worked like charm.
--classic - Snap packages are normally sandboxed for security reasons. Since Pharo is a development environment in which we want to be able to run any executable, or load any library, it is installed with access to the entire system (as the running user).
Is this really necessary even if we want to work only within an image? Regards .. Subbu
Hi Subbu, On Wed, Apr 12, 2017 at 08:22:27PM +0530, K K Subbu wrote:
On Wednesday 12 April 2017 07:33 PM, Alistair Grant wrote:
Hi Everyone,
I've made a snap package for Pharo 6 which I think is far enough along for some wider testing.
Just tried it now. worked like charm.
Thanks!
--classic - Snap packages are normally sandboxed for security reasons. Since Pharo is a development environment in which we want to be able to run any executable, or load any library, it is installed with access to the entire system (as the running user). Is this really necessary even if we want to work only within an image?
No, I've used it successfully with strict confinement, however I think most developers will quickly become frustrated with the restrictions. If someone has a Pharo based application that they'd like to distribute, I think strict confinement is a much more likely to be a realistic option. Cheers, Alistair
Thanks a lot for this effort!!!!! On Wed, Apr 12, 2017 at 4:03 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Everyone,
I've made a snap package for Pharo 6 which I think is far enough along for some wider testing.
To get Pharo up and running on Ubuntu 16.04:
# Install Pharo $ sudo snap install --edge pharo --classic # If your system isn't configured for threaded heartbeat: $ sudo pharo.config # Download the latest Pharo 6 image $ pharo.getimage # Go... $ pharo.ui Pharo.image # or: $ pharo Pharo.image eval 4+3
To get a list of available commands:
$ snap info pharo
If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see https://snapcraft.io/docs/core/install
The VM is the threaded heartbeat, dated 201704101933.
The installation flags are:
--edge - The edge channel is for development versions. It progresses to beta, candidate and then stable. --classic - Snap packages are normally sandboxed for security reasons. Since Pharo is a development environment in which we want to be able to run any executable, or load any library, it is installed with access to the entire system (as the running user).
Why use snap packages?
- They include all dependencies. In particular, for the 32 bit versions, this means that it isn't necessary to install all the 32 bit architecture and associated dependencies. - Including dependencies means that there shouldn't be any problems with incompatible library versions when upgrading.
Why not use snap packages?
- It's a relatively new technology, with a number of rough edges. - There may still be issues with its sandboxing that I haven't discovered yet. - Please let me know of any others to be listed here. - Because the package uses classic confinement, it isn't cross-distribution in practice (unfortunately).
If you don't trust me to configure your system correctly (which requires sudo):
- All the scripts that make up the sub-commands are visible, e.g. pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG
The packaging code is at: https://github.com/akgrant43/pharo-snap
I'm interested to know if people would like to see this eventually become a supported package format.
Cheers, Alistair
participants (7)
-
Alistair Grant -
Ben Coman -
Esteban Lorenzano -
K K Subbu -
Luke Gorrie -
Offray Vladimir Luna Cárdenas -
Stephane Ducasse