Travis build 58 on Fri Dec 18 00:41:30 UTC 2015

Author: Hodapp87

atom.xml

@@ -52,7 +52,7 @@
 
 cabal sandbox init
 cabal --with-ghc=arm-unknown-linux-gnueabihf-ghc --with-ghc-pkg=arm-unknown-linux-gnueabihf-ghc-pkg --with-ld=arm-linux-gnueabihf-ld --with-strip=arm-linux-gnueabihf-strip install</code></pre>
-<p>Which is <em>AWESOME</em> because the native compiler is <em>so</em> much faster than the one emulated with QEMU. This is not without caveats, though. For instance when compiling with multiple jobs it took forever and then ran out of memory, setting <code>-j1</code> fixed this.</p>
+<p>Which is <em>AWESOME</em> because the native compiler is <em>so</em> much faster than the one emulated with QEMU. This is not without caveats. For instance when compiling with multiple jobs it took forever and then ran out of memory, setting <code>-j1</code> with <code>cabal install</code> fixed this particular issue.</p>
 <p>A bigger problem is that there appears to be issues with the C FFI. I’m not yet sure how this works, but when I try to run an ARM binary which uses JuicyPixels to write a PNG (which relies upon zlib), I get this error:</p>
 <pre><code>user error (Codec.Compression.Zlib: incompatible zlib version)</code></pre>
 <p>but otherwise this works surprisingly well.</p>

posts/2015-12-15-arm.html

@@ -87,7 +87,7 @@ <h2 id="cross-compilation-with-qemu">Cross-Compilation with QEMU</h2>
 
 cabal sandbox init
 cabal --with-ghc=arm-unknown-linux-gnueabihf-ghc --with-ghc-pkg=arm-unknown-linux-gnueabihf-ghc-pkg --with-ld=arm-linux-gnueabihf-ld --with-strip=arm-linux-gnueabihf-strip install</code></pre>
-<p>Which is <em>AWESOME</em> because the native compiler is <em>so</em> much faster than the one emulated with QEMU. This is not without caveats, though. For instance when compiling with multiple jobs it took forever and then ran out of memory, setting <code>-j1</code> fixed this.</p>
+<p>Which is <em>AWESOME</em> because the native compiler is <em>so</em> much faster than the one emulated with QEMU. This is not without caveats. For instance when compiling with multiple jobs it took forever and then ran out of memory, setting <code>-j1</code> with <code>cabal install</code> fixed this particular issue.</p>
 <p>A bigger problem is that there appears to be issues with the C FFI. I’m not yet sure how this works, but when I try to run an ARM binary which uses JuicyPixels to write a PNG (which relies upon zlib), I get this error:</p>
 <pre><code>user error (Codec.Compression.Zlib: incompatible zlib version)</code></pre>
 <p>but otherwise this works surprisingly well.</p>

rss.xml

@@ -48,7 +48,7 @@
 
 cabal sandbox init
 cabal --with-ghc=arm-unknown-linux-gnueabihf-ghc --with-ghc-pkg=arm-unknown-linux-gnueabihf-ghc-pkg --with-ld=arm-linux-gnueabihf-ld --with-strip=arm-linux-gnueabihf-strip install</code></pre>
-<p>Which is <em>AWESOME</em> because the native compiler is <em>so</em> much faster than the one emulated with QEMU. This is not without caveats, though. For instance when compiling with multiple jobs it took forever and then ran out of memory, setting <code>-j1</code> fixed this.</p>
+<p>Which is <em>AWESOME</em> because the native compiler is <em>so</em> much faster than the one emulated with QEMU. This is not without caveats. For instance when compiling with multiple jobs it took forever and then ran out of memory, setting <code>-j1</code> with <code>cabal install</code> fixed this particular issue.</p>
 <p>A bigger problem is that there appears to be issues with the C FFI. I’m not yet sure how this works, but when I try to run an ARM binary which uses JuicyPixels to write a PNG (which relies upon zlib), I get this error:</p>
 <pre><code>user error (Codec.Compression.Zlib: incompatible zlib version)</code></pre>
 <p>but otherwise this works surprisingly well.</p>