One of Git’s killer features is interactive rebase. After choosing a range of commits and rebasing them interactively with

git rebase -i HEAD~10

you can re-order, edit, drop and squash commits, simply by fiddling with the list of commits pasted into your favorite editor. Some actions are easily done in Vim (e.g. deleting or moving lines), others require writing whatever you intend to do with the commit. Because I squash a lot, I became tired of typing ^cws over and over again and finally sat down to write this stupid little filetype plugin:

function RebaseActionToggle()
    let line = getline(".")
    let result = matchstr(line, "^\\a")
    let transitions = {'p': 'squash', 's': 'edit', 'e': 'fixup', 'f': 'pick'}
    execute "normal! ^cw" . transitions[result]
endfunction

noremap <Cr> :call RebaseActionToggle()<Cr>

If you save it as gitrebase.vim in .vim/after/ftplugin, you can cycle through the different rebase actions by pressing Enter:

Have fun with that.

No, not only because it’s “social coding” done right. But because the ecosphere around GitHub is alive and thriving. We have Travis CI to build around the clock. We have Read the Docs to re-generate Sphinx documentation on each push. We have Coveralls.io to check the test coverage and we will have gitter to have instant, per-repo support chat.

Yes everything is in the “cloud” and yes I could setup local alternatives. But I don’t want to care about infrastructure. I want to churn out commit after commit. Thanks everyone for making that a slick experience.

CMake, the software build system, describes itself as:

Welcome to CMake, the cross-platform, open-source build system. CMake is a family of tools designed to build, test and package software.

However, CMake cannot keep its promises and fails with respect to packaging¹. Writing software with CMake that builds everywhere is possible but in some cases not very easy and, although CMake provides its own packaging mechanism called CPack, it can only serve as a temporary solution.

The main problem on UNIX-like systems is the amount of freedom concerning installation paths. There are no guidelines where things have to go and how the paths are set up. Yes, CMake allows you to set the installation prefix by using

cmake . -DCMAKE_INSTALL_PREFIX=/usr

however, this is not enough to cover all cases. For example, the location of a 64-bit library is /usr/lib on Debian systems and /usr/lib64 on openSUSE systems. In an autotools-based system, you would just set --libdir to the appropriate location. Not so with CMake. People write all kinds of gruesome hacks to figure this out at build time much to mental state of package maintainers. Moreover, even if one user gets this whole mess right, a thousand others won’t.

To fix this problem for my own software systems, I wrote the ConfigurePaths module which would be used like this:

include(ConfigurePaths)

configure_paths(FOO)

Simple, eh? With this call, you populated your global CMake namespace with cached path variables that mimic the system variables known from configure scripts:

# header files
install(FILES bar.h
        DESTINATION ${FOO_INCLUDEDIR})

# libraries
install(TARGETS bar
        LIBRARY DESTINATION ${FOO_LIBDIR})

# binaries
install(TARGETS baruser
        RUNTIME DESTINATION ${FOO_BINDIR})

# pkg-config
install(FILES bar.pc
        DESTINATION ${FOO_PKGCONFIGDIR})

# ...

By default, all variables are set to the configure defaults, e.g. FOO_PREFIX is /usr/local, FOO_DATADIR is FOO_PREFIX/share, and so on. The user can override the default values by CMake means, for example:

$ cmake . -DPREFIX=/opt -DLIBDIR=/usr/lib64

Rather than convincing you to use this, I really just want to encourage you to think about the whole mess. In the end, it may turn out that you have to package the software yourself.

Today was the last day of a workshop organized by the KSETA grad school. It’s an interdisclipinary grad school focused mainly towards theoretical and experimental physicists but also enrolls engineering and computing students. All participants had to prepare an introductional tutorial-like talk either about some technology or something related to their day-to-day work.

I decided for the first option and gave two talks: one on Git, the other on OpenCL. My main goal was to tell everyone, how these tools can make life easier and that these technologies are nothing to be scared off. Both talks were aimed at total beginners and – still to my own surprise – well received.

If you want to use, extend or otherwise redistribute the content, you are free to do so. Both slide sets are hereby published under CC-BY-SA-3.0 with their sources available here and here. Note, that you probably have to adjust the theme and maybe also the font, if you do not like Adobe’s Source Sans Pro.