(Via proofmathisbeautiful.)

This came up after the PLUG meeting last night, over pizza and beer at the Best House last night.  As Walt pointed out, there was almost certainly a very good reason for this, and it would be living somewhere in the years of messy accretions that comprise my .emacs file and its satellites.

I knew this was probably the case.  Like most .emacs files, mine was not planned.  It grew from bits and useful snippets, mode hooks, random configurations, pieces that crept in as distribution cruft, and pastings of now-unknown provenance.  The whole morass needs a good mucking out, but that’s not on the to-do list.  Perhaps, though, I could finally get the nagging problem resolved.

The first test was an obvious one: remove all the startup files and see if the problem went away.

Now, at some point I acquired a set of XEmacs startup files.  The reason for this is hazy…I haven’t used XEmacs in years.  Nonetheless, there it is: an .xemacs folder with an init.el and custom.el.  At some point, something broke when I tried to take my .emacs file and .emacs.d folder without bringing .xemacs along for the ride, so the path of least resistance was to let it follow me from machine to machine ever since.

After renaming all the startup files, the problem was indeed gone and I could happily page up and down.  From there on, the process is a mechanical one: add files back in until it fails, then comment everything out in the file and add chunks back in until the problem returns.  Once it does, you can be pretty sure you’ve isolated the problem.

Indeed, the problem was lurking in .xemacs/init.el, in the following pair of lines:

(global-set-key "\e[" 'enlarge-window)
(global-set-key "\e]" 'shrink-window)

It seems to me like a slightly odd manifestion, but there you have it.  With those lines removed, my Emacs bliss is unimpeded.

I really ought to get around to getting rid of that XEmacs cruft.

(CC-licensed image of a cricket from TaranRampersad’s flickr photostream.)

import heapq

def dict_nlargest(d,n):
    return heapq.nlargest(n ,d, key = lambda k: d[k])

d = { 'a':10.0, 'b':2.0, 'c':5.0, 'd':3.0, 'e':15.0 }
print dict_nlargest(d,3)

Which neatly prints a list of the keys associated with the three largest values:

['e', 'a', 'c']

The heapq.nlargest() function can also use arbitrary object attributes as keys, as well, by supplying a one-argument function to the named parameter key. (This is the role of the lambda in the examples above and below.)

import heapq
class Toy:
    def __init__Toy(self, s, i, f):
        self.s = s
        self.i = i
        self.f = f

l = [ Toy('a', 10, 4.4), Toy('b', 4, 12.0),
      Toy('c', 2, 20.0), Toy('d', 1, 5.0) ]

# largest by the 'f' attribute
print heapq.nlargest(2, l, key = lambda o: o.f)

# largest by the 'i' attribute
print heapq.nlargest(2, l, key = lambda o: o.i)

This is fine for a one-off, but you’ll likely want to maintain this information in a data structure if this you’ll be performing this operation multiple times on a large collection.

The recent release of a new backend for GHC that can generate code for LLVM is quite exciting.  Even more interesting is this blog post by Don Stewart (co-author of Real World Haskell) exploring genetic algorithms (via the Acovea toolkit) to select sets of LLVM compiler optimizations.  The process isn’t fast (Acovea chews on the options for four hours), but the improvements for even these preliminary explorations are striking.  This approach is worth watching; there is a lot of performance waiting to be squeezed out of modern processors, and it’s even better if we can design approaches that allows automatic optimization for each platform. (Don suggests that he’s working on a wrapper library to allow you to simply issue a main = evolve main' and let it go.)

The researchers distributed oat flakes in a pattern similar to the locations of major cities and turned the Physarum polycephalum loose in, as it were, downtown Tokyo.  As the slime mold established its transport system, the resulting networks closely resembled design of the real-world human-engineered railways.

From their experiments, the researchers have developed a self-organizing mathematical model and simulation that I’d like to look at more closely.

The full text of the article “Rules for Biologically Inspired Adaptive Network Design” by  Tero, et al. is, alas, behind a paywall, as is too much current research, though Science (the journal where it was published) does have a popular take , as do Wired and BoingBoing.

Photo credit: Science/AAAS

The bottom layer is a conventional pizza crust topped with sauce, cheese, pepperoni, olives and smaller pizzas.  These smaller pizzas use English muffins as crusts, a similar array of toppings, and smaller pizzas built on corn chips.  While I admire the creators’ stated desire to achieve a 10-iteration pizza, I think they will have some serious logistical challenges making it past five or six.

There’s been quite a bit of research on the self-organizing behaviors that result in these architectual patterns. For example, this paper by Belić, et al. describes how the workers build parallel combs hanging from the roof of an empty hive. It’s interesting to observe how the cylindrical chamber alters these dynamics, with the comb strands distributed relatively equally around the circumference.

Visit slightlywarped.com’s Curiosities for the full series.

The box is custom-built system based around an Asus P6T motherboard, which has has an onboard RealTek ALC1200 for sound.  This shows up in Linux as

00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family)
HD Audio Controller

and thus uses the snd_hda_intel kernel module (Intel High-Definition Audio).

Having just had occasion to look into my /etc/modprobe.d/alsa-base.conf, I found this exceedingly suspicious pair of lines:

# Power down HDA controllers after 10 idle seconds
options snd-hda-intel power_save=10 power_save_controller=N

The 10-second time-out surely could not be a coincidence.

Sure enough, commenting it out has removed this lingering audio annoyance (which turns out to be completely unrelated to pulse).  It appears this issue is already known: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/417302.  As one commenter observed: “I was also affected by this. I think this is a bug – speakers should not produce unpleasant sounds for [no] apparent reason.”  This is a sentiment with which I can only agree.

Eventually, a “rescue train” came along to extract we poor passengers from our misery. The extraction was not timely, and rather than arriving forty-five minutes early for the lecture on a multi-robot planning, I arrived forty-five minutes late: just in time to miss the end.

You can imagine I was quite pleased, then, when a friend told me the video would be available online. Unfortunately, the link he sent me was for a lecture earlier in the month. Even more distressingly, the recording was only provided via Microsoft Silverlight. I simply do not understand why a computer science department that runs mostly on Linux keeps returning to suckle at a Windows-only, proprietary teat. Disgruntled, I made a note to check out Moonlight at some point.

Somewhat later, I ran an apt-cache search moonlight on my main research box (currently on Karmic), and sure enough, moonlight-plugin-mozilla looked plenty promising. A simple sudo aptitude install moonlight-plugin-mozilla, and it was on its way.

I returned to writing email. A few minutes later, I heard the sound of talking: a video was playing somewhere. Irritated, I tried to figure out if a video one of my open tabs had launched itself. I was somewhat gobsmacked when I found it was the lecture mentioned above: unless I somehow managed to restart Firefox in a memoryless stupor, it seems that the Moonlight plugin insinuated itself into a running Firefox 3.5.7 instance, loaded the player, and kicked off the playback without any intervention.  Impressively smooth and simple.

This may partially make up for my annoyance with Karmic’s compiz, which has an annoying habit of dying out from under X every day or two.