In any larger project that needs subdirectories, it is important to have a consistent way to locate files. Paths relative to the project root make sense, but in R, the current working directory cannot be always assumed to be the project root (think vignettes and tests).

Introducing rprojroot:

# Find the root of an R package, identified by a DESCRIPTION file

## [1] "/path/to/your/package/root"

This works no matter what your current working directory is, as long as it is somewhere below the project root. Promised.

Interested? There's more to it, check out the vignette or the online package documentation.

Largely inspired by the post Stop the working directory insanity by Jennifer Bryan, and of course by Git.

This is a short HOWTO for testing a package with wercker CI, a Docker-based continuous integration service.

CAVEAT: Currently, wercker requires far too many GitHub permissions. The people at wercker are aware of the problem, let's hope for the best. Don't use the service if you feel uncomfortable giving full access to your GitHub repositories (public and private) to wercker.

Comparison to Travis CI

  • It's faster: Initialization and teardown of tests in just under 30 seconds, because the expensive installation of dependent packages is carried out when building the Docker container

  • Images of failing builds can be downloaded and inspected

  • Builds can be run locally under exactly the same environment via the wercker build command

  • Custom base images that suit your needs

  • Better separation of logs in the web view

Adapt your package

  1. Install makeR in your package, use it to add a wercker.yml:

    curl | sh;
    make init-wercker;
    make init-gh-pages;
    make init-staticdocs;
    make dt_test;
  2. Use Authors@R in DESCRIPTION

    • Current R forbids the use of as.person() in Authors@R, use a construct like person("Kirill", "Müller", role = c("ctb", "cre"), email = "")
  3. Add URLs to DESCRIPTION like this:


Some GUI work with wercker

  1. Create a new application

    • Use "wercker will checkout the code without using an SSH key" in step 4 ("Configure access")
    • Keep "Docker" checked in step 5, ignore the proposed wercker.yml
    • Consider opting out of sharing the project in step 6 for security reasons (if not, carefully check log output for leaked private variables and keys)
  2. Set up GitHub Pages

    • Generate a new key pair, name does not matter, e.g. deploy_ssh
    • Copy it to clipboard
    • Add a deploy target "GitHub-Pages"
      • Choose auto-deploy as desired
      • Add a new "variable", your SSH key pair, name DEPLOY_SSH
      • Save
    • Head over to the GitHub repository (icon at the top right)
      • Settings
      • Deploy keys
      • Add your key from the clipboard, name does not matter, e.g. wercker
      • Allow push access for the key
  3. Set up codecov

    • Add your repository
    • Copy your token
    • In your wercker settings, hit Add new variable
      • Name: CODECOV_TOKEN
      • Value: (as copied from codecov)
      • make it protected
      • save
  4. Start the build

    git push

Badge your

  1. Get your badge from wercker (there seems to be no way to infer the badge URL)

    • don't forget to select "Master"
  2. codecov uses repo user and name (but twice):


Some GUI work on GitHub

  1. Add the link to your package's GitHub Pages to the description of your repo

Many software projects feature a NEWS (or ChangeLog) file where the most important changes are documented. One way of maintaining such a file is to request an entry for each contribution. However, this bears potential for merge conflicts: Two separate contributions will then change the NEWS file in the same place and thus are incompatible.

Are they really?

In Git, there are three built-in merge drivers:

  • text for text files: Will merge non-conflicting changes and introduce the notorious conflict markers <<<<<<<, ======= and >>>>>>> for conflicting changes
  • binary for binary files: Will prefer "our" contents and mark the file as conflicted
  • union for text files: Will append lines introduced by conflicting changes in a random order

Normally, the text or binary driver is used, depending on the file type. For the NEWS file, the union driver would be ideal. It is possible to specify a merge driver for each file in the repository (wildcards allowed). This is done by adding an entry to the .gitattributes file in the root of the repository, in our case

/NEWS merge=union

Create the file if it does not exist. Here, /NEWS is the absolute path of the NEWS file in the repository. Don't forget to commit this file to the repository. After that, entries added to the NEWS file by different branches all appear in the resulting file after merging, ready for being sorted just before the release.

I have prepared a small demo on GitHub. It seems that this feature has been around forever, but it is not as widely known as, say, the .gitignore file.

One more hint: If new items are added to the top of the NEWS file, the order of the entries will match the (reverse) order in which the branches are merged.

Can I start a GUI application from inside GNU Screen?

You can't. Well... At least, you have to set DISPLAY before invoking it.

When I disconnect and reconnect, will it still be there?

No, of course not!

Right, but... wrong. This post describes how to answer "Yes" to the two questions above.


If you run long tasks or work with multiple shells on a remote Linux/Unix server, GNU Screen is your friend. It is a virtual terminal multiplexer that will continue running all your shells and all the processes started by them even if you disconnect, and of course allow reconnecting later. Unfortunately, this tool has one drawback: All subprocesses will inherit the environment at the time Screen was first started, even after disconnecting and reconnecting. This means that you cannot automatically launch applications with a GUI in a reconnected Screen session, even if you enable X forwarding with ssh -X: The DISPLAY environment will probably be wrong. Of course you can note the value of DISPLAY right after ssh -X, and start your GUI applications using DISPLAY=:### my-gui-app -- but that's very inconvenient. In addition, even if Screen survives a disconnect, the GUI application won't -- the target display must run at least as long as the application runs, or the application will terminate. Another option is to log in separately using ssh -X for each GUI application and start it outside Screen -- this is inconvenient if a GUI application needs to be started from a specific directory (say, a version control front-end or a visual diff tool).

That's where xpra comes to play -- "Screen for X". It provides and maintains an Xvfb-based virtual framebuffer on the server to which applications can connect, this framebuffer is intended to run indefinitely. Xpra clients can then connect to the xpra server instance and display the contents of the virtual framebuffer on the local display, forward input events, ... -- in other words, let the user interact with the application as if it runs on the local machine. Once disconnected, another connection can be made to the same xpra session -- this is transparent to GUI applications using xpra as display, these applications simply continue running. The value of DISPLAY (and its lifetime) remains unchanged for the entire duration of the xpra session.

This post describes the installation of xpra and GNU Screen on a Debian/Ubuntu Linux server and client, with the following features:

  • Login on the server via SSH by default reattaches to a running Screen. If no Screen is running, a new instance is started and xpra is set up in that instance.

  • Applications with a GUI can be started from within Screen, and keep running even if the client disconnects. Several GUI applications can be run in parallel. They are shown on the client's display by issuing a special command once.

  • Multi-user support.

It is assumed that usernames match on both local and remote systems. If this is not the case, some tweaking might be necessary -- YMMV. Some knowledge of Screen is assumed, too.

Tested with xpra 0.9.6 (server, Debian Squeeze) and xpra 0.9.8 (client, Ubuntu 13.04). In principle, the configuration should also work on other Linux flavors.


Server and client

  • Add the winswitch repository according to the instructions. (This used to be a bad idea, but should now work fine.)

  • Install xpra: sudo apt-get install xpra.

Server only

  • Install GNU Screen: sudo apt-get install screen


Server: Auto-start Screen

The script below needs to be added to or sourced from your ~/.profile. It is a modified version of this script. The main changes are:

  • If no running Screen is found, the DISPLAY environment variable is set to the first free display with number larger than 5555. (This is to avoid confusion with system display numbers.) Free display numbers are discovered by looking into /tmp/.X11-unix/ for files named X*. The DISPLAY environment variable will be inherited by the screen instance which is started next, and thus also by all processes started inside this Screen. (There is a race condition here: Two simultaneous logins from the same user will set DISPLAY to identical values, and one instance of xpra will fail to attach to that display.)

  • If the DISPLAY environment variable is already set, the auto-start feature is disabled. This happens, for instance, if you use ssh -X to login to the remote machine.

  • The window title is set to $HOSTNAME.

Test this by sshing into your remote machine with and without the -X switch. In the latter case, Screen should be started automatically (if no instance was running previously), in the former case you'll be getting a simple prompt. If you cannot distinguish the former from the latter, you can customize the appearance of Screen (e.g., add a permanently visible status line) by editing your ~/.screenrc file. There are plenty of examples on the web. (You'll need to edit that file anyway, see below.) Close the auto-started Screen, this will also close your SSH connection.

Server: Patch xpra configuration

The following is necessary if your home on the server runs on a file system that does not support sockets. Add this one setting to your ~/.xpra/xpra.conf configuration file (not /etc/xpra/xpra.conf, thanks antoine!). Replace the string username by your own user name on the local machine.

Once variable expansion is implemented, you can indeed also edit /etc/xpra/xpra.conf and define a generic per-user socket-dir.

Server: Patch Screen configuration

The following lines need to be added to your ~/.screenrc on the server. (Create the file if it does not exist.) It will start an instance of xpra that uses the preconfigured DISPLAY in Screen window 9. (Even if xpra were able to choose the DISPLAY itself, we could not let it do so because screen, the parent process, needs to know the value of DISPLAY.)

Test this by sshing into the remote machine again. Now, window 9 should contain logging information from xpra.

Client: Connecting to the server

The final piece is the command that needs to be run on the client to connect to a remote xpra session:

This will attach to your (only) xpra session running on the server, and works even with a changed socket dir thanks to the changed xpra configuration. This command must keep running as long as you want to use GUI applications on the remote machine.

Test this by starting a GUI application from inside the remote Screen.

Client: Connector script

We can wrap this with a script that will also set the window title and accept the host name or address as parameter:

Add or link this script to some location in your PATH.


Watch out for lonely Xvfb processes using pstree $USER, sometimes killing xpra doesn't kill the associated virtual framebuffer.

Further steps

It's only a bit of configuration, but I understand that coupling xpra with an auto-started Screen might not suit everyone's needs. Packaging this into a small application that works similarly to keychain (a script that determines the current state, starts xpra as daemon if necessary and creates sourceable files which are then sourced from .bashrc) would be a logical next step.

I decided to adapt to the Swiss German keyboard layout, partly because my new notebook has one and the replacement (German-German) layout is expensive, partly because I have been told that the brackets and braces are at a very convenient location (Alt Gr+keys close to the Return key vs. Alt Gr+digits on the German keyboard).

The ß letter, not commonly used in Switzerland, is not available on this keyboard layout. In Ubuntu, it can be accessed simply by Alt Gr + s. However, in Windows, the ß letter cannot be easily accessed -- various forums suggest typing Alt + 0223. That's too much for one single letter.

The solution: Create a custom keyboard driver! What seems to be a difficult task is in fact a very simple one thanks to Microsoft's Keyboard Layout Creator. Download, install, open the default Swiss German layout, edit the Alt Gr layer to produce an ß when hitting s, verify, choose a name for the new layout, build, done. The result is an .msi file for every architecture (AMD64, x86) that can be installed in order to make the layout available on the target system.

Screenshot of enhanced keyboard layout in the Keyboard Layout Creator

For myself, I have copied most of Ubuntu's Alt Gr layer. However, I am reluctant to posting my own keyboard drivers because I am not at all sure about copyright restrictions of the original keyboard layout which has been used to create the customized one.