So after madman is currently orphaned in Debian and might get kicked out of the archive along with xmms kicking the bucket, I just noticed that one of my newer pieces of code made it into Debian: tagpy! :) That's awesome.

To everybody who is holding their breath waiting for a madman update: I still use madman for my own music managing needs, as it still (surprise) is exactly what I want in a music manager. But I simply don't have enough time for serious maintenance. I might switch it to audacious in the near future to keep it working for me, but I'm not promising extensive new features...

Watch this:

You won't regret it. :) (PS: Yes, I know it was made by a bunch of Germans, and yes, they misspelled "belief", but that doesn't kill it, in my opinion.)

Embarassing Update: I figured out how to embed youtube videos. :)

I have just uploaded version 0.91 of lircd-xpc to the site. This should make the daemon a bit more resilient against a state where one endpoint thread crashes, and the other lives on, resulting in an unresponsive daemon. If you've encountered this, you might want to update. This requires the latest libhid (and Python wrappers) including a patch that I've just sent to the list. That patch should make it into libhid svn pretty soon. Until then, you may grab my custom libhid Debian packages from the download directory.

Dearest readership! It is with great pleasure that on this second day of christmas I offer you my best wishes for the feast of love--with this picture that I have, in true christmas spirit, lifted from elsewhere:

Merry Christmas to all anyway... :)

Because when you're looking for Runge-Kutta methods, you find neat stuff and end up playing with it. That's why.

(How's that for a first journal post after fifteen years, huh?) :)

If you get errors like

multiple definition of 
`_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE'

when compiling PyLinear, it is because of this GCC bug, and it's quite likely that you are using GCC 4.1. Supposedly, this will be fixed in GCC 4.2. This bug will likely also affect other UBLAS applications.

The suggested workaround is to use GCC 4.0.

UPDATE: Everything seems fine in at least Debian's gcc package of version 4.1.1-11.

If you are a Comcast customer (particularly in Illinois) and your Voice-over-IP (or other large-UDP-packet-using) application does not work as it should, don't worry, it's their fault. :P

For some reason, they include

...
OPTION:  26 (  2) Interface MTU             576
...

in the replies from their DHCP servers, which leads your computer to throw away large UDP packets (such as SIP INVITE replies). I don't know why they'd do this since a) it breaks their customers' applications (on purpose?!) and b) it puts more load on their network.

In any case, here's the antidote: In dhclient.conf, say

# F!$#$ stupid comcast.
supersede interface-mtu 1500;

After that, everything should be working fine. If you're violating their terms of service in doing so, it's your own fault. I didn't tell you. 8)

It only cost me like two hours of my life to find and fix this. Quote from the reply from the customer service rep:

I'm sorry, but we do not have any information as to why the MTU is configured for the level that it is. That decision is likely made by the Network Department and something we would not be able to obtain or discuss.

I love you, too.

I've just released version 0.91 of TagPy. Besides some minor fixes, the biggest change is that you don't say any more

tag.setArtist("Fat Boy Slim")

Instead, the (IMO) much more pythonic

tag.artist = "Fat Boy Slim"

is now where it's at. Reading these attributes (and just these) is also changed from tag.artist() to tag.artist. I repeat, this only affects

• Tag.title
• Tag.artist
• Tag.album
• Tag.genre
• Tag.year
• Tag.track
• AudioProperties.length
• AudioProperties.bitrate
• AudioProperties.sampleRate
• AudioProperties.channels

Since these are so frequent, I saw a compelling reason to change them. Everything else in the API will remain as close as possible to TagLib's C++ conventions.

Sorry for the source-incompatible change, it will not happen again.

Enjoy.

I've made a minor update to clockwork that now allows you to immediately see how much longer the current workday is supposed to last, from the output of clockwork howlong. This update came out of a particular need that I had at my new summer job at the Math and Computer Science divsion at Argonne National Labs. I've also released Version 1.1, with that (and another minor) change.

As part of the course requirements for the mechanics class I took, a team of which I was a part designed a Rattleback. A rattleback is a top that appears to have a preferred direction of rotation, i.e. if you start spinning it the wrong way, it (unintuitively) will turn around and spin "the right way". There's quite a bunch more to know about the physics [1] of it, if you care. It might also be an interesting dynamical system to study, as little is known about it past what can be found by numerical simulations. Speaking of numerical simulations, if you are a student of EN137 after me and would like to take a peek at our simulation code (which was written in Octave, with a bit of PyLinear sprinkled in), be my guest.

In any case, you may view the NOT FOUND: rattleback.avi=video of our rattleback to see for yourself!

PS: I blatantly stole the title of this entry from one of the other teams. :)

[1] A. Garcia, M. Hubbard Spin Reversal of the Rattleback: Theory and Experiment Proceedings of the Royal Society of London. Series A, Mathematical and Physical Sciences, Vol. 418, No. 1854 (Jul. 8, 1988) , pp. 165-197