Install elm 0.16 on nixos

Last I checked elm had made it into nixpkgs (at least in unstable), but its only at 0.14.  With the flurry of blog posts lately about 0.16, 0.14 is not going to cut it!  Luckily installing 0.16 is pretty easy (except for the shell.nix perhaps):

> cd <where I keep code>
> mkdir elmthings
> cd elmthings

Then (just like with 0.15.1), make an shell.nix file that looks like this:

nixpkgs ? import  {}, compiler ? "ghc7102" }:
  inherit (nixpkgs) pkgs;
  cabal = pkgs.haskell.packages.${compiler}.cabal-install;
  ghc = pkgs.haskell.packages.${compiler}.ghcWithPackages (ps: with ps; [
          monad-par mtl
pkgs.stdenv.mkDerivation {
  name = "my-haskell-env-0";
  buildInputs = [ ghc cabal pkgs.zlib ];
  shellHook = "eval $(egrep ^export ${ghc}/bin/ghc)";

Then its just following the directions from the elm site:

[pr06lefs@nixosthe1:~/code/elmthings]$ nix-shell
[nix-shell:~/code/elmthings]$ curl > BuildFromSource.hs
[nix-shell:~/code/elmthings]$ runhaskell BuildFromSource.hs 0.16

If all goes well, the executables end up in the following directory. This directory should be added to your path.


[nix-shell:~/code/elmthings/Elm-Platform/0.16/.cabal-sandbox/bin]$ ls
aeson-pretty elm elm-make elm-package elm-reactor elm-repl glsl-pprint

With the correct llvm, ghc 7.10.2 works on the raspberry pi 2

I filed a bug re my problems with running ghc 7.10.2 on the pi2, and we got it solved eventually.  It turns out that debian jessie comes with llvm 3.5-10, but llvm 3.5.2-2 is the version (or one valid version?) that is required.  Now it seems to be working nicely!  There is still a bug in ghci, but you can at least run it without an immediate exception.

I installed ghc using the 7.10.2-2 debian experimental package, currently available here.  Check the bug for notes on installing the correct llvm.  I switched to ‘testing’ and that had the correct libstdc++ among other libs required by llvm 3.5.2-2.

I went ahead and built cabal-install version and then used that to install stack  Those required quite a bit of compile time (10+ hours for stack) so I’m making the binaries available here to save time for someone.

If you decide to build stack yourself, you’ll need more than 1g of memory.  My raspberry pi 2 only has 1g so I used a 500m swap file, which I think was barely enough.  With cabal I was able to build a yesod project without needing to tweak persistent-sqlite as with ghc 7.8.2.  Good stuff!

As for stack, I was able to build my yesod project with it, in 3 runs.  The first compile died when the SD card ran out of space, the second completed but failed the link step (I think) with exit code -9, and then the third was able to link successfully.  Total compile time:

run1: 232m43.771s
run2: 591m46.461s
run3: 6m16.723s

total: 830.75 mins, or 13.8 hours.  epic compile!  I used stack lts-3.5.

Set up Elm 0.15.1 on nixos

Ed:  elm is at 0.16, so I’ve put up a new guide, simpler than this one. 

Elm hasn’t made its way into nix-pkgs just yet, so building from source is still necessary.  The latest version is 0.15.1.  Last time I tried installing, it didn’t work out.  But today it was pretty straightforward with the right version of ghc.  I tried 7.8.4 but had some library conflicts.  With 7.10.2 installation was successful.

So to get going, first clone the git repo:

> cd <where I keep code>
> git clone
> git checkout 0.15.1

Then, make an shell.nix file that looks like this:

nixpkgs ? import  {}, compiler ? "ghc7102" }:
  inherit (nixpkgs) pkgs;
  cabal = pkgs.haskell.packages.${compiler}.cabal-install;
  ghc = pkgs.haskell.packages.${compiler}.ghcWithPackages (ps: with ps; [
          monad-par mtl
pkgs.stdenv.mkDerivation {
  name = "my-haskell-env-0";
  buildInputs = [ ghc cabal pkgs.zlib ];
  shellHook = "eval $(egrep ^export ${ghc}/bin/ghc)";

And put that shell.nix into the elm-platform directory.  Then,

[bburdette@nixosthe1:~/code/elm-platform]$ nix-shell
[nix-shell:~/code/elm-platform]$ runhaskell installers/BuildFromSource.hs 0.15.1

If all goes well, the executables end up here. This directory should be added to your path.

[nix-shell:~/code/elm-platform/Elm-Platform/0.15.1/.cabal-sandbox/bin]$ ls
aeson-pretty elm elm-make elm-package elm-reactor elm-repl glsl-pprint

GHC web dev considered harmful on ARM

This is to detail some of my recent experiences with trying to get some web stuff to work on ARM.  Verdict:  avoid!

Ed: with the correct llvm ghc 7.10.2 works!  Details here.

Ok, granted you can compile some haskell programs on ARM just fine.  If your code will compile with ghc 7.6 or earlier, for instance, chances are you’ll be ok.  On my ‘cyclophone’ instrument project the central control program (there are several small programs that run) can compile with older ghc and it seems to run ok.

But, I wanted a web component to the instrument, for controlling parameters, chord sequencing, etc.  I wrote something that ran fine on my laptop, using Yesod, which is not known for its light weight dependencies.  And eventually, with much struggle, I did get it to compile on arm!  But that turns out to not be repeatable, unfortunately, and I had to ignore some scary sounding error messages along the way.  Also, did I mention the hours of compiling?  Many hours.

But, you say, I think I can make it work, I’m a veteran haskell build tweaker.  Ok, I’ll tell you what worked for me.  Who knows, maybe it will work!  If so let me know how you did it.

  • first off, the newest working version of ghc that I’ve tried is 7.8.2, which is conveniently supplied as a package in arch linux.  Anything newer has fatal bugs.  That link is for a ghci illegal instruction error, but it turns out that executables that you build will also have this error.  On raspberry pi 2 with debian jessie, the recommended distro for the recent 7.10.2 ghc binary, this bug manifested while trying to bootstrap cabal.  You can’t use an older cabal because 7.10.2 requires a new one, and the bootstrapping fails, and that’s game over for ghc 7.10.2 on arm.  Actually its worse than that: 7.10.2 can’t compile a ‘hello world’ that doesn’t crash.  According to comments in the linked bug, anything from 7.8.4 on up has this bug as well.
  • That version of 7.8.2 in arch I mentioned?  Turns out llvm in arch is too new (3.6 as of this writing), and 7.8.2 won’t work with that.  You have to downgrade to an earlier llvm, and the llvm downgrade packages are not officially available.  Does this sketch you out yet?  Maybe ghc isn’t the best choice on arm?  Ok I have llvm downgrade packages for you, see the comments in my earlier post.  After downgrading you’ll have ghci working and fairly decent compiling stability compare to the nonfunctional 7.10.2.
  • Did you know cross compiling is broken for arm because of template haskell?  Something about ghc generating arm code which then has to be run during compilation, but you’re not compiling on arm so fail.  That’s the word on the street anyway, I didn’t try it myself.  So if you’re planning to use Yesod, it had better compile on your arm machine.  Make sure you have enough ram!  You could try a swap file, see the ‘swap file creation’ section here.  For me, it turns out lack of memory wasn’t a problem, and so the swap file didn’t help.
  • in its default mode, persistent-sqlite is broken on arm.  It has problems with compiling C code (that implements sqlite) that goes along with the project – I believe this is a ghc bug.  You can work around it by setting this convenient flag to ‘true’:
    flag systemlib
    description: Use the system-wide sqlite library
    default: True
    Then, you’ll want to add your altered persistent-sqlite to the sandbox for your yesod project, with “cabal sandbox add-source <path to your checkout of persisent>/persistent/persistent-sqlite”
  • Newer versions of persistent-sqlite have an additional C file to compile, unfortunately.  I was able to successfully compile version 2.1.3 because it doesn’t have that file.  I’m not sure exactly when the other file came in to the project, but anyway there you go.
  • Compiling my little yesod project takes at least 6 hours.  The first time.  You may end up needing to change library versions and recompile everything multiple times.  Sometimes the compiler got stuck – one library in particular I had to cancel after it compiled for over 8 hours.
  • If your ram is only 1g, you must compile with the -j1 (or -j2 if you’re feeling lucky) option.  This limits your build to 1 or 2 threads, respectively.  Running out of memory is a thing, especially on the raspberry pi 2 with its quad cores.  So that’s:  “cabal -j1 install” for instance.
  • A lot of times the compile will fail, with some crash or other problem.  Often you can make the offending library compile by installing it by itself, then you can restart your project build and make it a little further.
  • I actually got my yesod project to build on bananapi with ghc 7.8.2!  I just kept rebuilding and etc until it worked.  I haven’t done a cabal update in over 150 days on that machine and I’m afraid if I touch anything the build will stop working.
  • I followed the same procedures to install ghc 7.8.2 and etc on the raspberry pi 2, also with arch.  There, compiler crashes made it impossible to complete installation.  It eventually failed on the link step, having compiled all the many libraries successfully.  Close but no cigar.
  • Ok yeah Yesod is far from an ideal framework for a little computer like the pi 2.  Its the opposite of lightweight, at least for compiling.  So I also tried scotty but that had similar compile difficulties.

So for myself, I’ve decided to check out rust as an alternative for this project, although I will be keeping an eye on the state of play for haskell on arm (seeing as I already wrote a perfectly good server in haskell).  Rust is not mainstream for web, but my needs are minimal – implementing some sliders in the browser UI to tweak parameters in the instrument, and maybe a few other things, we’ll see.  Arm binaries are here.  I made a little hello world project with dependencies on various libraries I want to use – json, sqlite, websockets, ‘iron’ web server, html, osc – and it downloaded and compiled everything in about 20 mins, with four threads of compilation using a constant 160mb of memory.  Not bad, rust!

As for ghc, well, my feeling is that arm support is a minor consideration at best, and that extensive testing just doesn’t happen for arm, either on libraries or for the compiler itself.  Its too bad, as performance is pretty good if you can ever get your program to compile.  But the reality is that ghc is sketchy and unreliable on arm, and arm problems, although they are being worked on, are not high priority in the haskell community as a whole.

Wirelessly sync your android phone pictures

For a while I’ve been looking for a way to conveniently sync directly with my android phone, without any cloud services like dropbox or etc.  Here’s a simple method – although I had to do a bit of googling to get it to work.  I’m kind of ashamed to say how long I limped along before finally devoting some time to getting this together.

First off I use this adware SSHDroid.  Who knows what information its phoning home?  But it is free, and works ok, and anyway I consider any information on an android phone to be compromised.  So..

step 1: install SSHDroid.

step 2: verify that you can ssh in to your android phone from the command line (you’re on linux, right?).  For example:

> ssh root@

step 3: set aside a directory on your computer into which you want to put your photos.  For me its ~/Pictures/phonepix.

step 4: cd to one up from there (for me ~/Pictures), and create a script file containing the following (change the ip address as appropriate, and be sure to chmod +x on the file):

> rsync -avz -e "ssh -p 10010" root@ phonepix

step 5: run it!  hope it works for you.  My phone is a galaxy nexus, yours may store the camera photos in a different location.  SSH in and find them, and edit accordingly.

I’d like to say you can sync your music and other documents in the same way, but it seems that that sync only works for download, not upload.  Some kind of permissions problem in android I suppose.  Perhaps another ssh server other than SSHDroid would do the trick for bidirectional sync.

GHC on bananapi/arch

I’m looking at switching over to Arch linux for the Cyclophone project, partly because ghc is more up to date on arch. ghci, the haskell interpreter, actually works on arch which is nice. ghci doesn’t work on raspian or other ARM distros I’ve tried. The ghc/ghci version on arch now is 7.8.2.

Unfortunately the version of LLVM (3.5.1) on arch is too new and breaks ghc when you actually try to compile something. The errors start with:

You are using a new version of LLVM that hasn't been tested yet!"

Followed by a lot of these:
Alias must point to a definition
i8* @"base_GHCziBase_DZCFunctor_static_info$alias"

Looks like this is a known problem, slated for fixing in ghc 7.10.x. Ticket is here.

Either I could compile 7.10 and go with that, or I could downgrade llvm. Seeing as there might be a lot of breaking changes in 7.10, I’d rather go 7.8.2, so downgrading it is.

The main package rollback website for Arch only addresses x86 architectures, not ARM. After inquiries on IRC (#archlinux-arm on freenode) I was directed here:

Ed: link above is toast. see comments below for download links.

And found a list of possible replacement packages for llvm and llvm-libs, both of which were installed on my system after adding ghc.

I decided to go with 3.4.2, so I got those onto my banana pi with wget:

> wget
> wget

Because its a banana pi, I want to use the armv7 packages – the armv6 stuff is for raspberry pi. You can verify that info on your system with:

> cat /proc/cpuinfo

Ok now with those packages located and downloaded, downgrading is simple:

> sudo pacman -U llvm-3.4.2-1.1-armv7h.pkg.tar.xz llvm-libs-3.4.2-1.1-armv7h.pkg.tar.xz

This replaced the existing llvm and llvm-libs packages without disturbing their dependencies, in my case ghc. After that the cyclophone main program, scoscdir, compiles without a hitch, and without the tweaks I’ve been adding to libs because of old ghc versions on raspian.

Get started with purescript on nixos

On nixos, installing the tools for purescript is a little different from how it is described in the Purescript by Example book (purchase link).  Until a few days ago I had to rely on a local copy of bower for each project, and before that there was a problem with the purescript haskell package.  However, that’s all been fixed, so getting purescript working on nixos is pretty straightforward now (2015-01-11) if you are on the unstable channel.

You can check what channel you’re on like this:

[bburdette@nixosthe1:~]$ sudo nix-channel --list
[sudo] password for bburdette:

If you aren’t on unstable, you can switch like this:

[bburdette@nixosthe1:~]$ sudo nix-channel --add nixos

Then you’ll want to do the usual updating, to 1) update the package registry, 2) rebuild packages according to the new stuff, and 3) (optional) upgrade any packages you’ve installed with “nix-env -i “.

1> sudo nix-channel –update
2> sudo nixos-rebuild switch
3> nix-env –upgrade

With that out of the way you can install purescript and friends:

> nix-env -i nodejs
> nix-env -iA nixos.pkgs.haskellPackages.purescript
> nix-env -i bin-grunt-cli
> nix-env -i bin-gulp
> nix-env -i bin-bower

I used -iA for purescript because various guesses for the regular name didn’t work for me.  You don’t need gulp for the book examples, but some projects on github use gulp.

You can install them all with one command like so:
> nix-env -iA nixos.pkgs.nodejs nixos.pkgs.haskellPackages.purescript nixos.pkgs.nodePackages.grunt-cli nixos.pkgs.nodePackages.gulp nixos.pkgs.nodePackages.bower

Great! Now you can clone the purescript code repo for the Purescript by Example book.

> git clone

Now let’s build and run the chapter 2 example, with these commands:

> cd purescript-book/chapter2
> npm update
> bower update
> grunt
> node dist/Main.js

The output from these commands looks like this:

[bburdette@nixosthe1:~/purescript-book/chapter2]$ npm update
grunt-purescript@0.5.3 node_modules/grunt-purescript
grunt@0.4.5 node_modules/grunt
├── which@1.0.8
├── dateformat@1.0.2-1.2.3
├── eventemitter2@0.4.14
├── getobject@0.1.0
├── rimraf@2.2.8
├── colors@0.6.2
├── async@0.1.22
├── grunt-legacy-util@0.2.0
├── hooker@0.2.3
├── exit@0.1.2
├── nopt@1.0.10 (abbrev@1.0.5)
├── lodash@0.9.2
├── coffee-script@1.3.3
├── underscore.string@2.2.1
├── iconv-lite@0.2.11
├── minimatch@0.2.14 (sigmund@1.0.0, lru-cache@2.5.0)
├── glob@3.1.21 (inherits@1.0.0, graceful-fs@1.2.3)
├── findup-sync@0.1.3 (glob@3.2.11, lodash@2.4.1)
├── grunt-legacy-log@0.1.1 (underscore.string@2.3.3, lodash@2.4.1)
└── js-yaml@2.0.5 (esprima@1.0.4, argparse@0.1.16)

[bburdette@nixosthe1:~/purescript-book/chapter2]$ bower update
bower purescript-math#0.1.0 cached git://
bower purescript-math#0.1.0 validate 0.1.0 against git://
bower purescript-math#0.1.0 install purescript-math#0.1.0

purescript-math#0.1.0 bower_components/purescript-math

[bburdette@nixosthe1:~/purescript-book/chapter2]$ grunt
Running "psc:all" (psc) task
>> Created file dist/Main.js.

Running "dotPsci:0" (dotPsci) task
>> Created .psci file

Done, without errors.

[bburdette@nixosthe1:~/purescript-book/chapter2]$ node dist/Main.js