Wat me het meeste verbaast over de huidige DVCS flamewar (hou in het achterhoofd dat we hier op GUADEC 2008 al mee bezig waren, wil iemand wedden of we het zullen volhouden tot GUADEC 2009?), is dat we blijkbaar niet genoeg sysadmin mankracht hebben om een migratie te doen naar git, maar dat we wel voldoende mankracht hebben om een volledig nieuw systeem te ontwikkelen dat beide version control systemen verenigt en dan een migratie te doen naar deze git+bzr combo.

Kan iemand me deze paradox uitklaren?

Als jouw Firefox, net als de mijne, grote hoeveelheden I/O doet bij het sluiten en traag is bij het gebruiken van de awesomebar, probeer dan het volgende (eerst Firefox volledig sluiten):

for f in ~/.mozilla/firefox/*/*.sqlite; do sqlite3 $f 'VACUUM;'; done

Het is onschadelijk, er zal geen data verloren gaan: het compacteert je SQLite databases. Merkbare verschillen hier.

Wanneer je meerdere dingen tegelijk moet doen in een programma is het eerste dat in je hoofd opkomt gewoonlijk: "Ik gebruik een thread!". Normaalgezien wordt dit gevolgd door "Maar threads zijn vreselijk pijnlijk...".

Onlangs heb ik een interessant alternatief bestudeerd aan de universiteit: het Actor Model. Dit model biedt een beheersbaar alternatief voor threads en locking. Het bekendste voorbeeld van een actor model implementatie is Erlang, wat heel populair aan het worden is dezer dagen.

Als deel van dit vak heb ik een paper geschreven die de concurrency van Erlang en Scala (wat ook gebruik maakt van het actor model) beschrijft. Als je ooit met threads gevochten hebt en hoopte op een alternatief, dan kan dit interessant zijn:

Concurrency in Erlang and Scala: The Actor Model

Hieraan gerelateerd en ook interessant zijn de slides van dit vak, die ook communicating event loops bespreken (wat lijkt op GLib events).

Toen ik aan het uitzoeken was waarom Tomboy vrij veel tijd nodig heeft om te starten (BGO #567989, hint: het is niet het gebrek aan SQLite), dacht ik aan Lord Kelvin's uitspraak: "Meten is weten".

Nadenkend hoe ik dit kon doen, dacht ik eraan dat de GNOME community de perfecte tool heeft om uit te zoeken waarom iets traag is: Federico's geweldige timeline tool. Het enige wat ik moest doen is uitzoeken hoe dit gebruikt kan worden met Mono. En dat is vrij simpel, zoals je hieronder zal zien.

Federico gebruikt een slimme hack met syscalls, die gelogd worden met strace. Gelukkig is dit heel simpel te reproduceren met C#.

1. Allereerst moeten we de juiste syscalls genereren. Voeg onderstaande toe aan je programma:
   
public class TraceLogger {
    public static void trace (string group, string format, params object[] args)
    {
        string message = String.Format (format, args);
        string str = String.Format ("MARK: {0}: {1}", group, message);
        Mono.Unix.Native.Syscall.access(str, Mono.Unix.Native.AccessModes.F_OK);
    }
}

2. Voeg royaal veel trace statements toe aan je code: TraceLogger.trace("Main", "Starting main loop");
3. Wijzig je startup script zodat de regel met "exec mono ..." nu "exec strace -ttt -f -o /tmp/timeline.strace mono ...." bevat.
4. Gebruik Federicos script om het te plotten: python plot-timeline.py -o graph.png /tmp/timeline.strace.

Zo simpel is het. De aandachtige lezer zal merken dat ik het tracing formaat iets anders gebruik: in plaats van de programma naam gebruik ik een groep parameter. Dit maakt de grafiek interpreteren iets gemakkelijker: als je teveel tracing statements gebruikt kan het moeilijk zijn om te zien waar de grote gaten zijn. Door de kleurcodes te kapen wordt deze interpretatie moeilijkheid vermeden.

Ga nu maar allemaal snel jullie Mono programma's nog sneller maken!

Na me er maanden aan te ergeren (en helemaal niet te herinneren wat het veroorzaakte) besloot ik om uit te zoeken waarom zowel Ctrl-A en Ctrl-Q gemapt zijn aan Select-All en waarom geen van beide ervoor zorgt dat het programma afgesloten wordt.

Blijkt dat zowel fr en us keymaps hebben het probleem was: BGO #569554. Meest bizarre bug ooit...

En voor wie zich afvraagt hoe ik dit ontdekt heb: Binary Gconf Search. En nee, het was niet fun...