There were a couple of places I got caught up reading other people’s setups and seeing how they did things that didn’t necessarily work for me.
Custom 404 pages and permalinks
I was having trouble creating the 404.html at the root of my site, as per GitHub’s notes for a custom error page. Jekyll was converting my 404.html source file into _site/404/index.html.
This wasn’t working. In the end, I tracked it down to my use of a permalink setting of pretty in Jekyll’s _config.yml.
I fixed this by changing to a custom permalink setting of /:categories/:year/:title.html which I think is nicer anyway.
Makefile
I’m not a ruby or web dev guy by trade, and so I knew I’d forget what the commands were to do a test build of the blog. However, I do know Make. I’ve put the basic commands into a Makefile so they’re easy to run (and I’ll know where to look if I forget them).
Travis integration
I wanted to use Travis for continuous integration to get notified when the blog fails to build.
This is pretty easy, it’s just a matter of linking Travis to your GitHub profile, enabling your repo and then making the following changes to your repo.
Add the following file to your site repo in a file called .travis.yml:
This is enough to get Travis to try and build your site. However, it will likely not build. Travis will likely complain about errors (since it installs ruby gems into a custom vendor directory). The error I was seeing was:
ERROR: YOUR SITE COULD NOT BE BUILT:
------------------------------------
Post 0000-00-00-welcome-to-jekyll.markdown.erb does not have a valid date.
To fix this add the following line to your _config.yml:
Done! You can then embedded neat build notifiers around the place, like so:
It lets you write programs that you can get the compiler to execute at compile time. Here’s a basic example showing how to get the compiler to calculate the greatest common divisor of two numbers:
At first glance, this isn’t anything too interesting, until you realise the the value GCD<25, 60> is replaced with the calculated result and ends up as a static const int with a value of 25.
Moving on, this is a basic fibonacci generator that runs at compile time.
If you squint, it looks like templates can be used as functions, types as function arguments and fields (or typedefs) in the templated structure as your result.
With this in mind, think of how similar the previous code example looks when compared with the following Haskell code snippet:
Neat! They seem to line up fairly closely when looking at it this way.
The key to writing recursive templates like this is to use template specialisation as your base case to terminate the recursion. It’s like pattern matching in Haskell to determine which function definition to use.
Normally, you’d write the templates in a separate C++ header and then include them into the main program, so I’ll do that in the following examples.
Here’s a definition for an IF function in C++ templates:
Here, we’ve built a template with two specialisations, one for the IF clause and one for the ELSE clause. We’ve used typedefs to pick out the supplied clauses from the template arguments to determine the result.
In the next post in this series, I’ll extend these ideas into building lists with templates, and then doing interesting operations (map, reduce and sort) on them, all at compile time.
A little while ago Markus Persson, creator of Minecraft announced a new game he was proposing.
Part of the game’s initial specification was a preliminary description of a hypothetical CPU that could be used and programmed from inside the game, the D-CPU16. I wrote a basic emulater for D-CPU16 binaries based on that description, and it’s available on GitHub.
There have since been several new revisions of the D-CPU16 specifications that I’ve not kept up with, so it’s of limited use, but it was a fun project all the same.