On Mon, Apr 17, 2017 at 09:34:53AM +0200, Luke Gorrie wrote: > On 17 April 2017 at 07:50, Alistair Grant <[email protected]> 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. > >
