How to speed up your vim startup time

My go-to editor for pretty much anything is vim. And like any serious vim user I use numerous plugins to extend and improve the editing experience. Natually there’s a cost to that, namely an increase in vim startup time. Compared to almost any GUI application vim starts up almost instantaneously. Still I noticed that slight delay and it had been bothering me for a while until I finally got round to investigate and tweak.

Thankfully vim makes profiling the startup time really convenient by providing a --startuptime flag to write timings for loading your .vimrc and plugins to a file, which looks something like this:

times in msec
 clock   self+sourced   self:  sourced script
 clock   elapsed:              other lines

000.007  000.007: --- VIM STARTING ---
002.399  002.392: Allocated generic buffers
002.468  000.069: locale set
004.946  002.478: GUI prepared
004.954  000.008: clipboard setup
004.967  000.013: window checked
016.181  011.214: inits 1
016.187  000.006: parsing arguments
016.188  000.001: expanding arguments
016.212  000.024: shell init
017.230  001.018: Termcap init
018.203  000.973: inits 2
018.390  000.187: init highlight
022.090  002.745  002.745: sourcing /usr/share/vim/vim74/debian.vim
026.679  000.296  000.296: sourcing /usr/share/vim/vim74/syntax/syncolor.vim
026.805  001.004  000.708: sourcing /usr/share/vim/vim74/syntax/synload.vim

The interesting measurements are those concerned with sourcing files, so focus your attention on the 3rd column to see where time is spent. Short of trimming down your vimrc (mine takes about 18ms to load by itself) and cutting down on the number of plugins, the plugin manager can also make a difference. I used pathogen for a long time, before switching to Vundle (because it’s easier to have your plugin manager handle Git repositories rather than having to manually add them as submodules to your dotfile repository or similar). Then I came across vim-plug and was intrigued by its on-demand loading feature. That allows loading plugins for specific file types or only on the first invocation of a certain command. The latter is particularly useful for plugins you don’t need to have active all the time. In my case this was particularly useful for NERDtree and DokuVimKi, which both take a significant time to load. Looking carefully at the startup time output I also noticed I was sourcing filetype plugins twice! The offending line in my vimrc was quickly found, which shaved off some additional milliseconds.

TL;DR Switching to vim-plug, getting rid of some unnecessary plugins, loading others only on demand and uncluttering my vimrc I managed to cut down my vim startup by more than half, from close to 250ms to only about 120ms.

Plotting Christmas gift tags using a Raspberry Pi and

On the first weekend of December, the fine folks from put on an Xmas IoT Hackathon at the London Fab Lab. The Fab Lab is a maker space for digital fabrication and rapid prototyping. They host classes and events (like hackathons) and members can use a variety of tools for wood and metal working as well as 3D printers and a laser cutter, which you can use e.g. to cut a gingerbread house like this one (made from real gingerbread!):

Gingerbread house

Appropriate to the occassion, the resin folks brought boxes full of hardware:


There was therefore no shortage of Raspberry Pis and all kinds of accessoires. Teams were formed and a range of exciting hacks started taking shape. I teamed up with Mark, a good friend and hackathon buddy, who had brought along a Graphtec Silhouette Portrait cutter/plotter which we were intending to hack:

Graphtec Silhouette Portrait

You’d normally use this to cut out shapes previously created with their proprietary software Silhouette Studio. Of course that’s only the intended use. Replacing the knife by a silver sharpie turns the Silhouette into an electronic circuit plotter - for very simple circuits. Here’s a proof-of-concept circuit used to power an LCD with a button cell:


Our plan was to the Silhouette into a Christmas gift tag plotter, powered by a Raspberry Pi. Using Silhouette Studio to drive the plotter was of course no option. We had to find a pure command line, open source solution to generate the template and feed it to the plotter which also needed to run on the ARM processor of the Pi. After some searching and experimenting we found a Python based driver, which after a little tweaking was able to digest a postscript file and get it plotted. Here are some experimental results:


We generated the gift tags using paper.js: The user puts in five names of friends to create tags for and we place the names, framed each by two automatically generated snowflakes, on a canvas and have paper.js save the canvas as SVG. Now there were only two pieces missing: one was converting from svg to postscript, which inkscape happily does for us, even on the command line. The final piece was then a simple node.js server to put everything together: A form to put the names in, which when submitted generates an SVG string, which is POSTed to the server, where it is saved to a file, converted to postscript via inkscape and then fed to the plotter. Job done! Well, almost, we still had to deploy it to the Pi.

Fortunately, a deployment service for IoT devices, makes that rather simple: you create an application on the dashboard, download the base image for your device, flash it on the SD card, pop it into the Pi and boot it. After a few minutes the device comes online at the dashboard. When you then push to the Git repository associated with the project, your new code is deployed on the Pi, heroku-style, but cooler (because of the blue unicorn and cause it run on your device!).

The device is provisioned via docker and provide a base container (based on Raspbian wheezy) that comes with node.js preinstalled. Python, git and inkscape are easily installed via the apt package manager and we simply git clone the graphtec driver. The container automatically runs npm install and when successful npm start to run our server. So far, so straightforward, but there were two small issues to figure out: one was installing the font we were using for the names and refreshing the font cache and the other was detecting the printer, which required starting udevd manually. Having that sorted, our first test was finally sucessful:

Gift tags

We had a really great weekend at the Fab Lab and even made the 2nd prize with our hack. Thanks to the folks for putting it on and hopefully until the next one!

How to update expired repository keys in Debian / Ubuntu

When using third party package repositories, you occassionally might need to update expired repository keys. An expired key leads to an error message during a sudo apt-get update similar to the following:

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used.
GPG error: raring Release:
The following signatures were invalid: KEYEXPIRED 1396011159 KEYEXPIRED 1396011159 KEYEXPIRED 1396011159

To find any expired repository keys and their IDs, use apt-key as follows:

apt-key list | grep expired

You will get a result similar to the following:

pub   4096R/BE1DB1F1 2011-03-29 [expired: 2014-03-28]

The key ID is the bit after the / i.e. BE1DB1F1 in this case.

To update the key, run

sudo apt-key adv --recv-keys --keyserver BE1DB1F1

The repository will then be updated with the next sudo apt-get update.

Taarifa reporting for International Medical Corps UK at hack4good London

On the weekend of 4-6th October I was part of #hack4good in London working with Chris Adams, Corinne Pritchard and Nick Stanton tackling multi-agency reporting at refugee camps for International Medical Corps UK with the Taarifa platform.

We approached the problem from two angles: One was developing a workflow for a paper-based reporting system, where report forms are automatically generated for a specific area like a refugee camp. Refugees would be able make a report by filling in the form themselves with the help of a simple iconography to overcome the language barrier, mark the location on a map and drop it into a collection box. The forms are machine readable and can be digitized in an automated process.

The other was the technical challenge of providing a platform that could process a variety of different reports that various agencies working at a refugee camp need to deal with from santiation over general feedback to sexual exploitation. These can be aggregated in one place by the Taarifa API which I’ve extended to be able to handle any report schema. Creating a new report type is a simple as sending a POST request describing the schema to the API in JSON format. Reports can then be submitted immediately via the JSON API or via an automatically generated web form. All of that is live and operational at

There was quite a bit of media coverage around #hack4good: Channel 4, SkyNews and a video of the London event by Big Bang Lab.

C pointers to multi-dimensional assumed shape Fortran arrays with gfortran

Interoperability between C and Fortran codes is often complicated by Fortran’s support for “true” multi-dimensional arrays. In addition, Fortran 90 supports assumed shape (also referred to as deferred shape) arrays, where the extent sizes are determined at runtime. Actual arguments for array dummy arguments can be array slices that may be of non-unit stride. In short, an assumed size Fortran array can reference non-contiguous chunks of memory.

Therefore, the compiler will reject an attempt to obtain a raw data pointer of a Fortran array to pass to a C function like in the following module:

gfortran 4.7 emits the following error message:

Error: Assumed-shape array 'v' at (1) cannot be an argument to the procedure 'c_loc' because it is not C interoperable

What if you know that the assumed-shaped array passed to your function is actually contiguous (or you choose to leave it the caller’s responsibility)? Surely the compiler should be able to give you a pointer to the first array element like so:

Turns out gfortran doesn’t and generates the same error as before. The gfortran developers have recognized this as a bug, which will be fixed in the 4.9 release.

In the meantime you can work around it by defining a pure function that simply returns the first argument of an assumed shape array. gfortran is happy with that since now the type of the argument passed to c_loc is a scalar and therefore interoperable:

However, this workaround confuses Intel’s and PGI’s Fortran compilers, so simply escape it using the a preprocessor #define: