April 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 6 snap install

by K K Subbu

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

April 15, 2017

Re: [Pharo-users] Pharo 6 snap install

by Alistair Grant

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(a)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

April 15, 2017

Re: [Pharo-users] Pharo6 ombu-session files in pharo-local

by Cyril Ferlicot D.

Le 15/04/2017 Ã 10:24, Holger Freyther a Ã©crit : > Hi, > > as part of moving a test image from Pharo5 to Pharo6 I also noticed that on each start a new "ombu-session" folder will be created (and never cleaned up). For a server-side deployment this is quite unfortunate as I want/need to use a fixed amount of disk space. > > I think Norbert has similar concerns with this feature. We are using "image-launch" to run the image and then either systemd|monit|runit|kubernetes will execute (and re-execute) image-launch. So potentially many many folders are created and never used. > > On deployments with many images, it is rare to make online changes and even more rare to try to recover them. Would it be possible to create the underlying storage or disable it completely? > > > thank you > holger > Hi Holger, `ombu-session ` is the directory used by epicea to log all the changes of the application by session of coding. It will contains the same informations that the .changes file. It cannot be cleanup because we do not want to lose those logs since we might need them to recover lost changes. In deployment you can disable Epicea. `EpMonitor current disable` -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

April 15, 2017

Re: [Pharo-users] Traits score: Squeak: 1, Pharo5: 0

by Cyril Ferlicot D.

Le 15/04/2017 Ã 08:14, Nicolai Hess a Ã©crit : > How to reproduce: > > "Create a Trait" > Trait named:#TRoot > uses:{} package:'MyPackage'. > > "Add some methods" > (Smalltalk classOrTraitNamed:'TRoot') compile:'trootA'. > (Smalltalk classOrTraitNamed:'TRoot') compile:'trootB'. > (Smalltalk classOrTraitNamed:'TRoot') compile:'trootC'. > > "Create another Trait using this Trait" > Trait named:#TRootUser > uses:{(Smalltalk classOrTraitNamed:'TRoot')} package:'MyPackage'. > > "Add more methods. > Note, methods still added on TRoot" > (Smalltalk classOrTraitNamed:'TRoot') compile:'troot1'. > (Smalltalk classOrTraitNamed:'TRoot') compile:'troot2'. > (Smalltalk classOrTraitNamed:'TRoot') compile:'troot3'. > > "Trait TRootUser should not have any local methods" > (RPackageOrganizer default packageNamed:'MyPackage') methods inspect. > > > Exprected outcome: > All methods are only defined on Trait TRoot. > Actual outcome: > Methods from TRoot added before creating the Trait that uses TRoot, are > *added* to the using trait, but only in the RPackage, the trait, *using* > TRoot still *knows* that it does not hold any > local methods: > > TRootUser localMethods. > -> "#()" > TRoot localMethods > -> "{TRoot>>#troot1. TRoot>>#troot3. TRoot>>#trootC. TRoot>>#trootB. > TRoot>>#trootA. TRoot>>#troot2}" > > Now, if we store a snapshot of this package, the RGMethodDefinitions, > wrongly assigned to trait TRootUser, will be flattened into that trait. > > This is cool that it was found with a reproducible case. We got the same problem at Synectique. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

April 15, 2017

Re: [Pharo-users] Pharo 6 snap install

by Luke Gorrie

On 15 April 2017 at 10:08, Alistair Grant <akgrant0710(a)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.

April 15, 2017

Re: [Pharo-users] Traits score: Squeak: 1, Pharo5: 0

by Hilaire

Indeed that's it. Adding methods after the second traits was created shows up the bug. I open a ticket. https://pharo.fogbugz.com/f/cases/19938/Traits-methods-flattened Le 15/04/2017 Ã 08:14, Nicolai Hess a Ã©crit : > > How to reproduce: > -- Dr. Geo http://drgeo.eu

April 15, 2017

Pharo6 ombu-session files in pharo-local

by Holger Freyther

Hi, as part of moving a test image from Pharo5 to Pharo6 I also noticed that on each start a new "ombu-session" folder will be created (and never cleaned up). For a server-side deployment this is quite unfortunate as I want/need to use a fixed amount of disk space. I think Norbert has similar concerns with this feature. We are using "image-launch" to run the image and then either systemd|monit|runit|kubernetes will execute (and re-execute) image-launch. So potentially many many folders are created and never used. On deployments with many images, it is rare to make online changes and even more rare to try to recover them. Would it be possible to create the underlying storage or disable it completely? thank you holger

April 15, 2017

Re: [Pharo-users] Traits score: Squeak: 1, Pharo5: 0

by Hilaire

Great! It is nice you can reproduce it, because my attempt failed with the exemple package attached. Le 15/04/2017 Ã 08:14, Nicolai Hess a Ã©crit : > > Le 14/04/2017 Ã 15:24, Denis Kudriashov a Ã©crit : > > > > Could you create example set of packages to reproduce problem? (to be > > not dependant on your private code) > > > > > How to reproduce: > -- Dr. Geo http://drgeo.eu

April 15, 2017

Re: [Pharo-users] Pharo 6 snap install

by Alistair Grant

On Sat, Apr 15, 2017 at 09:50:29AM +0200, Luke Gorrie wrote: > On 15 April 2017 at 09:12, Alistair Grant <akgrant0710(a)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(a)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

April 15, 2017

Re: [Pharo-users] Pharo 6 snap install

by Luke Gorrie

On 15 April 2017 at 09:12, Alistair Grant <akgrant0710(a)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(a)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.

April 15, 2017