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

[Ben Coman]

On Thu, Apr 20, 2017 at 12:21 AM, Luke Gorrie <luke at snabb.co> wrote:

>
> Hi Ben & all,
>
> I revised the nix packaging. I'll do a little testing and cleaning up and
> then send it upstream. Quick testing or feedback would be really welcome!
>
> This (long, single line) command installs the VMs (cog, spur, spur64)
> behind a simple wrapper:
>
> nix-env --option tarball-ttl 0 -f https://github.com/lukego/
> nixpkgs/archive/pharo6.tar.gz -iA pharo.vm
>
>
>
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!

Then you can start an image like this:
>
> pharo-vm ...
>
>
>


> You can also install a few off-the-shelf images with dedicated startup
> scripts. Here's how to install all of them:
>
> nix-env --option tarball-ttl 0 -f https://github.com/lukego/
> nixpkgs/archive/pharo6.tar.gz -iA pharo
>
>
>
When I ran that, it kicked off a few more minutes compiling.  Is that
expected?
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?
So the following did commands seem to have not been installed.



> Then you can start one of those images with these shell commands:
>
> pharo-6.0
> pharo64-6.0
>
>
Since Pharo 6 is not yet released, what are the implications of naming
these pharo-6.dev


> pharo-5.0
> moose-6.1
> pharo-launcher-2017.02.28
>
>
> There is a little automatic testing: Each image is started under Xvfb to
> see if it crashes.
>
> I am having some trouble doing "Save as..." to persist these images. The
> image seems to suggest saving them in the root directory, rather than the
> current directory, and I haven't managed to actually save an image. Weird.
> Have to look a bit harder. Let me know if you see the problem!
>

Is it directory permissions on the image file, or directory containing the
image file?


>
> btw: The images are maintained manually
> <https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/images/default.nix>.
> Could be automated in the future with a program to generate that file. Or
> maybe packaging images is the wrong idea and the launcher is better. Time
> will tell.
>

I think at least packaging the bleeding edge (i.e. atm Pharo 6) is wrong,
since it changes fast.
If Squeak adopts this, it may make more sense for them.  Squeak trunk works
more with an incremental growth of an Image, with a chain of updates
scripts (someone might provide more detail), whereas Pharo has more of a
bootstrap process where each build is not a child of the previous build,
which is where PharoLauncher is useful.

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?

cheers -ben


>
>
> On 18 April 2017 at 23:00, Luke Gorrie <luke at snabb.co> wrote:
>
>> On 18 April 2017 at 18:59, Ben Coman <btc at openinworld.com> wrote:
>>
>>> This worked fine for me on 32bit Debian 8 Jessie, resulting in...
>>>
>>
>> Cool! Thanks for testing that.
>>
>> The reason you see some "Jan 1 1970" timestamps is that nix resets file
>> modification times back to the epoch to make the build more reproducible.
>>
>> Being able to try a compiler upgrade and then cleanly rollback is a great
>>> feature.  I gather that under the covers, so switching between two
>>> environments is just a quick link change?
>>>
>>
>> Yep.
>>
>> You can also skip the symlinks and construct the software environment you
>> want with a custom $PATH. Here is a command to start a sub-shell with
>> exactly the build environment used for compiling the vm:
>>
>> $ nix-shell https://github.com/lukego/nixpkgs/archive/pharo6.tar.gz -A
>> pkgs.pharo-vm
>>
>> This will start a shell with $PATH including exactly the expected
>> versions of bash, gcc, autoconf, libtool, etc, that the build would use.
>> Good for trouble shooting.
>>
>> The binaries that you build will also remember exactly which shared
>> objects they are supposed to link with (e.g. which build of glibc):
>>
>> $ ldd $(which ls)
>>         linux-gate.so.1 (0xf7767000)
>>         librt.so.1 => /nix/store/djclawhih7363vlvsbr
>> gfi1fr8l3glix-glibc-2.25/lib/librt.so.1 (0xf7759000)
>>         libacl.so.1 => /nix/store/v480rw5maz01wh5ysrm
>> a8mhl6qy1kvjd-acl-2.2.52/lib/libacl.so.1 (0xf774f000)
>>         libattr.so.1 => /nix/store/h6k7bwddlfzv1sbwxbn
>> l795h0317wrwp-attr-2.4.47/lib/libattr.so.1 (0xf7749000)
>>         libpthread.so.0 => /nix/store/djclawhih7363vlvsbr
>> gfi1fr8l3glix-glibc-2.25/lib/libpthread.so.0 (0xf772b000)
>>         libc.so.6 => /nix/store/djclawhih7363vlvsbr
>> gfi1fr8l3glix-glibc-2.25/lib/libc.so.6 (0xf7573000)
>>
>>         /nix/store/djclawhih7363vlvsbrgfi1fr8l3glix-glibc-2.25/lib/ld-linux.so.2
>> (0xf7769000)
>>
>>
>> More nice tricks here: https://gist.github.com/
>> travisbhartwell/f972aab227306edfcfea
>>
>> Now would any of the other dialects like to add to this?
>>> At a minimum, perhaps just adding sources filesto...
>>> https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/developme
>>> nt/pharo/vm/share.nix
>>>
>>
>> That would be neat!
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170420/628f9476/attachment.html>