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