For what has been a fun ride the official results are now available. In the end, 11th out of 700 is not too bad and it's the highest ranking non-C++ entry by some margin.

I entered the contest a bit late with a rather specific approach in mind: UCT, an algorithm from the Monte Carlo tree search family. It has been rather successful in Go (and in Hex too, taking the crown from Six). So with UCT in mind, to serve as a baseline I implemented a quick minimax with a simple territory based evaluation function ... that everyone else in the competition seems to have invented independently. Trouble was looming because it was doing too well: with looking ahead only one move (not even considering moves of the opponent) it played a very nice positional game. That was the first sign that constructing a good evaluation function may not be as hard for Tron as it is for Go.

But with everyone else doing minimax, the plan was to keep silent and Monte Carlo to victory. As with most plans, it didn't quite work out. First, to my dismay, some contestants were attempting to do the same and kept advertising it on #googleai, second it turned out that UCT is not suited to the game of Tron. A totally random default policy kept cornering itself in a big area faster than another player could hit the wall at the end of a long dead end. That was worrisome, but fixable. After days of experimentation I finally gave up on it deciding that Tron is simply too tactical - or not fuzzy enough, if you prefer - for MC to work really well.

Of course, it can be that the kind of default policies I tried were biased (a sure thing), misguided and suboptimal. But then again, I was not alone and watched the UCT based players struggle badly. In the final standings the highest ranking one is jmcarthur in position 105. One of them even implemented a number of different default policies and switched between them randomly with little apparent success. Which makes me think that including a virtual strategy selection move at some points in the UCT search tree should be interesting, but I digress.

So I went back to minimax, implemented Alpha-beta pruning with principal variation, and iterative deepening. It seemed to do really well on the then current maps whose size was severely reduced to 15x15 to control the load on the servers. Then I had an idea to explore how the parities of squares in an area affect the longest path possible which was quickly pointed out to me over lunch by a friend. And those pesky competitors have also found and advertised it in the contest forum. Bah.

There were only two days left at this point and I had to pull an all nighter to finally implement a graph partitioning idea of mine that unsurprisingly someone has described pretty closely in the forum. At that point, I finally had the tool to improve the evaluation function but neither much time or energy remained and I settled for using it only in the end game where the players are separated.

The code itself is as ugly as exploratory code can be, but in the coming days I'll factor the UCT and the Alpha-beta code out.

Tron is a fun little game of boxing out the opponent and avoiding crashing into a wall first. The rules are simple so the barrier to entry into this contest is low. Thanks to aeruiqe who made to Common Lisp starter pack it took as little as a few hours to get a very bare bones algorithm going. It's doing surprisingly well: it is number 23 on the leaderboard at the moment with 43 wins, 2 losses and 9 draws.

Debian Squeeze finally got Xorg 7.5 instead of the old and dusty 7.4. The upgrade was as smooth as ever: DPI is off, keyboard repeat for the Caps Lock key does not survive suspend/resume and the trackpoint stopped working. Synaptics click by tapping went away before the upgrade so that doesn't count.

From a failed experiment today I salvaged Micmac, a statistical library wannabe, that for now only has Metropolis-Hastings MCMC and Metropolis Coupled MCMC implemented. The code doesn't weigh much but I think it gets the API right. In other news MGL v0.0.6 was released.

Let me interrupt the flow of the MGL introduction series with a short report on what I learnt playing with Deep Boltzmann Machines. First, lots of thanks to Ruslan Salakhutdinov, then at University of Toronto now at MIT, for making the Matlab source code for the MNIST digit classification problem available.

The linked paper claims a record of 99.05% in classification accuracy on the permutation invariant task (no prior knowledge of geometry). A previous approach trained a DBN in an unsupervised manner and fine tuned it with backpropagation. Now there is one more step: turning the DBN into a DBM (Deep Boltzmann Machine) and tune it further before handing the baton over to backprop. While in a DBN the constituent RBMs are trained one by one, the DBM is trained as a whole which, in theory, allows it to reconcile bottom-up and top-down signals, i.e. what you see and what you think.

In the diagram above, as before, dark gray boxes are constants (to provide the connected chunks with biases), inputs are colored mid gray while hidden features are light gray. INPUTS is where the 28x28 pixel image is clamped and LABEL is a softmax chunk for the 10 digit classes.

In the Matlab code, there are a number of prominent features that may or may not be important to this result:

• The second RBM gets the the correct label as input which conveniently allows tracking classification accuracy during its training, but also - more importantly - forces the top-level features to be somewhat geared towards reconstruction of labels and thus classification.
• A sparsity term is added to the gradient. Sparse representations are often better for classification.

Focusing only on what makes DBM learning tick, I tried a few variants of the basic approach. All of them start with the same DBN whose RBMs are trained for 100 epochs each:

DBN training finishes with around 97.77%, averaging 97.9% in the last 10 epochs.

On to the DBM. As the baseline, the DBM was not trained at all and the BPN did not get the marginals of the approximate posterior as inputs as prescribed in the paper, only the normal input. It's as if the DBN were unrolled into a BPN directly. Surprisingly, this baseline is already at 99.00% at the end of BPN training (all reported accuracies are averages from the last 10 epochs of training).

The second variant performs DBM training but without any sparsity term and gets 99.07%. The third is using a sparsity penalty ("normal sparsity" in the diagram) for units in opposing opposing layers on at the same time and nets 99.08%. The fourth is just a translation of the sparsity penalty from the Matlab code. This one is named "cheating sparsity" because it - perhaps in an effort to reduce variance of the gradient - changes weights according to the average activation levels of units connected by them. Anyway, this last one reaches 99.09%.

To reduce publication bias a bit, let me mention some experiments that were found to have no effect:

• In an effort to see whether DBM training is held back by high variance of the gradient estimates a batch size of 1000 (instead of 100) was tested for a hundred epochs after the usual 500. There was no improvement.
• In the BPN label weights and biases were initialized from the DBM. This initial advantage diminishes gradually and by the end of training there is nothing (+0.01%) between the initialized and uninitialized variants. Nevertheless, all results and diagrams are from runs with label weights initialized.
• The matlab code goes out of its way to compute negative phase statistics from the expectations of the units in F1 and F2 supposedly to help with variance of estimates and this turned out to be very important: with the same calculation based on the sampled values DBM classification deteriorated. Using the expectations for chunks INPUTS and LABEL did not help, though.

What I take home from these experiments is that from the considerable edge of DBM over DBN training only a small fraction remains by the end of BPN training and that the additional sparsity constraint accounts for very little in this setup.

In the previous part we went through a trivial example of a backprop network. I said before that the main focus is on Boltzmann Machines so let's kill the suspense here and now by cutting straight to the heart of the matter.

Cottrell's Science article provides a clear and easy to follow description of the spiral problem that we are going to implement. The executive summary is that we want to train an auto-encoder: a network that reproduces its input as output with a small encoding layer somewhere in between. By forcing the information through the bottleneck of the encoding layer the network should pick up a low dimensional code that represents the input, thus performing dimensionality reduction.

The function under consideration is f(x) = [x, sin(x), cos(x)]. It is suprisingly difficult to learn the mapping from x to f(x). A network architecture that is able to represent this transformation has 3 inputs, 10 neurons in the next layer, 1 neuron in the encoding layer, 10 neurons again in the reconstruction part and 3 in the output layer. However, randomly initialized backpropagation fails at learning this; a better solution is to first learn a Deep Belief Network, "unroll" it to a backprop network and use backprop to fine tune the weights.

A Deep Belief Network is just a stack of Restricted Boltzmann Machines. An RBM is a BM restricted to be a two layer network with no intralayer connections. The "lower" layer is called visible and the "higher" layer is called hidden layer, because from the point of view of a single RBM it is the visible layer that's connected to - maybe indirectly - to external stimuli. In the upward pass of a DBN, where the low level representations are subsequently transformed into higher level ones by the constituent RBMs, the values of the hidden units are clamped onto the visible units of the next RBM. In other words, an RBM shares its visible and hidden layers with the hidden and visible layers of the RBM below and above, respectively, respectively.

Let's start with a few utility functions:

 (defun sample-spiral ()
   (random (flt (* 4 pi))))
 
 (defun make-sampler (n)
   (make-instance 'counting-function-sampler
                  :max-n-samples n
                  :sampler #'sample-spiral))
 
 (defun clamp-array (x array start)
   (setf (aref array (+ start 0)) x
         (aref array (+ start 1)) (sin x)
         (aref array (+ start 2)) (cos x)))
 
 (defun clamp-striped-nodes (samples striped)
   (let ((nodes (storage (nodes striped))))
     (loop for sample in samples
           for stripe upfrom 0
           do (with-stripes ((stripe striped start))
                (clamp-array sample nodes start)))))

Subclass RBM and define SET-INPUT using the above utilites:

 (defclass spiral-rbm (rbm) ())
 
 (defmethod mgl-train:set-input (samples (rbm spiral-rbm))
   (let ((chunk (find 'inputs (visible-chunks rbm) :key #'name)))
     (when chunk
       (clamp-striped-nodes samples chunk))))

Define the DBN as a stack of two RBMs: one between the 3 inputs and 10 hidden features, the other between the 10 hidden features and the encoding layer that's unsurprisingly has a single neuron:

 (defclass spiral-dbn (dbn)
   ()
   (:default-initargs
    :layers (list (list (make-instance 'constant-chunk :name 'c0)
                        (make-instance 'gaussian-chunk :name 'inputs :size 3))
                  (list (make-instance 'constant-chunk :name 'c1)
                        (make-instance 'sigmoid-chunk :name 'f1 :size 10))
                  (list (make-instance 'constant-chunk :name 'c2)
                        (make-instance 'gaussian-chunk :name 'f2 :size 1)))
     :rbm-class 'spiral-rbm))

Note that by default, each pair of visible and hidden chunks is connected by a FULL-CLOUD that's the simplest kind of connection. INPUTS via the cloud between INPUTS and F1 contributes to the activation of F1: in the upward pass the values found in INPUTS are simply multiplied by a matrix of weights and the result is added to the activation of F1. Downward pass is similar.

Once the activations are calculated according to what the clouds prescribe, chunks take over control. Each chunk consists of a number of nodes and defines a probability distribution over them based on the activations. For instance, SIGMOID-CHUNK is a binary chunk: each node can take the value of 0 or 1 and the probability of 1 is 1 / (1 + e^(-x)) where X is the activation of the node.

Nodes in a GAUSSIAN-CHUNK are normally distributed with means equal to their activations and unit variance. In SPIRAL-DBN above the INPUTS and the final code, F2, are gaussian.

Let's check out how it looks:

 (let* ((dbn (make-instance 'spiral-dbn))
        (dgraph (cl-dot:generate-graph-from-roots dbn (chunks dbn))))
   (cl-dot:dot-graph dgraph "spiral-dbn.png" :format :png))

In a box the first line shows the class of the chunk and the number of nodes in parens (omitted if 1), while the second line is the name of the chunk itself. The constant chunks - in case you wonder - provide the connected chunks with a bias. So far so good. Let's train it RBM by RBM:

 (defclass spiral-rbm-trainer (rbm-cd-trainer) ())
 
 (defun train-spiral-dbn (&key (max-n-stripes 1))
   (let ((dbn (make-instance 'spiral-dbn :max-n-stripes max-n-stripes)))
     (dolist (rbm (rbms dbn))
       (train (make-sampler 50000)
              (make-instance 'spiral-rbm-trainer
                             :segmenter
                             (repeatedly (make-instance 'batch-gd-trainer
                                                        :momentum (flt 0.9)
                                                        :batch-size 100)))
              rbm))
     dbn))

Now we can unroll the DBN to a backprop network and add the sum of the squared differences between the inputs and the reconstructions as the error:

 (defclass spiral-bpn (bpn) ())
 
 (defmethod mgl-train:set-input (samples (bpn spiral-bpn))
   (clamp-striped-nodes samples (find-lump (chunk-lump-name 'inputs nil) bpn)))
 
 (defun unroll-spiral-dbn (dbn &key (max-n-stripes 1))
   (multiple-value-bind (defs inits) (unroll-dbn dbn)
     (let ((bpn-def `(build-bpn (:class 'spiral-bpn
                                        :max-n-stripes ,max-n-stripes)
                       ,@defs
                       (sum-error (->sum-squared-error
                                   :x (lump ',(chunk-lump-name 'inputs nil))
                                   :y (lump ',(chunk-lump-name
                                               'inputs
                                               :reconstruction))))
                       (my-error (error-node :x sum-error)))))
       (let ((bpn (eval bpn-def)))
         (initialize-bpn-from-bm bpn dbn inits)
         bpn))))

The BPN looks a whole lot more complicated, but it does nothing more than performing a full upward pass in the DBN and a full downward pass:

 (let* ((dbn (make-instance 'spiral-dbn))
        (bpn (unroll-spiral-dbn dbn))
        (dgraph (cl-dot:generate-graph-from-roots bpn (lumps bpn))))
   (cl-dot:dot-graph dgraph "spiral-bpn.png" :format :png))

Training it is as easy as:

 (defclass spiral-bp-trainer (bp-trainer) ())
  
 (defun train-spiral-bpn (bpn)
   (train (make-sampler 50000)
          (make-instance 'spiral-bp-trainer
                         :segmenter
                         (repeatedly
                           (make-instance 'batch-gd-trainer
                                          :learning-rate (flt 0.01)
                                          :momentum (flt 0.9)
                                          :batch-size 100)))
          bpn)
   bpn)

I'm tempted to dwell on pesky little details such as tracking errors, but this entry is long enough already. Instead, load the mgl-example system and see what example/spiral.lisp has in addition to what was described. Evaluate the block commented forms at the end of the file to see how training goes.

Having been motivated, today we are going to walk through a small example and touch on the main concepts related to learning within this library.

At the top of food chain is the generic function TRAIN:

 (defgeneric train (sampler trainer learner)
   (:documentation "Train LEARNER with TRAINER on the examples from
 SAMPLER. Before that TRAINER is initialized for LEARNER with
 INITIALIZE-TRAINER. Training continues until SAMPLER is finished."))

A learner is anything that can be taught, which currently means it's either a backpropagation network (BPN) or some kind of boltzmann machine (BM). The method with which a learner is trained is decoupled from the learner itself and lives in the trainer object. This makes it cleaner to support multiple learning methods for the same learner: for instance, either gradient descent (BP-TRAINER) or conjugate gradients (CG-BP-TRAINER) can be used to train a BPN, and either contrastive divergence (RBM-CD-TRAINER) or persistent contrastive divergence (BM-PCD-TRAINER) can be used to train a restricted boltzmann machine (RBM).

The function TRAIN takes training examples from SAMPLER (observing the batch size of the trainer, if applicable) and calls TRAIN-BATCH with the list of examples, the trainer and the learner. This may be as simple as:

 (defmethod train (sampler (trainer bp-trainer) (bpn bpn))
   (while (not (finishedp sampler))
     (train-batch (sample-batch sampler (n-inputs-until-update trainer))
                  trainer bpn)))

Ultimately, TRAIN-BATCH arranges for the training examples to be given as input to the learner ("clamped" on the input nodes of some network) by SET-INPUT; exactly how this should be done must be customized. Then, in the case of BP-TRAINER, the gradients are calculated and added to the gradient accumulators that live in the trainer. When the whole batch is processed the weights of the network are updated according to the gradients.

Let's put together a toy example:

 (use-package :mgl-util)
 (use-package :mgl-train)
 (use-package :mgl-gd)
 (use-package :mgl-bp)
 
 (defclass linear-bpn (bpn) ())
 
 (defparameter *matrix*
   (matlisp:make-real-matrix '((1d0 2d0) (3d0 4d0) (5d0 6d0))))
 
 (defparameter *bpn*
   (let ((n-inputs 3)
         (n-outputs 2))
     (build-bpn (:class 'linear-bpn)
       (input (input-lump :size n-inputs))
       (weights (weight-lump :size (* n-inputs n-outputs)))
       (product (activation-lump :weights weights :x input))
       (target (input-lump :size n-outputs))
       (sse (->sum-squared-error :x target :y product))
       (my-error (error-node :x sse)))))
 
 (defmethod set-input (samples (bpn linear-bpn))
   (let* ((input-nodes (nodes (find-lump 'input bpn)))
          (target-nodes (nodes (find-lump 'target bpn)))
          (i-v (storage input-nodes)))
     (assert (= 1 (length samples)))
     (loop for i below (length i-v) do
           (setf (aref i-v i) (elt (first samples) i)))
     ;; TARGET-NODES = INPUT-NODES * *MATRIX*
     (matlisp:gemm! 1d0 (reshape2 input-nodes 1 3) *matrix*
                    0d0 (reshape2 target-nodes 1 2))))
 
 (defun sample-input ()
   (loop repeat 3 collect (random 1d0)))
 
 (train (make-instance 'counting-function-sampler
                       :sampler #'sample-input
                       :max-n-samples 10000)
        (make-instance 'bp-trainer
                       :segmenter
                       (repeatedly
                         (make-instance 'batch-gd-trainer
                                        :learning-rate (flt 0.01)
                                        :momentum (flt 0.9)
                                        :batch-size 10)))
        *bpn*)

We subclassed BPN as LINEAR-BPN and hanged a SET-INPUT method on it. The SAMPLES argument will be a sequence of samples returned by the sampler passed to TRAIN, that is, what SAMPLE-INPUT returns.

The network multiplies INPUT taken as a 1x3 matrix by WEIGHTS (initialized randomly) and the training aims to minimize the squared error as calculated by the lump named SSE. Note that SET-INPUT clamps both the real input and the target.

We instantiate BP-TRAINER that inherits from SEGMENTED-GD-TRAINER. Now, SEGMENTED-GD-TRAINER itself does precious little: it only delegates training to child trainers where each child is supposed to be a GD-TRAINER (with all the usual knobs such as learning rate, momentum, weight decay, batch size, etc). The mapping from segments (bpn lumps here) of the learner to gd trainers is provided by the function in the :SEGMENTER argument. By using REPEATEDLY, for now, we simply create a distinct child trainer for each weight lump as it makes a function that on each call evaluates the form in its body (as opposed to CONSTANTLY).

That's it without any bells and whistles. If all goes well WEIGHTS should be trained to be equal to *MATRIX*. Inspect (nodes (find-lump 'weights *bpn*)) to verify.

Impatience satisfied, examine the BUILD-BPN form in detail. The :CLASS argument is obvious, and the rest of the forms are a sequence of bindings like in a LET*. The extra touches are that the name of the variable to which a lump is bound is going to be supplied as the :NAME of the lump and an extra MAKE-INSTANCE is added so

 (input (input-lump :size n-inputs))

is something like

 (make-instance 'input-lump :name 'input :size n-inputs)

One can replicate this with MAKE-INSTANCE and ADD-LUMP, but it's more work. For ease of comprehension the network can be visualized by loading the mgl-visuals system and:

 (let ((dgraph (cl-dot:generate-graph-from-roots *bpn* (lumps *bpn*))))
   (cl-dot:dot-graph dgraph "linear-bpn.png" :format :png))

That's it for today, thank you for your kind attention.

This is going to be the start of an introduction series on the MGL Common Lisp machine learning library. MGL focuses mainly on Boltzmann Machines (BMs). In fact, the few seemingly unrelated things it currently offers (gradient descent, conjugate gradient, backprop) are directly needed to implement the learning and fine tuning methods for different kinds of BMs. But before venturing too far into specifics, here is a quick glimpse at the bigger picture and the motivations.

Most of the current learning algorithms are based on shallow architectures: they are fundamentally incapable of basing higher level concepts on other, learned concepts. The most prominent example of succesful shallow learners is Support Vector Machines, for which there is a simple CL wrapper around libsvm, but that's a story for another day.

On the other hand, deep learners are theorethically capable of building abstraction on top of abstraction, the main hurdle in front of their acceptance being that they don't exist or - more precisely - we don't know how to train them.

A good example of a deep learner is the multi-layer perceptron: with only three layers it is a universal approximator which is not a particularly difficult achievement, and the practical implications of this result are not earth shattering: the number of required training examples and hidden units can be very high and generalization can be bad.

Deep architectures mimic the layered organization of the brain and, in theory, have better abstraction, generalization capability, higher encoding effeciency. Of course, these qualities are strongly related. While this has been known/suspected for a long time, it was only recently that training of deep architectures started to become feasible.

Of deep learners, boltzmann machines deserve special attention as they have demonstrated very good performance on a number of problems and have a biologically plausible, local, Hebbian learning rule.

Now that you are sufficiently motivated, stick around and in the later parts of this series we are going to see real examples.

I'm cleaning up the accumulated junk and found this guide that was written eons ago.

This build is focused on survival. No save/loading, killap's final patch, hard combat and game difficulty. As it is not only ironman but a munchkin too it must be a sniper since HtH is a bit underpowered.

See this for good insights into ironman survival. The two most important pieces of advice it has is: sneak and outdoorsman. Sneak does not work as well for me as advertised, that is I cannot end combat in all cases if the critter I shot did not die. Still, Sneak is still incredibly useful so it's tagged and raised to 150% in a hurry. Small Guns and Speech get tagged as well.

A true munchkin takes Gifted and Small frame. We rely on Sneak to keep us from being shot at so Fast Shot would not help too much. The main emphasis is on survival so endurance and agility must be 10. NPCs cannot be kept alive and are not needed for most of the game, plus conversation is ruled by Speech thus charisma is 2. Good minmaxing so far. Luck is 8 and will be 10 after the Zeta scan. This is important for Sniper.

This leaves us with 18 points for Strength, Perception and Intelligence. Each point in Perception adds 8% to shooting accuracy. However putting the same point into Intelligence gives 66 skill points to spend by level 34. Small Guns shall go beyond 200% where the cost of 1% is 3 skill points (it's tagged). 66 points is worth 22% to shooting accuracy. Clearly Intelligence seems the better place.

However, Perception also determines sequence. Contrary to what the link above says I find it important that enemies don't get a double turn. If combat could be ended dependably it would be less of an issue, alas, it cannot. This makes Perception pretty important. With the +1 obtainable by surgery 9 is a good number.

Strength allows you to carry more which is a small convenience at the beginning. Even with Small Frame one can get away with a strength as low as 2 especially with Sulik in the beginning and later the car. The other, main use of strength is to avoid the 20% shooting accuracy penalty per point under the weapon's minimum strength. At high levels you'll have 6-7 in strength with armor and surgery. At lower levels the penalty can be (over)compensated for by pouring skill points into Small Guns (after reading the books of course).

What about strength vs perception? Strength is useful in the early game before Small Guns is high enough. Perception remains useful at the end due to its accuracy bonus. Intelligence below 6 is out of question unless you aim for maximum efficiency at level 50.

So what is it that we optimize for? Munchkin combat power, of course. When? Mostly at the end, say at level 34. That's 33 levels gained and 11 perks. So without further ado, pure munchkin starting stats:

 S: 2, P: 9, E: 10, C: 2, I: 7, A: 10, L: 8

Developed stats with armor, surgeries, shades, zeta scan, combat implants:

 S: 7, P: 10, E: 10, C: 2, I: 8, A: 10, L: 10

Skill point needs:

 93=28+26+39 Sneak (tagged): 45% -> 151%
 
 265=23+26+39+52+65+60 Small Guns (tagged): 55% -> 221%
 
 21 Speech (tagged): 19% -> 76% (+5% expert excrement expeditor, +10% enhancer)
 
 32 Doctor: ~1% -> 55% (+5% VC training, +20% doctor's bag, +10% enhancer)
 
 0 Outdoorsman: ~23% -> 110% (books, +20% motion sensor)

That's 411 skill points. Required points in intelligence: 499/33levels/2 = 6.22. A few more points can be saved by reading Guns and Bullets magazines (max 18). Still, there is a point in improving Small Guns over 220%, take the gauss rifle or pistol for example which has a 20% bonus on accuracy and try to shoot someone in the eye in Advanced Power Armor II from 30 hexes:

 (SmallGuns = 220) + (8 * (Perception = 10)) + (Weapon bonus = 20)
 + (Ammo AC modifier = 30)
 - 30 - (AC = 45) - (4 * (N-Hex = 30)) - (Eyes = 60) = 95%

Perks:

 Toughness(3)
 Lifegiver(2)
 Bonus rate of fire
 Better Criticals
 Sniper
 Bonus Move(2)
 Action Boy(2)
 Living Anatomy

This character is hard to play in the early game. Small Guns takes some time to develop and the -40% penalty for most guns due to the low strength is a killer until power armor and/or the Red Ryder.

To make the early game less of a struggle Small Guns shall be raised pretty early, after Sneak reaches 100% and you have read a few Guns and Bullets from Klamath, the Den, Redding and Modoc. Grab as many Scout handbooks as you can.

Useful links:

http://faqs.ign.com/articles/777/777224p1.html

http://user.tninet.se/~jyg699a/fallout2.html#combat

http://www.fanmadefallout.com/fo2-items/

http://www.fanmadefallout.com/procrit/

http://www.playithardcore.com/pihwiki/index.php?title=Fallout_2

Debian Lenny was released back in February. My conservativeness only lasts about half a year so I decided to upgrade to Squeeze aka Debian testing. The upgrade itself went rather smoothly with a few notable exceptions. With KDE 4.3 I should have waited more. Notes:

• Who thought it a grand idea that in the default theme (Oxygen) the color of the panel and window title bar cannot be customized? Installing the desktop theme called Aya solved the panel issue while going back to Keramik helped with the title bar.
• The kmail message list is a train wreck by default with its multi-line entries. It took me ages to find how to turn it to back to classic theme (hint: it's not under `Configure KMail'), at the cost of no threading messages.
• I had customized kwin to use the Super key for all shortcuts. KDE3 decided to call it the Win key, but hey, I understand that's where it's often mapped. After the upgrade my settings were wiped out.
• In org-mode C-u C-c C-t had asked for a new tag. After the upgrade and (setq org-use-fast-todo-selection 'prefix) it does so again.
• The X.org upgrade broke my fragile xmodmap config so I wrote an xkb based config instead. It's activated with:

 xkbcomp -I$HOME/.xkb ~/.xkb/keymap/us_lisp $DISPLAY

• Upgrading to emacs23 was painless, except for blorg that needed a couple of hacks to get this entry out the door.