[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.

#!/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

• 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.

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.

I’ve allowed some tags, and this introduces a problem: you can submit a comment that doesn’t have proper closing tags, such as

<del>I think I'm funny

As I was working on the form validation, I came across a tidbit of knowledge I hadn’t been aware of. Apparently, the official specification for a valid email address is in RFC 2822 and can be implemented with this monster of a regular expression. Lovely.

Update: I’d love it if you’d like to try to break the comments, but please do it in the testing area of my site at http://ctrl-c.us/testing/. Also, please don’t try anything too malicious. If you notice something, leave a comment to let me know. Thanks.

In other news, when I most recently checked this site has climbed to somewhere on the second page of Google search results for both my name and “ctrl-c”. Hopefully this is going up quickly. I still have several features I’m working on which I have yet to roll out. I’m almost done with the comments code, but I haven’t done the submission form (along with all the proper stripping to get rid of nasty injections…ugh). Also, I’m going to be adding nice syntax highlighting for code samples, which should both look cool and necessitate the writing of an actual article about code :) Finally, I’ve yet to add admin pages, but this is pretty low priority.