I’ve been using Vim (Neovim to be precise) for a few months now, and I’m slowly progressing on unlearning using the mouse all the time. It turns out that 20+ years of computer use creates some sort of a habit.

I recently bought a RaspberryPI 3, which I had planned on using mainly for development and as an always on Internet device. Installing Neovim was not a problem (git clone ... > cd neovim > make && sudo make install), but completing the install of the YouCompleteMe plugin turned out to be a little trickier.

Installing YouCompleteMe

One of my favorite plugins is YouCompleteMe. Which I wanted to use in order to get good autocompletion when learning Go. The plugin installed correctly, using the awesome plugin manager Plug, but in order for the plugin to be useful - you also need to manually build the autocompletion library on your machine.

I’ve done this lots of times before, so I changed into the [Vim Plugins]/YouCompleteMe folder and ran the command ./install.py --gocode-completer, which started the build process. After about 20% progress, the build seemed to stop, and after a minute or so, the build crashed.

It turns out that the reason for this is that the plugin’s build system tries to be clever (never write clever software!) and checks the number of cores available on the system before triggering the build job.

Since the Raspberry PI 3 has four cores - a build job using 4 threads was started. This in itself is not a problem, but given the fact that the PI 3 only has 1gb of RAM (and we’re compiling C++ code) that memory was used up quickly. The delay before the final crash was due to the system using swap space on the SD card, due to no free memory.

The solution

The solution to this problem is really simple; don’t build the plugin using multiple threads. In order to control this, we can just use an environment variable, like this:

YCM_CORES=1 ./install.py --gocode-completer

This will builds the plugin using a single thread, which eliminates the memory problem. It also creates a great opportunity to go grab a cup of coffee, since the build will take a couple of minutes.

Alternative solution (unconfirmed)

This could probably have been solved by increasing the size of the swap space. But in this case the swap space was located on the SD card, which is really slow.