Due to a lot of traveling in September, I wan’t able to write the August update in September. So what happened in the last two month?
For the cross compilation pipeline through the
llvm-ng, I’ve added binary serializability of
cmm to a custom
ghc fork, that allows to dump the
cmm representation. This is helpful as it allows the decoupeling from the code generator and the ghc front end. What usually happens is that ghc reads a file, parses it turns it into an AST, desuguares it, runs a set of optimizations and finally turns it into STG before turning…
In July I’ve been playing around a bit more with
-target. At this point I believe the best solution is to have a minimal
ghc that doesn’t ship with any libraries; and all libraries are built on demand per target. We will likely want to pre-build and ship the Runtime System Library
rts as we do not have a cabal package that would just build the
rts. You’d have to specify the targets for which you want to build/include the
This post will be quite brief. I wasn’t able to carve out much time in June as my wife an I have just welcomed a new human being.
As the 8.6.1 alpha was just announced, I’m trying to finish adapting the
llvm-ng backend as quickly as I can and build a fresh set of pre-built ghc 8.6.1 cross compilers.
With GHC 8.6.1 being released soon, the windows for patches was closing fast. While not necessarily cross compilation related, I was still able to get a patch in the infamous load command size limit issue on macOS.
Interestingly windows suffers from a similar issue. On windows we have a command argument size limit of 32k character from Windows 7 onwards. Cabals (and to that extend also Stacks, and all other tools that use
Setup.hs) tendency to put libraries into their own folders results in one library search path per library. Thus once you have accumulated enough dependencies in your transitive…
Due to some travel in April, I wasn’t able to write up an update for what happened in March. So today we’ll have a combined update for March and April.
I have been making progress on the Windows front to the point where we don’t even need a windows installation anymore, and run the iserv slave via WINE. More on that soon!
At the haskell.sg March Meetup I gave a short presentation on how to cross compile dhall-json to raspberry pi, and the issues you might run into. I wanted to show that it is possible to cross compile non-trivial Haskell packages today, and that issues (ghc-head,
build-type, and Template Haskell) have mostly trivial fixes of which most can in principle be upsteamed.
The talk coincided with the release of GHC 8.4, and the release of a new
zlib package to hackage, which renders the need to fix
While I didn’t manage to find the time to write anything here in February, I did make some progress on the cross compilation front.
cabal can now be invoked outside of the source folder, and tries to not pollute the source tree with generated files anymore (haskell/cabal#4874). The
--with-PROG flag is now properly respected when using
new-build; this allows
new-build to work with cross compilers (haskell/cabal#5018). I’ve also spent quite some time to get cabals CI back into shape, which was hitting a rather obscure bug (haskell/cabal#5132).
I’ve also started working for IOHK where I will be assisting the DevOps…
After setting up hackage.mobilehaskell.org with S3 and fastly backing in December, I automated the overlay generation in January. This means that any patches pushed to the overlay repository will be automatically reflected in the overlay after a few minutes. Now all that’s missing is patches for common packages!
I’ve also managed to write a patch for
cabal so that
new-build properly propagates
--with-PROG flags into dependencies. This should make it work much better for cross compilation, once the patch is merged. I’m hopeful this will happen soon.
Finally I’ve argued for the use (and improved) overlays in the SLURP and Uncurated Hackage Layer proposals, because I believe overlays are an underused feature that could provide us with solutions to the perceived problems (as I understand them) and offer a unified interface.
Nix is a purely functional package manager and NixOS is a purely functional Linux distribution. I have been running a NixOS server for a while now, and been quite happy with the configuration. However updating it has essentially been copying the
configuration.nix file over and calling
nixos-rebuild switch --upgrade. This builds packages that are not in the cache on the server. NixOps is the NixOS cloud deployment tool and I should be able to use it to provision the server. Specifically using NixOps on macOS seems to be rather uncommon. …
At the haskell.sg January Meetup I presented building Android apps with Haskell yesterday. As we have recordings set up for a while now, you can follow it below. The talk is rather short and will only outline how to install the cross compilers, setup an Android app and call Haskell from Kotlin to display “Hello from Haskell”. It should hopefully provide a good starting point to start playing with the cross compilers.
The source code for the sample application can be found on github.
making mobile haskell awesome!