[Vm-dev] Fwd: Nix package for Pharo flavor of opensmalltalk-vm

[Luke Gorrie]

Thanks Ben for testing this, it's really helpful!

On 20 April 2017 at 06:03, Ben Coman <btc at openinworld.com> wrote:

> After I did that and it spent a few minutes pulling in and compiling
> dependencies and compiling the VM,
> I ran it again, and it completed immediately taking minimal action.  Thats
> cool!
>

This is the nice benefit of referential transparency on the builds. Since
the result is always the same, because the whole build environment is held
constant, you can safely reuse previous builds instead of making new ones.
Your /nix/store directory contains all the builds you have made. (You can
run 'nix-collect-garbage' to free up space from old builds.)

Once the packages go upstream nobody will need to compile it locally. Their
'nix-env' command will use the sha256 to get a binary from cache.nixos.org
(populated by upstream CI builds.)

But yeah the first time it sure takes a while because you are basically
downloading a whole Linux distro. I neglected to mention that you could
write 'nix-env -j 10' to run many build steps (including downloads) in
parallel. That can really speed things up at the expense of obfuscating the
output.

When I ran that, it kicked off a few more minutes compiling.  Is that
> expected?
>

Installing the first image will also install Xvfb (+ dependencies) in order
to run a unit test. (Could be that I should run headless pharo instead but
figured that exercising the X11 display driver would be worth the extra
installation time.)

Also I got an error "error: detected 64-bit image but 64-bit VM is not
> available"
> perhaps since I'm on 32-bit Debian (Jessie-8).  Is there some way to guard
> against such error?
>

Good catch!

This error is from installing a 64-bit Pharo image. The unit test will
check that the image actually runs, and this failed due to missing the
required VM.

The solution is that I need to exclude the 64-bit images on 32-bit
machines. (I did already exclude the spur64 VM but I didn't think to
exclude the images too.)

Just as a workaround you could install images individually by changing '-iA
pharo' to e.g. '-iA pharo5' or '-iA moose61'.

Since Pharo 6 is not yet released, what are the implications of naming
> these pharo-6.dev
>

On reflection I will split up my packaging work into "vm" and "image"
components. I will send the vm upstream ASAP. I will leave the images on a
development branch, perhaps indefinitely, because I am not sure that I am
on the right track there at all.

So, here are more thoughts on image packaging, but with the disclaimer that
I will probably not actively pursue this topic further at the moment:

I assert that Pharo 5 and Pharo 6 are both released, and are both
fast-moving targets.

On http://pharo.org/download there is a prominent link to Pharo 6 as the
"development version" ready for download. Anecdotally the Pharo community
that I interact with (mailing list, twitter, slack chat, etc) seem more
focused on Pharo 6 than on Pharo 5. Occasionally people express surprise
when I tell them I am "still" using Pharo 5.

On http://files.pharo.org/image/50/ there is a new release of Pharo 5 every
few weeks. This means that each time I have downloaded "Pharo 5" in the
past I have probably gotten a different image and a different VM. So from
my end-user perspective I have no idea what software I am installing
regardless of whether I choose Pharo 5 or Pharo 6.

So as a nix user it would make sense for me to be able to download both
Pharo 5 and Pharo 6 and for the nix package definitions to determine
exactly which software I am running (as opposed to getting an invisible
update from Pharo upstream every few days/weeks potentially leading to "but
it worked fine on my other machine..." sorts of problems that are exactly
what can nix protect me from.)

Packing the other images is maybe also wrong.  How would you deal with user
> state being stored in the image when a new build download in available?
>

The ad-hoc idea that I ran with is this:

Running a script like pharo-5.0 (or moose-6.1, etc) will make a temporary
copy of the image in the current directory. The changes file will be
read-write (requirement) but the image file will be read-only. The model is
"you saved it, you own it" i.e. if you want the image to survive after exit
you need to "Save image as..." and once you do that then you are
responsible for it.

Code: script to run an image
<https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/images/build-image.nix#L27-L33>
and script to start the right vm
<https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/wrapper/pharo-vm.sh>
.

I am not sure why "Save image as..." is misbehaving for me. I have tested
every combination of read/write permissions on the working directory, the
image, the changes file, etc, but it was always the same. I am sure that I
can work this out via the Smalltalk debugger -- but at the moment it seems
to make more sense to focus on the VM than on the images. (I want to wrap
this up.)

The downside to skipping the images is that I don't maintain feature parity
with Damien's original nix packaging. He packaged the launcher image and
then that was the gateway to everything else. This solution doesn't feel
very solid to me, since now in 2017 I don't think the launcher is
accounting for all the different VM requirements properly, but I am not
willing to pick up maintenance of that image so that is life.

Cheers,
-Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170420/9cf27b1a/attachment-0001.html>