Announcing CLI11 Version 1.0

CLI11, a powerful library for writing command line interfaces in C++11, has just been released. There are no requirements beyond C++11 support (and even <regex> support not required). It works on Mac, Linux, and Windows, and has 100% test coverage on all three systems. You can simply drop in a single header file (CLI11.hpp available in releases) to use CLI11 in your own application. Other ways to integrate it into a build system are listed in the README.

Lua Environment Modules

This is a guide to setting up Lmod (lua environment modules) on a CentOS system. I’ve used a similar procedure to set them up on a Mac, as well, so this is still a useful guide to the workings of Lmod if you use a different system; mostly paths will change. On a Mac, you’ll want to install Lmod from the science tap in brew.

There are several good pages covering environment modules (TCL version), but not many that use the newer Lua syntax. This document aims to fill that roll.

Setting up environment modules

Note: please use Lmod instead. It is a newer project that is backward compatible, but also makes some nice improvements. It is used on many supercomputer systems. See my next article.

The environment modules project is an ideal way to set up (albeit mostly manually) your environment for multiple packages. This is a quick guide on setting it up.

First, install the environment-modules (CentOS) package with yum. You’ll also need to initialize it in the bashrc file, I chose to add source /usr/share/Modules/init/bash (and optionally bash_completion) to /etc/bashrc instead of running /usr/share/Modules/bin/add.modules, but if you only want it locally, that’s also an option.

To set up a module file, you want something like this, for example /usr/share/Modules/modulefiles/cuda/8.0:

#%Module1.0
proc ModulesHelp { } {
        global version prefix name
        puts stderr "$name/$version - loads the environment for $name, in $prefix"
}

set     name      cuda
set     version   8.0

module-whatis   "loads the $name environment"

set prefix /usr/local/cuda-$version

prepend-path     LD_LIBRARY_PATH     $prefix/lib64
prepend-path     PATH                $prefix/bin

You can generate the meat of this file by doing, for example for ROOT:

/usr/share/Modules/bin/createmodule.py /opt/root-6.08.02/bin/thisroot.sh > /usr/share/Modules/modulefiles/root/6.08.02

You can remove most or all the default modules - and yes you’ll need to make modules for each package. The “spider” search does not seem to be in the standard modules package.

Note: I used http://dillinger.io to generate the this page.

Making a Plumbum Autoload Extension for IPython

I recently decided to try my hand at making an auto-load extension for Python and plumbum. I was planning to suggest it as a new feature, then I thought it might be an experimental feature, and now it's just a blog post. But it was an interesting idea and didn't seem to be well documented process on the web. So, here it is.

The plan was to make commands like this:

>>> from plumbum.cmd import echo
>>> echo("This is echoed!")

or

>>> from plumbum import local
>>> echo = local['echo']
>>> echo("This is echoed!")

into this:

>>> echo("This is echoed!")

Thereby making Plumbum even more like Bash for fast scripting.

Plumbum Color

I've been working on a color addition to Plumbum for a little while, and I'd like to share the basics of using it with you now. This library was originally built around a special str subclass, but now is built on the new Styles representation and is far more powerful than the first implementation. It safely does nothing if you do not have a color-compatible systems (posix + tty currently), but can be forced if need be. It is included with Plumbum, so you don't have to add a requirement for your scripts that is non-essential (as color often is). It is integrated with plumbum.cli, too. Also, I've managed to accelerate the color selection algorithims about 8x, allowing near game-like speeds. (see the fullcolor.py example).

Plumbum Scripting

Scripting in Bash is a pain. Bash can do almost anything, and is unbeatable for small scripts, but it struggles when scaling up to doing anything close to a real world scripting problem. Python is a natural choice, especially for the scientist who already is using it for analysis. But, it's much harder to do basic tasks in Python. So you are left with scripts starting out as Bash scripts, and then becoming a mess, then being (usually poorly) ported to Python, or even worse, being run by a Python script. I've seen countless Python scripts that run Bash scripts that run real programs. I've even written one or two. It's not pretty.

I recently came (back) across a really powerful library for doing efficient command line scripts in Python. It contains a set of tools that makes the four (five with color) main tasks of command line scripts simple and powerful. I will also go over the one main drawback of the library (and the possible enhancement!).