Archive for 2011

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.

germanic_language_family

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                                                                                
[galleryforge:git]
    origin.url = git@github.com:numerodix/galleryforge.git
[italian-course:git]
    origin.url = git@github.com:numerodix/italian-course.git
[re:git]
    origin.url = git@github.com:numerodix/re.git
[spiderfetch:git]
    origin.url = git@github.com:numerodix/spiderfetch.git
> 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                                                                                
[.:git]
    origin.url = user@host:~/repohost.git
[galleryforge:git]
    origin.url = git@github.com:numerodix/galleryforge.git
[italian-course:git]
    origin.url = git@github.com:numerodix/italian-course.git
[re:git]
    origin.url = git@github.com:numerodix/re.git
[spiderfetch:git]
    origin.url = git@github.com:numerodix/spiderfetch.git
> 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:

billbailey_pipe

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.

the Dutch close loopholes

June 14th, 2011

If it's one thing that is very evident about Dutch culture is that they are careful to close down all the loopholes. If you get on the tram and there's a ticket inspection and you say you forgot to swipe your card -- could be an acceptable excuse in Norway -- you'll still get a fine. There's no leniency, no second chances.

Gyms are horribly expensive and their pricing policies are very sleazy, because they usually don't have any short term membership options, you have to join for at least 3 months, or 6, or 12. As a PR bandaid they like to offer an "introductory lesson" or something along those lines. Basically, you can come in and use the gym once, for free, to sort of make up your mind before the point of no return. Sometimes they have an instructor accompany you to explain what is what. It's the same scam as "the cell phone for free", where they try to distract you from the 12 month contract.

At the gym I went to today they do have an introductory lesson. But this being Holland, there is an interesting twist to it. If you want to just come in once you can pay a one time fee of 15 bucks. The introductory lesson, which in theory is free, costs you 12.50. Then, if you decide to get a membership they will deduct that 12.50 from the price you pay later. So the introductory lesson is only free if it's not free, you see that logic?

This is a pretty eccentric attitude. In theory, if you wanted to bad enough you could come in once a month, try not to run into the same staff, and always go for the introductory lesson. If you could do it so that they didn't remember you, you'd get it for free. How many people would actually try that, though? One? Three? The money a gym would lose on this scheme is pretty negligable. More importantly, anyone inclined to go to such lengths probably isn't willing to pay for the gym anyway, so that money wasn't yours to begin with.

But this is a loophole-closing culture, they don't want to run that risk. In Norway the social stigma of being found out and feeling embarrassed is deemed sufficient in such cases that basically noone does it. But the Dutch are not satisfied with that, they need policies that remove any room for such creativity.