xmonad Per-Layout Keybindings

In xmonad it can be useful to have different keybindings for different layouts, or respond to other events differently depending on the active layout. This can be accomplished by looking up the active layout in the hook. For this we define a utility function:

import XMonad
import qualified XMonad.StackSet as S

-- Get the name of the active layout.
getActiveLayoutDescription :: X String
getActiveLayoutDescription = do
    workspaces <- gets windowset
    return $ description . S.layout . S.workspace . S.current $ workspaces

We can use this function in keybindings as follows. Here I’m using the BinarySpacePartition layout, and my other layouts are based on Tall. Depending on whether I have BSP active or not, I send different messages.

-- ...

import XMonad.Layout.BinarySpacePartition

myKeys = [ ((mod4Mask .|. shiftMask, xK_l), do
            layout <- getActiveLayoutDescription
            case layout of
                "BSP" -> sendMessage $ ExpandTowards R
                _     -> sendMessage Expand
           )
         , ((mod4Mask .|. shiftMask, xK_h), do
            layout <- getActiveLayoutDescription
            case layout of
                "BSP" -> sendMessage $ ExpandTowards L
                _     -> sendMessage Shrink
           )
         ]

Note that you can give your layouts custom names through Renamed.

Granting Capabilities Using capsh

On Linux it sometimes is useful to grant privileged capabilities to binaries without running them as root. Usually this is achieved by setting capabilities on the file through setcap. However, this has some complications with environment variables and capabilities inheritance of child processes. We can use capsh instead of setcap to achieve what we want using ambient capabilities.

Continue reading “Granting Capabilities Using capsh”

Using Nix to Create R Virtual Environments

Previously we saw how to use Nix to create virtual environments for Python. We can do the same for R. This means we can have different simultaneous R installations for different projects and keep the installed packages for each project separated. An important benefit of this is the ability to have different (incompatible) versions of the same packages for different projects.

The straightforward approach is to let Nix handle all R package management. However, sometimes it is useful to manage packages through the various R tools such as the built-in install.packages or install utilities provided by the devtools package.

R looks for installed packages in the R library directories, of which there are two types: the system library and the user library. By default these package management tools install packages in the first-specified user library directory. The user library directories can be specified through the R_LIBS_USER environment variable. We can use Nix to specify a unique library directory per project.

For example, create a nix.shell in your project root as follows:

with import <nixpkgs> {};
let
  my-r = rWrapper.override {
    packages = with rPackages; [ 
      ggplot2
      plyr
      tidyr
      devtools
    ];
  };
in  
  pkgs.mkShell {
    buildInputs = [
      bashInteractive
      my-r
    ];
    shellHook = ''
      mkdir -p "$(pwd)/_libs"
      export R_LIBS_USER="$(pwd)/_libs"
    '';
  }

Activate it in your shell by running $ nix-shell.

This makes available R with ggplot, plyr, tidyr and devtools. It creates a subdirectory in your project root, _libs, where the project’s R user library is located.

Using Nix to Create Python Virtual Environments

Nix and Python logos

Nix is a great tool to set up development environments. It allows us to have simultaneous installations of various versions of tools—such as Python—required for our projects. This means Nix makes it easy to have Python 2.7 installed for one project, and Python 3.6 for another. Projects using the same Python version can have different Python packages.

Of course, Python’s VirtualEnv also enables us to do this. Nix, however, is more powerful. It can handle all our system’s packages; not just Python’s. This means it enables us to hold different versions of any dependency. For example, if one project requires a specific version of OpenCL and another project requires an incompatible version, VirtualEnv won’t help us. Nix will.

There are many Python packages, and to install one such package through Nix requires it to be available in the Nix package repository. Understandably, not all Python packages are packaged for Nix—and those that are, often are not the newest version, nor at some other specific version we require.

We can use Nix to provision a Python environment for our project that works similarly to VirtualEnv’s. We can then use pip to handle such per-project Python dependencies, allowing us to grab Python packages directly from the regular Python package repositories without going through Nix. This also allows us to quickly get to work with others’ Python projects that are not set up to work with Nix.

Continue reading “Using Nix to Create Python Virtual Environments”

Closed-Form Rocket Fuel Requirements

Previously we calculated the fuel requirements of rockets to reach escape velocity. In that calculation, we did not take into account the effect of gravity during the fuel burn and underestimated the fuel requirements. We improved on this through a simulation better approximating reality. This simulation takes into account the force of gravity during the burn, as well as that force weakening as the rocket increases its distance from Earth, and takes into account the necessary escape velocity decreasing as the rocket’s distance to Earth grows. On this second post, Basker V commented that a closed-form solution can be found when the burn time is sufficiently small, allowing the rocket’s distance to Earth to be considered constant during the burn. In effect, this enables us to ignore both the diminishing force of gravity and decreasing escape velocity. Let’s find this closed-form.

Continue reading “Closed-Form Rocket Fuel Requirements”

&SPL – Creating a simple imperative programming language

[bibshow file=spl.bib sort=firstauthor order=asc]

SPL sample code

&SPL is an acronym for Simple Programming Language, and is a C-like imperative programming language, with classes, lists, and tuples. For example, the following code produces the Fibonacci sequence.

#include "stdlib/std.spl"

// Output the Fibonacci sequence
main ()
{
    var t1 = 0;
    var t2 = 1;

    while(True) {
        println(t2);
        var h = t1 + t2;
        t1 = t2;
        t2 = h;
    }
}

The language is formally defined with a context-free grammar and typing rules. In this post an implementation of an &SPL source code compiler implemented in Haskell will be discussed. The compiler compiles the source code into assembly for a Simple Stack Machine [bibcite key=SSM] (http://www.staff.science.uu.nl/~dijks106/SSM/) in a four-part process of lexing, parsing, typing and code generation. The source code is available on GitHub.

Continue reading “&SPL – Creating a simple imperative programming language”

Creating Multiple Custom User Types Through Inheritance in Django

Django Logo

When developing applications in Django, the need might arise to customize the user model. Specifically, you might want to create different types of users. In my case, I’m interested in creating a person user and a kit user. A person user can own multiple kit users, and both need to be able to authenticate to access an API. Luckily, Django’s authentication system is very flexible, and there are multiple ways to achieve this goal.

The standard way to implement this is to stick with the default user model, django.contrib.auth.models.User, and create a complex user profile. The profile adds the desired fields and behaviors for the various user types in a new model, and links to the model through a field reference. This can get fairly complex quickly. It is especially difficult to express ownership of kits by users, without allowing ownership of users by users. Here, we will see how we can implement this using inheritance. The code samples are for Django 1.11.

Continue reading “Creating Multiple Custom User Types Through Inheritance in Django”

ASUS PCE-AC68 Blue Screen of Death

Since building a new computer, my Windows 10 installation would sometimes crash. The error reported on the blue screen of death would always be page fault in nonpaged area. Interestingly, the system would be fine for months and then suddenly crash a few times per day — always when using Deluge, a torrent client. After some testing, it turned out that downloading a torrent with Deluge would reliably crash the system within an hour.

Debugging the crash minidump with Windows Debugger (WinDBG), it turned out the driver bcmwl63a was likely at fault. This driver is developed by Broadcom for 802.11 wireless network adapters. The driver was being used for my ASUS PCE-AC68 network adapter.

I was using version 7.35.338.0 of the Broadcom drivers for the adapter, supplied through the ASUS product utility version 2.1.1.5 that is available on the ASUS support website. The issue can be fixed by upgrading to versionĀ 7.35.351.0 of the Broadcom drivers, which ASUS supplies in version 2.1.4.3 of their utility. The issue can likely also be fixed by downgrading to version 6.30.223.228 (utility version 2.0.8.8), but I have not tested this. See this thread for more information.

First uninstall the old driver through Windows Device Manger (and uninstall the utility through the Control Panel, if installed). Then, instead of installing the new utility, I would recommend installing only the new driver (supplied in the same zip-file as the utility). This can be done manually in Device Manager by updating driver software for the PCE-AC68. Note that after uninstalling the old drivers, the adapter might show up as an unrecognized device, so be sure to check that if the PCE-AC68 is no longer present in the device list.