Re: [Pharo-users] Pharo 6 snap install
Locked
12
12
 
|
this belongs to pharo-dev, please continue there :)
|
Pharo VM build for nix, was: Re: [Pharo-users] Pharo 6 snap install
|
|
I made a pull request from the work-in-progress branch where I am tweaking things to build the latest VM under nix: The tricky bit that I haven't confronted properly yet is the overlap between nix and mvm/zeroconf i.e. each one wants to be in charge of managing the shared library dependencies. I'd ideally like to handle the dependencies on the nix side and have a sufficient test suite to check that the VM+libs that I provide works with the popular images too. Is such a test suite available perhaps? But maybe I will need to build the exact same libraries as mvm does or even fall back to packaging binary releases of the VM instead of building them myself. (mvm script is not directly usable for reasons sketched in the PR.) On Sat, 15 Apr 2017 at 14:46, Esteban Lorenzano <[hidden email]> wrote:
|
|
|
In reply to this post by EstebanLM
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 EstebanLM
On Sat, Apr 15, 2017 at 4:34 PM, Luke Gorrie <[hidden email]> wrote:
> On 15 April 2017 at 10:08, Alistair Grant <[hidden email]> wrote: > > 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.) A historical perspective... Prior to this coming Release 6, Pharo had diverged from the parent build system used by OpenSmalltalk (nee Squeak-VM) such that (IIUC) it was driven from the Image generating the generated-C-sources plus the Cmake configuration. I guess this is what you describe as "bootstrap". However for Release 6 onwards, Pharo has returned to the fold and is directly using the OpenSmalltalk build system. The OpenSmalltalk build system does not require a build to invoke a Smalltalk image, and I notice elsewhere you've seen the ./mvm script. Eliot currently manually updates the checked-in generated-C-sources at times he considers them stably generated from VMMaker-Image, although I think I saw recently some mention of doing CI on each VMMaker check-in.. So the Pharo 5 in-Image CMake generation system is deprecated, and I guess there will not be much further development on the Pharo 5 VM. So I would consider *not* including the bootstrap as part of the nix process and manually perform the bootstrap per steps 1 to 3 here... then archive those folders to create your own source-distribution Now it would be good to hear if Pharo might get a Pharo-5-stable-VM deployed from OpenSmalltalk? cheers -ben > 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. > > |
Re: [Pharo-users] Pharo 6 snap install
|
|
Hi Ben,
On Sun, Apr 16, 2017 at 10:42:42PM +0800, Ben Coman wrote: > On Sat, Apr 15, 2017 at 4:34 PM, Luke Gorrie <[hidden email]> wrote: > > On 15 April 2017 at 10:08, Alistair Grant <[hidden email]> > > wrote: > > > > 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.) > > A historical perspective... > > Prior to this coming Release 6, Pharo had diverged from the parent > build system used by OpenSmalltalk (nee Squeak-VM) such that (IIUC) it > was driven from the Image generating the generated-C-sources plus the > Cmake configuration. I guess this is what you describe as > "bootstrap". > > However for Release 6 onwards, Pharo has returned to the fold and is > directly using the OpenSmalltalk build system. The OpenSmalltalk build > system does not require a build to invoke a Smalltalk image, and I > notice elsewhere you've seen the ./ mvm script. Eliot currently > manually updates the checked-in generated-C-sources at times he > considers them stably generated from VMMaker-Image, although I think I > saw recently some mention of doing CI on each VMMaker check-in.. Do you know how the linux zero conf scripts are / will be built? My assumption has been that they are part of the image build. Thanks, Alistair |
|
|
On Sun, Apr 16, 2017 at 10:50 PM, Alistair Grant <[hidden email]> wrote:
> Hi Ben, > > On Sun, Apr 16, 2017 at 10:42:42PM +0800, Ben Coman wrote: >> On Sat, Apr 15, 2017 at 4:34 PM, Luke Gorrie <[hidden email]> wrote: >> > On 15 April 2017 at 10:08, Alistair Grant <[hidden email]> >> > wrote: >> > >> > 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.) >> >> A historical perspective... >> >> Prior to this coming Release 6, Pharo had diverged from the parent >> build system used by OpenSmalltalk (nee Squeak-VM) such that (IIUC) it >> was driven from the Image generating the generated-C-sources plus the >> Cmake configuration. I guess this is what you describe as >> "bootstrap". >> >> However for Release 6 onwards, Pharo has returned to the fold and is >> directly using the OpenSmalltalk build system. The OpenSmalltalk build >> system does not require a build to invoke a Smalltalk image, and I >> notice elsewhere you've seen the ./ mvm script. Eliot currently >> manually updates the checked-in generated-C-sources at times he >> considers them stably generated from VMMaker-Image, although I think I >> saw recently some mention of doing CI on each VMMaker check-in.. > > Do you know how the linux zero conf scripts are / will be built? > > My assumption has been that they are part of the image build. I'm not familiar with the zero-conf implementation. You might learn something here... https://github.com/pharo-project/pharo-zeroconf cheers -ben |
Re: [Pharo-users] Pharo 6 snap install
|
|
In reply to this post by Ben Coman
On 16 April 2017 at 16:42, Ben Coman <[hidden email]> wrote:
Thanks for the background, Ben. It sounds like the path of least resistance is to forget Pharo 5 and focus on packaging up the Pharo 6 VM in a maintainable way. Then to get a stable VM all I need to do is go hang out at the beach for a few weeks/months while other people sort that out. That works for me :). I have the master branch VM mostly packaged for Nix now, I think. Is there an easy way to run the test suite headless? (How?) I noticed that a few tests failed in your excerpt... perhaps I would consider 99.9% pass rate as good enough to ship. Reasonable? Cheers! -Luke |
Re: [Pharo-users] Pharo 6 snap install
|
|
I have the VM building under nix from the master branch now. The build is based loosely on the linux.64x64 mvm script so it's building a 64-bit x86-64 VM. The pharo-vm commit I am testing is 1c38b03f (from wednesday.)
I have tried opening both Pharo-60465.image and Pharo-50771.image and both give this error:
How come? Is this because I built a 64-bit VM? If I want to use those images then should I build a 32-bit image instead? (Or none of the above?)
Googling around it sounds like this "origin error" is caused by not finding the Sources file but I have provided the PharoV50.sources and strace suggests that it is opened okay: open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/PharoV50.sources", O_RDONLY) = 3So maybe the problem is that I need a different source file? Or maybe that I should switch to a 32-bit VM? Or something else entirely...? Any help appreciated :) -Luke |
|
|
Luke,
I don't see this in the latest binary and I have not adjusted the rtprio figures at all. I can try running some simple tests if you send them to me. $ curl get.pharo.org/64/60+vmLatest | bash .... file Pharo.image Pharo.image: Smalltalk image Spur 64b +C+NF+Tag (68021) $ prlimit --rtprio RESOURCE DESCRIPTION SOFT HARD UNITS RTPRIO max real-time priority 0 0 $ pharo-vm/lib/pharo/5.0-201704120850/pharo --version 5.0-201704120850 Wed Apr 12 09:13:59 UTC 2017 gcc 4.6.3 [Production Spur 64-bit ITHB VM] CoInterpreter VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 12 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 12 2017 VM: 201704120850 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Apr 12 10:50:48 2017 +0200 $ Plugins: 201704120850 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Linux testing-gce-504e47eb-4202-4e16-92e1-3d42dab82e2f 3.13.0-103-generic #150~precise1-Ubuntu SMP Thu Nov 24 11:05:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux plugin path: /opt/share/downloads/pharo/64/pharo-vm/lib/pharo/5.0-201704120850/ [default: /opt/share/downloads/pharo/64/pharo-vm/lib/pharo/5.0-201704120850/] $ ./pharo Pharo.image eval 0 tinyBenchmarks '923354373 bytecodes/sec; 82191014 sends/sec' Regards .. Subbu On Monday 17 April 2017 03:25 AM, Luke Gorrie wrote: > I have the VM building under nix from the master branch now. The build > is based loosely on the linux.64x64 mvm script so it's building a 64-bit > x86-64 VM. The pharo-vm commit I am testing is 1c38b03f (from wednesday.) > > I have tried opening both Pharo-60465.image and Pharo-50771.image and > both give this error: > > This interpreter (vers. 68021) cannot read image file (vers. 6521). > > > How come? Is this because I built a 64-bit VM? If I want to use those > images then should I build a 32-bit image instead? (Or none of the above?) > > Then I found Pharo64-60465.image and this does open and display a window > but it's frozen and prints these messages: > > pthread_setschedparam failed: Operation not permitted > This VM uses a separate heartbeat thread to update its internal clock > and handle events. For best operation, this thread should run at a > higher priority, however the VM was unable to change the priority. The > effect is that heavily loaded systems may experience some latency > issues. If this occurs, please create the appropriate configuration > file in /etc/security/limits.d/ as shown below: > > cat <<END | sudo tee /etc/security/limits.d/squeak.conf > * hard rtprio 2 > * soft rtprio 2 > END > > and report to the squeak mailing list whether this improves behaviour. > > You will need to log out and log back in for the limits to take effect. > For more information please see > https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > 'Your VM is too old for this image. Please download the latest VM.' > Error: Can't find the requested origin > > > UnixResolver(PlatformResolver)>>cantFindOriginError > [ self cantFindOriginError ] in > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in > Block: [ self cantFindOriginError ] > [ ^ aBlock value ] in > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in > Block: [ ^ aBlock value ] > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > Error(Exception)>>signal > Error(Exception)>>signal: > ExternalLibraryFunction(Object)>>error: > ExternalLibraryFunction(Object)>>externalCallFailed > ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: > UnixEnvironment(OSEnvironment)>>getEnv: > UnixEnvironment(OSEnvironment)>>at:ifAbsent: > [ Smalltalk os environment at: aString ifAbsent: [ nil ] ] in > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in > Block: [ Smalltalk os environment at: aString ifAbse\ > nt: [...etc... > BlockClosure>>on:do: > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: > UnixResolver>>home > [ self home / '.config' ] in UnixResolver>>preferences in Block: [ > self home / '.config' ] > [ ^ aBlock value ] in > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in > Block: [ ^ aBlock value ] > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > Error(Exception)>>signal > Error(Exception)>>signal: > ExternalLibraryFunction(Object)>>error: > ExternalLibraryFunction(Object)>>externalCallFailed > ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: > UnixEnvironment(OSEnvironment)>>getEnv: > FFICalloutAPI>>function:module: > > > Googling around it sounds like this "origin error" is caused by not > finding the Sources file but I have provided the PharoV50.sources and > strace suggests that it is opened okay: > > open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/PharoV50.sources", > O_RDONLY) = 3 > open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/PharoV50.sources", > O_RDONLY) = 6 > > So maybe the problem is that I need a different source file? Or maybe > that I should switch to a 32-bit VM? Or something else entirely...? > > Any help appreciated :) > -Luke > |
Re: [Pharo-users] Pharo 6 snap install
|
|
In reply to this post by Luke Gorrie
On Sun, Apr 16, 2017 at 11:55:27PM +0200, Luke Gorrie wrote:
> I have the VM building under nix from the master branch now. The build is based > loosely on the linux.64x64 mvm script so it's building a 64-bit x86-64 VM. The > pharo-vm commit I am testing is 1c38b03f (from wednesday.) > > I have tried opening both Pharo-60465.image and Pharo-50771.image and both give > this error: > > > This interpreter (vers. 68021) cannot read image file (vers. 6521). > > > How come? Is this because I built a 64-bit VM? If I want to use those images > then should I build a 32-bit image instead? (Or none of the above?) Yes, 32 bit VM will only work with 32 bit images, and 64 bit VM with 64 bit images. > Then I found Pharo64-60465.image and this does open and display a window but > it's frozen and prints these messages: > > > pthread_setschedparam failed: Operation not permitted > This VM uses a separate heartbeat thread to update its internal clock > and handle events. For best operation, this thread should run at a > higher priority, however the VM was unable to change the priority. The > effect is that heavily loaded systems may experience some latency > issues. If this occurs, please create the appropriate configuration > file in /etc/security/limits.d/ as shown below: > > cat <<END | sudo tee /etc/security/limits.d/squeak.conf > * hard rtprio 2 > * soft rtprio 2 > END > > and report to the squeak mailing list whether this improves behaviour. > > You will need to log out and log back in for the limits to take effect. > For more information please see > https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux As this says, for best operation you should enable higher priority threads. Have you tried creating the file as described? That said, the message is only a warning, the system should be basically working. > 'Your VM is too old for this image. Please download the latest VM.' > Error: Can't find the requested origin > > > UnixResolver(PlatformResolver)>>cantFindOriginError > [ self cantFindOriginError ] in UnixResolver(PlatformResolver)>> > directoryFromEnvVariableNamed: in Block: [ self cantFindOriginError ] > [ ^ aBlock value ] in UnixResolver(PlatformResolver)>> > directoryFromEnvVariableNamed:or: in Block: [ ^ aBlock value ] > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > Error(Exception)>>signal > Error(Exception)>>signal: > ExternalLibraryFunction(Object)>>error: > ExternalLibraryFunction(Object)>>externalCallFailed > ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: > UnixEnvironment(OSEnvironment)>>getEnv: > UnixEnvironment(OSEnvironment)>>at:ifAbsent: > [ Smalltalk os environment at: aString ifAbsent: [ nil ] ] in UnixResolver > (PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block: [ Smalltalk > os environment at: aString ifAbse\ > nt: [...etc... > BlockClosure>>on:do: > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: > UnixResolver>>home > [ self home / '.config' ] in UnixResolver>>preferences in Block: [ self > home / '.config' ] > [ ^ aBlock value ] in UnixResolver(PlatformResolver)>> > directoryFromEnvVariableNamed:or: in Block: [ ^ aBlock value ] > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > Error(Exception)>>signal > Error(Exception)>>signal: > ExternalLibraryFunction(Object)>>error: > ExternalLibraryFunction(Object)>>externalCallFailed > ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: > UnixEnvironment(OSEnvironment)>>getEnv: > FFICalloutAPI>>function:module: > > > Googling around it sounds like this "origin error" is caused by not finding the > Sources file but I have provided the PharoV50.sources and strace suggests that > it is opened okay: > > > open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/ > PharoV50.sources", O_RDONLY) = 3 > open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/ > PharoV50.sources", O_RDONLY) = 6 If I'm reading the stack correctly, it looks like your HOME environment variable isn't set (or the VM isn't able to access it). > So maybe the problem is that I need a different source file? Or maybe that I > should switch to a 32-bit VM? Or something else entirely...? The 32 bit VM is more stable than the 64 bit one at the moment. If you are still getting the build system stabilised, it might be easier to stick with 32 bits for now. Switching to 64 bits later should be straightforward (certainly easier than switching from building Pharo 5 to Pharo 6). Cheers, Alistair |
Re: [Pharo-users] Pharo 6 snap install
|
|
On 17 April 2017 at 07:50, Alistair Grant <[hidden email]> wrote: Yes, 32 bit VM will only work with 32 bit images, and 64 bit VM with 64 I wonder if some DWIM would make sense here. For example, my bash wrapper that starts the VM could inspect the image file and decide which VM is appropriate (spur, non-spur, 32-it, 64-bit, etc.) Otherwise the user needs to guess and decipher cryptic error messages. Has anybody made such a "DWIM" script that automatically selects the right VM? Would love a link to use for reference. Is there any compatibility matrix to help me understand which VMs are compatible with which images? Now I know that the 64-bit VM can't run 32-bit images but I am wondering whether e.g. the Spur VM can run older images like Pharo 4 / DrGeo / etc or whether different VMs need to be built for those too. As this says, for best operation you should enable higher priority I will look for a build option to disable this feature that wants to set realtime priority. I don't think it's reasonable to expect end-users to edit /etc files in order to run GUI applications. I also don't like applications blindly printing instructions that are distro-specific (there is no /etc/security directory on NixOS for example.) I also :-) don't immediately see why it is safe to assume that running pharo at realtime scheduler priority is what the user will want when their system becomes overloaded. I already know that another problem coming down the pipeline, after making the VM work, is finding hard-coded paths in popular image files that only work on some distributions. For example the Moose image makes some unsafe assumptions about what libcairo will be called, https://github.com/NixOS/nixpkgs/pull/14414 Grumble, grumble, grumble :). But soon all fixed! If I'm reading the stack correctly, it looks like your HOME environment Odd. That should not be the case. I will dig deeper. > So maybe the problem is that I need a different source file? Or maybe that I Thanks for the tip! I will try to build the 32-bit VM now. |
Re: [Pharo-users] Pharo 6 snap install
|
|
On Mon, Apr 17, 2017 at 09:34:53AM +0200, Luke Gorrie wrote:
> On 17 April 2017 at 07:50, Alistair Grant <[hidden email]> wrote: > > Yes, 32 bit VM will only work with 32 bit images, and 64 bit VM with 64 > bit images. > > > I wonder if some DWIM would make sense here. For example, my bash wrapper that > starts the VM could inspect the image file and decide which VM is appropriate > (spur, non-spur, 32-it, 64-bit, etc.) Otherwise the user needs to guess and > decipher cryptic error messages. That would be great. It doesn't look like the images have a human readable magic number at the start. Hopefully someone can give us a hint. > Has anybody made such a "DWIM" script that automatically selects the right VM? > Would love a link to use for reference. > > Is there any compatibility matrix to help me understand which VMs are > compatible with which images? Now I know that the 64-bit VM can't run 32-bit > images but I am wondering whether e.g. the Spur VM can run older images like > Pharo 4 / DrGeo / etc or whether different VMs need to be built for those too. > > > As this says, for best operation you should enable higher priority > threads. Have you tried creating the file as described? > > > I will look for a build option to disable this feature that wants to set > realtime priority. This isn't really a feature, it's a core part of the VM's operation. You could choose to build the itimer VM, but that has its own problems. See: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux http://forum.world.st/Iceberg-with-SSH-on-Linux-td4940436.html http://forum.world.st/Unix-heartbeat-thread-vs-itimer-td4928943.html#a4938456 Cheers, Alistair > I don't think it's reasonable to expect end-users to edit /etc files in order > to run GUI applications. I also don't like applications blindly printing > instructions that are distro-specific (there is no /etc/security directory on > NixOS for example.) I also :-) don't immediately see why it is safe to assume > that running pharo at realtime scheduler priority is what the user will want > when their system becomes overloaded. > > I already know that another problem coming down the pipeline, after making the > VM work, is finding hard-coded paths in popular image files that only work on > some distributions. For example the Moose image makes some unsafe assumptions > about what libcairo will be called, https://github.com/NixOS/nixpkgs/pull/14414 > > Grumble, grumble, grumble :). But soon all fixed! > > > If I'm reading the stack correctly, it looks like your HOME environment > variable isn't set (or the VM isn't able to access it). > > > Odd. That should not be the case. I will dig deeper. > > > > So maybe the problem is that I need a different source file? Or maybe > that I > > should switch to a 32-bit VM? Or something else entirely...? > > The 32 bit VM is more stable than the 64 bit one at the moment. If you > are still getting the build system stabilised, it might be easier to > stick with 32 bits for now. Switching to 64 bits later should be > straightforward (certainly easier than switching from building Pharo 5 > to Pharo 6). > > > Thanks for the tip! > > I will try to build the 32-bit VM now. > > |
|
|
In reply to this post by Luke Gorrie
On Monday 17 April 2017 01:04 PM, Luke Gorrie wrote:
> > I wonder if some DWIM would make sense here. For example, my bash > wrapper that starts the VM could inspect the image file and decide which > VM is appropriate (spur, non-spur, 32-it, 64-bit, etc.) Otherwise the > user needs to guess and decipher cryptic error messages. You can use the attached magic file with file(1) command: file -m magic <image files> ... to detect the image type. or register the patterns with binfmt_misc to match the vm to the image type automatically. BTW, I goofed in my earlier email. I was using 64/vm60 and not 64/vmT60. Sorry for the confusion. With 64/vmT60, I use the following : $ sudo prlimit --rtprio=2 --pid $$ $ ./pharo Pharo.image eval 3+4 Regards .. Subbu |
magic (1K)
Re: [Pharo-users] Pharo 6 snap install
|
|
In reply to this post by alistairgrant
On 17 April 2017 at 10:17, Alistair Grant <[hidden email]> wrote: This isn't really a feature, it's a core part of the VM's operation. Thanks for the links! I have only read through once, but isn't it a no-brainer to disable that message telling you to edit your kernel config? It's very user-unfriendly, it's the very first thing a new user will see the first time they try Pharo, it's not actually applicable to all Linux distributions, and it provides no demonstrable benefit? |
Re: [Pharo-users] Pharo 6 snap install
|
|
On 17 April 2017 at 11:01, Luke Gorrie <[hidden email]> wrote:
^^^ please forgive gratuitously combative tone :) Fighting the VM build in another window. Just now I am able to build the 32-bit VM from master and run both the Pharo 5 and Pharo 6 images. The next problem is the issue of accessing $HOME. The actual error is ExternalLibraryFunction>>invokeWithArguments: failing to call getenv() from libc. Simplest way that I can reproduce it here is Smalltalk os environment at: 'HOME'. Checking for what I can have mucked up in the build... Otherwise I need to supply the "smudged" version information in some reasonable way. I don't have access to the .git folder during build so I can't use the perl script directly. I see that I can't just skip these values either because on startup I am also seeing a warning that my "VM is too old" coming from DiskStore class>>checkVMVersion that wants to see that my VM source is from at least July 2012 :). |
Re: [Pharo-users] Pharo 6 snap install
|
|
Hi Luke,
On Mon, Apr 17, 2017 at 11:33:38AM +0200, Luke Gorrie wrote: > On 17 April 2017 at 11:01, Luke Gorrie <[hidden email]> wrote: > Otherwise I need to supply the "smudged" version information in some reasonable > way. What about the genVersion.sh script I provided earlier in this thread? > I don't have access to the .git folder during build so I can't use the > perl script directly. Which perl script (I'm still learning about the build process), and why would you need access to git blobs directly? > I see that I can't just skip these values either because > on startup I am also seeing a warning that my "VM is too old" coming from > DiskStore class>>checkVMVersion that wants to see that my VM source is from at > least July 2012 :). What does "Smalltalk vm interpreterSourceDate" actually return? Cheers, Alistair |
Re: [Pharo-users] Pharo 6 snap install
|
|
In reply to this post by K K Subbu
On Mon, Apr 17, 2017 at 02:07:40PM +0530, K K Subbu wrote:
> On Monday 17 April 2017 01:04 PM, Luke Gorrie wrote: > > > >I wonder if some DWIM would make sense here. For example, my bash > >wrapper that starts the VM could inspect the image file and decide which > >VM is appropriate (spur, non-spur, 32-it, 64-bit, etc.) Otherwise the > >user needs to guess and decipher cryptic error messages. > > You can use the attached magic file with file(1) command: > > file -m magic <image files> ... > > to detect the image type. or register the patterns with binfmt_misc to match > the vm to the image type automatically. Thanks! This should make it straightforward to update the startup scripts. Cheers, Alistair |
Re: [Pharo-users] Pharo 6 snap install
|
|
In reply to this post by alistairgrant
On 17 April 2017 at 11:59, Alistair Grant <[hidden email]> wrote: What about the genVersion.sh script I provided earlier in this thread? The genVersion.sh script has a dependency under the hood that I can't satisfy: it expects to be able to run git commands but I can't do that in the nix environment. The root problem is that nix requires a perfectly reproducible build environment, with the sha256 hash of every dependency declared, and that is hard to do for the .git folder. The .git is really a database that contains many source code versions and not just the one that I have checked out. Which perl script (I'm still learning about the build process), and why Check out opensmalltalk-vm/.git_filters/RevDateURL.smudge. This is a perl script that is accessing environmental state that's off-limits in the nix universe e.g. whoami, hostname, date, git, etc. Could be that I should write the version info by hand and apply it as a patch. I have to make my build produce the same result every time it runs. That way it will always work the same, and somebody in 5 years who wants to run an _ancient_ Pharo 6 image will be able to do that with my build script because it's a fixed point. What does "Smalltalk vm interpreterSourceDate" actually return? actually it gets an exception because I don't have well-formed values from the strings it is trying to parse. |
Re: [Pharo-users] Pharo 6 snap install
|
|
In reply to this post by Luke Gorrie
On 17 April 2017 at 11:33, Luke Gorrie <[hidden email]> wrote:
I have resolved this now. The problem was the VM primitive ioLoadModule() not being able to find libc. It has some heuristics for where to look but they don't work on NixOS. I added the relevant folder into $LD_LIBRARY_PATH in my wrapper script and now it is happy. There will be a lot of this in my future... finding hard-coded paths for things like shared libraries and un-hard-coding them. I am not sure what to do in cases where the paths are in Smalltalk code inside an image, that's harder to patch than the VM sources or ELF headers etc. |
Re: [Pharo-users] Pharo 6 snap install
|
|
On Mon, Apr 17, 2017 at 12:47:38PM +0200, Luke Gorrie wrote:
> On 17 April 2017 at 11:33, Luke Gorrie <[hidden email]> wrote: > > Fighting the VM build in another window. Just now I am able to build the > 32-bit VM from master and run both the Pharo 5 and Pharo 6 images. The next > problem is the issue of accessing $HOME. The actual error is > ExternalLibraryFunction>>invokeWithArguments: failing to call getenv() from > libc. Simplest way that I can reproduce it here is Smalltalk os environment > at: 'HOME'. > > > I have resolved this now. > > The problem was the VM primitive ioLoadModule() not being able to find libc. It > has some heuristics for where to look but they don't work on NixOS. I added the > relevant folder into $LD_LIBRARY_PATH in my wrapper script and now it is happy. > > There will be a lot of this in my future... finding hard-coded paths for things > like shared libraries and un-hard-coding them. I am not sure what to do in > cases where the paths are in Smalltalk code inside an image, that's harder to > patch than the VM sources or ELF headers etc. I've hit this as well building the snap package, e.g. CairoLibrary>>unixModuleName. I modified the method directly, but probably it would be better to create a UnixPlatform>>findLibrary: method to look after it centrally. Cheers, Alistair |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |