Archive for 2011


December 14th, 2011
  • Eva Joly
    socio-political activity and cultural integration
  • Noam Chomsky
  • Slavoj Žižek
  • Umberto Eco
  • Philip Zimbardo

In the tech world

  • Alex Martelli
    • python, programming knowledge, technical respect/authority
  • Armin Rigo
    • pypy
  • Armin Ronacher
    • api design, writing on python
  • Benoît Chesneau
    • python/erlang libraries, programming output
  • Damien Katz
    • couchdb, technical leadership
  • Dave Beazley
    • talks/trainings, swig
  • Jacob Kaplan Moss
    • technical leadership
  • Miguel de Icaza
    • mono
  • Niko Matsakis
    • rust language design
  • Pieter Hintjens
    • zeromq, community building, writing on software/society
  • Steve Yegge
    • writing on programming
  • Zed Shaw
    • teaching


  • Kate Matsudaira
    • leadership, management

the Germanic languages

November 23rd, 2011

When you study languages you really do begin to see them far more in terms of language families. I really enjoyed Alexander Arguelles's five part series about the Germanic language family. Below I have made a simplified version of the chart he presents, focusing on the major modern languages and their roots.


These languages are also known as the Teutonic languages, as is the case in Frederick Bodmer's excellent book on the history of languages, "The Loom of Language".

The earliest language that we have any substantial written texts from is Gothic, from around the 4th century. Everything before that is an extrapolation based on the comparative study of later languages (leading up to the hypothetical Indo-European language that is supposed to be the common ancestor of Gothic, Latin, Greek, Sanskrit and so forth).

The symbolic end point of the chart is around the 18th century, where the languages are similar enough to their current form to be called the modern version of the language. So you can read books dating back to that period with relative ease.

As far as studying them, my starting point was Norwegian and English, and later I added Dutch, so it made sense that I would try all of them out sooner or later (it's hard to find books in Afrikaans but I did find one). The only one I haven't touched is German, but who knows if the mood might strike me one day.

If you're wondering how you might jump across from one of these languages to another, check out my Norwegian-to-Dutch reference card.

re: for the man with many repos

November 13th, 2011

As it often goes, re is a tool that grew out of a bunch of shell scripts. I kept adding stuff to the scripts for a long time, but eventually it went beyond the point of being manageable.

The tool addresses three different issues:

  • Cloning/pulling multiple repos in one step.
  • Keeping repo clones in sync across machines.
  • Better handling of local tracking branches.

Listing repos

Let's start with a basic situation. I've cloned some of my repos on github:

$ ls -F
galleryforge/  italian-course/  re/  spiderfetch/

I run re list to scan the current path recursively and discover all the repos that exist:

$ re list                                                                                
    origin.url =
    origin.url =
    origin.url =
    origin.url =
> Run with -u to update .reconfig

It creates a configuration file called .reconfig that contains the output you see there. By default it doesn't overwrite the config, just shows you the result of the detection action. Pass -u to update it.

This file format is similar to .git/config. Every block is a repo, and :git is a tag saying "this is a git repo". (By design re is vcs agnostic, but in practice I only ever use git and the only backend right now is for git. It probably smells a lot of git in any case.)

Every line inside a block represents a remote (git terminology). By default there is only one. If you add add a remote in the repo and re-run re list it will detect it. But it will assume that origin is the canonical remote (more on why this matters later).

Pulling repos

Now let's say I want to pull all those repos to sync them with github. I use (you guessed it) re pull:

$ re pull                                                                                
> Fetching galleryforge
> Fetching italian-course                                                                
> Fetching re                                                                            
> Fetching spiderfetch                                                                   
> Merging galleryforge                                                                   
> Merging italian-course                                                                 
> Merging re                                                                             
> Merging spiderfetch                                                                    
-> Setting up local tracking branch ruby-legacy                                          
-> Setting up local tracking branch sqlite-try                                           
-> Setting up local tracking branch db-subclass                                          
-> Setting up local tracking branch next

As you can see it does fetching and merging in separate steps. Fetching is where all the network traffic happens, merging is local, which is why I think it's nice to separate them. (But there are more reasons to avoid git pull.)

What it also does is set up local tracking branches against the canonical remote. The canonical remote is the one listed first in .reconfig. So it doesn't matter what it's called, but it's a good idea to make it origin, because that's what re list will assume when you use it to update .reconfig after you add/remove repos.

It handles local tracking branches only against one remote, because if both origin and sourceforge have a branch called stable then it's not clear which one of those the local branch stable is supposed to track. I find this convention quite handy, but your mileage may vary.

If I later remove the branch ruby-legacy from github and run re pull, it's going to detect that I have a local tracking branch that is pointing at something that doesn't exist anymore:

$ re pull spiderfetch
> Fetching spiderfetch
> Merging spiderfetch                                                                    
-> Stale local tracking branch ruby-legacy, remove? [yN]

Scaling beyond a single machine

Now, re helps you manage multiple repos, but it also helps you keep your repos synced across machines. .reconfig is a kind of spec for what you want your repo-hosting directory to contain, so you can just ship it to a different machine, re pull and it will clone all the repos over there, set up local tracking branches, all the same stuff.

In fact, why not keep .reconfig itself in a repo, which again you can push to a central location and from which you can pull onto all your machines:

$ re list                                                                                
    origin.url = user@host:~/repohost.git
    origin.url =
    origin.url =
    origin.url =
    origin.url =
> Run with -u to update .reconfig

It does not manage .gitignore, so you have to do that yourself.

Advanced uses

Those are the basics of re, but the thing to realize is that it doesn't limit you to a situation like the one we've seen in the examples so far, with a single directory that contains repos. You can have repos at any level of depth, you can have .reconfigs at different levels too, and you can then use a single re pull -r to recursively pull absolutely everything in one step.

Get it from github:

war on terror

September 13th, 2011

What an interesting linguistic construct. "War on terror" when in fact terror is actually an integral part of war, isn't it? That's the first thing you do, you *threaten* with war. Do this or we'll beat you up. Then, even after you declare war, the adversary still doesn't know at first how serious you're going to be about it. You could send in the whole army right away or just some... pickpockets. Eh? if you think this is bad, just imagine how much worse it could get. Again you threaten, you threaten to escalate. It's all about trying to instill terror. And then once you have war with planes flying over the city, huge explosions, tanks rolling up the street, it's much more terrorizing for the population than "terrorism" itself.

Now imagine this bit performed by:


la liaison francese

September 8th, 2011

Secondo Assimil (Wikipedia fornisce una spiegazione più chiara però) la liaison va usata nei seguenti casi:

  • tra articolo e nome
  • tra aggettivo e nome
  • tra pronome e verbo

In ogni altro caso sarebbe facoltativa. In più: la liaison si fa più facilmente laddove esiste uno stretto legame sintattico tra le parole; non ha invece luogo se le parole sono separate da una pausa.