[alias]
    addremove = !git add . && git ls-files --deleted | xargs --no-run-if-empty git rm

Tada—git addremove puts new files in the staging area and also removes deleted files. Now you don’t have to pay attention to your hipster friends who try to tell you how great mercurial is.

Today I experienced a real example of the problems that can arise from this design flaw, similar to the issues Jeff points out with Gmail. I live in a moderately sketchy house, and there is a switch which controls the power to several walls worth of electrical outlets. The arrangement of controls is about as good as the fighter jet. Here’s a picture of the switch panel:

Brilliant switch design

I don’t really understand what happened to the machine—the surge protector is fine and I didn’t smell any burning in the case. I verified that the cable is getting power, so either the power supply was blown (hopefully) or the motherboard/cpu are fried (hopefully not). Tomorrow we’re going to swap out the power supply to see, and hopefully I’ll figure it out soon.

#!/bin/bash
 
EVAL_STRING="notify-send -u normal -t 5000 -i info \"Task completed\" \"$@\""
eval $@; eval $EVAL_STRING

I put it in a folder which is in my path, and now I just do

$ notify ./takes_forever

What if this were bold?

There was a fairly recent change to Gmail, where infrequently used labels could be hidden. It lets you keep your important labels in the left sidebar, and if you have 10 more hidden labels you click a little button that says “10 more” to show a menu with all of these labels. Chats, Sent Mail, Drafts, Starred, All Mail, Spam, and Trash also behave like normal labels for this purpose. This is a nice feature, in my opinion. I usually don’t care about how many spam messages I have, so I can tuck it away from my normal view. More importantly, I use a lot of filters (50 or 60) to organize incoming mail under labels (I have 32 at the moment), but  most of these only occasionally receive mail and it’s nice to have them hidden too.

When a label has unread messages in, it turns bold. For me, this used to mean that to see if I had any new mail, I looked both at the top of the inbox and scanned the labels for a bold one. Now, to see if any of my hidden labels have new messages, I have to click the button to show these labels. The fix, in my opinion, is to turn the “25 more” text bold when hidden labels have unread messages (see picture). I know it’s small, but this would save compulsive email checkers like myself a fair amount of annoyance. (Yes, I’m aware that I can just move all my labels out of this menu, but I like this feature too much to stop using it because of this.)

A small caveat here is that if you move the Spam label into this menu, you will always have unread messages (unless you don’t get spam, or mark it as read). Spam could be ignored for the purposes of bolding the button, but this might be considered unexpected behavior. Regardless, I’m sure the smart people on the Gmail team could figure something out.

I couldn’t find anyone else talking about this. This may be due to poor Googling on my part, or perhaps nobody else really cares. Hopefully other people have thought about it and we can get the attention of somebody at Google.

Edit: I found another person’s idea for a solution to this problem here.

• Implementation in Java instead of C
• Features like garbage collection, portability, and a huge standard library come for free
• Languages benefit from advances and optimizations in the JVM

(This is part of a trend pointed out as Prediction #4 in a list of 10 predictions about software Steve Yegge made about 5 years ago.) In fact, targeting a virtual machine has almost become the only way to implement new, fancy languages with reasonable performance, portability, and implementation time.

Scala has an interesting mix of features. Some are taken from functional programming such as higher-order and anonymous functions, closures, partial function applications, and algebraic data types. It has pure OO (everything is an object, even functions) with mixins to compose functionality. Probably the most distinguishing feature of Scala is that it is statically typed (with some pretty nice type inference). For all this, it has a fairly small syntax (significantly smaller than Java, for instance).

As implied by the name, Scala tries to be as scalable as possible. Here are a couple of ways this is done (and I’m sure there are many others that I haven’t seen). Scala programs can be interpreted like scripts: if hello.scala contains

println("OHAI")

then this can be run by

$ scala hello.scala
OHAI

They can also be compiled to class files. If hello.scala instead contains

object HelloApp {
    def main(arg: Array[String]) {
        println("OHAI")
    }
}

then we can do

$ scalac hello.scala
$ scala HelloApp
OHAI

What really makes Scala scalable, though, is how its small but powerful syntax allows creation of new constructs that almost look like new syntax itself. In a great talk by Martin Odersky, the creator of Scala, he presents three nice examples of features that can be concisely added to Scala due to its extensibility: the using keyword, break and continue, and Erlang-style actors (the latter two are included in the Scala library).

I’m just getting started with Scala, but I’ve been very happy with its thorough documentation and the large collection of documents available to help learn the language. For instance, I have found Martin Odersky’s Scala By Example to be a great introduction. It’s nice to see a language that makes it so easy for beginners to figure out what’s going on (I’m looking at you, Cobra). I’m also having a good time reading “Programming in Scala”, the comprehensive and extremely well-written language guide. Not only does it explain Scala very well, it is easy to read and includes tidbits such as this (vars are mutable variables; vals are immutable):

If you’re coming from an imperative background, such as Java, C++, or C#, you may think of var as a regular variable and val as a special kind of variable. On the other hand, if you’re coming from a functional background, such as Haskell, OCaml, or Erlang, you might think of val as a regular variable and var as akin to blasphemy.

Scala has some traction in the software community. The most well-known example, of course, is Twitter; last year they switched their message queuing from Rails to Scala, in their continuing quest to turn millions of dollars of venture capital into the hippest code possible. (Also there was a bit of a case of their backend exploding when things started heating up; it seems a bit telling that they switched to from Ruby to a language that has the first two syllables of ’scalable’ in its name.) There is also a Rails-like web framework for Scala, Lift.

Given my great initial impression, I can only hope that Scala becomes more widespread. I might post more thoughts on Scala quirks and features (as well as my improved vim indent file) later on.

Margin appearing in Chrome, but not FF 3.5 or IE 7.

It’s interesting to see how my brain has grown so accustomed to the Google search page that even a minor change like this stands out instantly.

I’m sure the answer is something simple that I’m missing, but I haven’t figured it out yet. It doesn’t seem dependant on whether I’m logged into Google or not, and is also independent of whether I search through the browser search bar or from google.com directly. I was going to browse the source and CSS to see where it’s coming from, but after glancing at this:

Hurk.

I quickly lost interest.

There is a slight improvement; http://www.ctrl-c.us/ now redirects to http://ctrl-c.us/ :-)

OK, it’s now way past my bedtime. I’m getting up in just a few hours to go on another epic hike. Pictures to follow.

remove Lock = Caps_Lock
add Lock = Escape
keysym Caps_Lock = Escape
keysym Escape = Caps_Lock

In Windows, it’s a bit trickier. You have to add a registry key, and look up the hex codes for the escape and caps lock keys. I found a lot of premade registry files for switching other keys, but apparently I’m the only person who swaps escape with caps lock. Anyway, you just need to paste the following in a file, name it something with a .reg extension, and then double-click it to import the key into the registry.

Windows Registry Editor Version 5.00
 
[HKEY_CURRENT_USER\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,03,00,00,00,3a,00,01,00,01,00,3a,00,00,00,00,00

This only applies the change to the current user, and you have to log out and log back in for the changes to take effect. You have to change the [HKEY_CURRENT_USER\Keyboard Layout] to [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout] if you want it to apply to all users.

While you’re at it, you can find a small utility to allow for alt + left-click window dragging and alt + right-click resizing here and another for background window scrolling here.

SWIG is a great tool that supports a host of high-level languages; I’ve only ever used it with Python. At the other end, you get your choice of C and C++—crappy languages aren’t really my thing, so this tutorial will be about C. I’m going to use Python 3 because all the cool kids live on the bleeding edge. This requires SWIG 1.3.37 or better; if you’re on Ubuntu like me, you’re going to have to go grab it from the website and compile it yourself (I’m using 1.3.39). Also, remember that you need the header files for python installed (python3-dev on Ubuntu). If you’re too lazy to copy-paste, you can download the files here.

We’ll start out with the obligatory hello world program just to test that SWIG is set up correctly. First make a C function that prints the text and name it hello.c:

#include<stdio.h>
 
void hello() {
    printf("Hello, World!\n"):
}

Now we’ll get SWIG to generate a wrapper for us so that we can call it in Python. Make a file called hello.i and put this in it (my code highlighting isn’t feeling very confident about SWIG files, sorry):

%module hello
%{
    void hello();
%}

This file is the interface file, and it tells SWIG what functions and data structures are going to be shared between C and Python. Now we’ll have SWIG process the interface file to make a wrapper for a python module:

$ swig -python hello.i

This should generate two files: hello.py and hello_wrap.c. Compile the C files:

$ gcc -c -fPIC hello_wrap.c hello.c -I/usr/include/python3.0 -I/usr/lib/python3.0

Make sure that the direcotories are correct. Unfortunately, gcc generates a warning when I compile, which is bothersome as I’m a -Werror kind of guy. The -fPIC flag is necessary, because we’re making a shared library the python module is going to use:

$ ld -shared hello.o hello_wrap.o -o _hello.so

If that works, you are ready to fire up Python and try it. At a Python3 prompt:

>>> from hello import *
>>> hello()
Hello, World!

Easy, right? Now I’ll show you some of the features that I most frequently use. First, we’ll pass some data through by wrapping a C function to multiply integers. Make a file called swig_intro.h, and put in the following declaration:

#include<stdlib.h>
#include<stdio.h>
 
int mult(int a, int b);

Then in swig_intro.c we can write

#include "swig_intro.h"
 
int mult(int a, int b) {
    return a * b;
}

Finally, the interface file, swig_intro.i, will look like this:

%module swig_intro
%{
    #include "swig_intro.h"
%}
 
int mult(int a, int b);

To make things easier, let’s write a makefile for this little project:

TARGET     = swig_intro
CC         = gcc
CFLAGS     = -g -fPIC -Wall -Wextra
HEADERS    = swig_intro.h
SRCS       = swig_intro.c
INCLUDES   =
INTERFACE  = swig_intro.i
SWIG       = swig
 
LDSHARED   = ld
CSHARED    = -shared
 
OBJS       = $(SRCS:.c=.o)
 
IWRAP      = $(INTERFACE:.i=_wrap.i)
ISRCS      = $(IWRAP:.i=.c)
IOBJS      = $(IWRAP:.i=.o)
 
PYTHON_INCLUDE= -I/usr/include/python3.0 -I/usr/lib/python3.0
PYTHON_SO     = .so
 
all: $(SRCS)
	$(SWIG) -python $(INTERFACE)
	$(CC) -c $(CCSHARED) $(CFLAGS) $(ISRCS) $(HEADERS) $(SRCS) $(INCLUDES) $(PYTHON_INCLUDE)
	$(LDSHARED) $(CSHARED) $(OBJS) $(IOBJS) -o _$(TARGET)$(PYTHON_SO)
 
clean:
	rm -f *_wrap* *~ .~* *.pyc
	rm -f *.o *.so *.so

If that works, you can launch a Python3 shell (from now on I’ll assume you do the import first):

>>> from swig_intro import *
>>> mult(-10, 5)
-50

Behind the scenes, SWIG uses something called typemaps to specify how each type is from Python to C and vice versa. In many cases, such as this, we don’t need to worry about that at all, because SWIG has default typemaps for all the fundamental datatypes. For example, you might wonder what SWIG does with a C struct. Go ahead and add this definition to the header file and the interface file:

typedef struct Person {
    char *first_name;
    char *last_name;
    int birth_year;
} Person;
 
void print_person(Person *p);

and put the following function into the .c file:

void print_person(Person *p) {
    if (!p->first_name || !p->last_name) {
        printf("The person is not properly defined.\n");
        return;
    }
    printf("%s %s was born in %d.\n", p->first_name, p->last_name, p->birth_year);
}

Now recompile and try this:

>>> p = Person()
>>> p.first_name = "Paul"
>>> p.last_name = "Black"
>>> p.birth_year = 1977
>>> print_person(p)
Paul Black was born in 1977.

As you can see, the the struct Person was wrapped in a very simple Python class with the three public data fields first_name, last_name, and birth_year.

Next, let’s see how to use typemaps ourselves to pass a more complex structure from Python to C. We’re going to make a (rather contrived) C function that will return the product of a list of integers. We’ll do this by turning a Python list into a C struct that specifies an int array and a size. Add the following code to the header and interface files:

struct IntList {
    int size;
    long *list;
} IntList;
 
int product(IntList *l);

In the .c file, add the function:

int product(IntList *l) {
    int i;
    if (l->size <= 0) {
        return 0;
    }
    int ret_val = 1;
    for (i = 0; i size; i++) {
        ret_val *= l->list[i];
    }
    return ret_val;
}

Now we need to define the typemap in the .i file. This isn’t too difficult; we just make use of several functions from the Python C API:

%typemap(in) IntList * {
    if (!PyList_Check($input)) {
        PyErr_SetString(PyExc_TypeError, "Not a list.");
        return NULL;
    }
    int size = PyList_Size($input);
    $1 = (IntList *)malloc(sizeof(IntList));
    long *list = (long *)malloc(sizeof(long) * size);
    $1->list = list;
    $1->size = size;
    int i;
    for (i = 0; i < size; i++) {
        PyObject *item = PyList_GetItem($input, i);
        if (!PyInt_Check(item)) {
            PyErr_SetString(PyExc_TypeError, "List item is not an integer.");
            free(list);
            free($1);
            return NULL;
        }
        list[i] = PyInt_AsLong(item);
    }
}
 
%typemap(freearg) IntList * {
    free(((IntList *)$1)->list);
    free((IntList *)$1);
}

This also illustrates how to tell SWIG to free your objects and how to handle errors. Now we can see it in action:

>>> from swig_intro import *
>>> product(5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Not a list.
>>> product(["five"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: List item is not an integer.
>>> product([1,3,5,7,9])
945

As you would expect, transferring data the other way is similar. For an example, let’s make a function that takes a list and returns a dictionary mapping the list elements to their squares. Add these definitions to the header and interface files:

struct IntMap {
    int size;
    long *list1;
    long *list2;
} IntMap;
 
IntMap *square(IntList *l);

The actual C function will take a pointer to an IntList and return a pointer to an IntMap, allocating space for a second list as needed. The conversion to a dict will be specified with an out typemap. In the .c file:

IntMap *square(IntList *l) {
    IntMap *ret_map = (IntMap *)malloc(sizeof(IntMap));
    ret_map->size = l->size;
    ret_map->list1 = l->list;
    ret_map->list2 = (long *)malloc(sizeof(long) * l->size);
    int i;
    for (i = 0; i size; i++) {
        ret_map->list2[i] = l->list[i] * l->list[i];
    }
    return ret_map;
}

Add the typemap to the .i file:

%typemap(out) IntMap * {
    $result = PyDict_New();
    int i;
    for (i = 0; i size; i++) {
        PyObject *key = PyInt_FromLong($1->list1[i]);
        PyObject *val = PyInt_FromLong($1->list2[i]);
        PyDict_SetItem($result, key, val);
    }
}
 
%typemap(freearg) IntMap * {
    free(((IntMap *)$1)->list2);
    free((IntMap *)$1);
}

And we’re done!

>>> square([1,-12,60000])
{60000: 3600000000, 1: 1, -12: 144}

I’ve only shown some of the more useful capabilities of SWIG that I find myself using a lot. For more information, consult the official SWIG docs. Unfortunately, they’re not entirely complete, so it is sometime easier to get answers by just browsing the built-in SWIG interface files to see how the typemaps work.