I've just spent the whole night setting up blog comments. PyBlosxom doesn't make it painless, sadly, more like the opposite.

First: don't be scared by the list of comment-related plugins on the PyBlosxom site. There's only one important plugin: comments. All others depend on it and enhance its functionality. The last three or four times I was about to add comments to my blog I got scared at step one: evaluate the available plugins. Don't repeat my mistake!

Second, follow the instructions carefully. There's no shortcut.

Third, fix what's broken. Be prepared to debug the source code. print >> sys.stderr, "message" is your friend.

Fourth, fiddle with the look (CSS and HTML).

Fifth, write a blog post and eagerly await your first comments.

Step 3 screams for an explanation, doesn't it? Problem 1: the comments plugin requires that you use categories in your blog. I'm not (I'm holding out for tags). Workaround: comment out if entry['absolute_path'] check in cb_story and cb_story_end.

Problem 2: the AJAX post returns "Empty response from server". Workaround: modify cb_story_end to call readComments directly if entry['num_comments'] is None, since cb_story, which usually does the read, is not called during the AJAX post.

Problem 3: if you enable comment moderation (by setting comment_draft_ext to a different value from comment_ext), the AJAX post returns "Empty response from server" once more. Workaround: modify cb_prepare to notice this case and set data['moderated'] = True, create a new template comment-moderated and render it in cb_story_end just like the preview template is rendered; also modify __shouldOutput to return True when rendering comment-moderated.

I'll post patches to the pyblosxom mailing tomorrow, unless I forget. It's 6 am already, and I'm kind of sleepy. I just hope I haven't inadvertently broken my RSS feed or flooded any planets.

Oh, and a helpful hint: don't name the post you're writing comments.txt, or the #comments anchor will point to the start of the story instead of the comments.

Update: The story continues, but solution is not in sight yet.

I upgraded a buildbot slave to Ubuntu 8.04 (Hardy) recently and now I'm getting a strange intermittent failure: sometimes cp -r /local/dir /nfs/mounted/dir fails ("process killed by signal 1", i.e. SIGHUP).

I wonder if NFS is relevant or incidental to the issue?

Google finds an old thread from 2005, with a workaround (usepty=False), but I'd like to understand the problem before applying random fixes.

So far three different build steps doing cp -r have failed during 10 days. I've now changed them all to cp -rv, so I can at least see if the failure is in the middle of the copy or at the end, if it fails again.

Update: so far 4 build steps have failed on 6 separate occasions:

May  5 02:31: cp -r local-dir1 nfs-mounted-dir1  
May  6 02:31: cp -r local-dir1 nfs-mounted-dir1  
May  6 04:33: cp -r local-dir2 nfs-mounted-dir2  
May 15 02:00: cp -r local-dir3 nfs-mounted-dir3  
May 17 04:32: rm -rf nfs-mounted-dir4            
May 20 04:31: rm -rf nfs-mounted-dir4            

I see no particular correlation between step duration and results, e.g. the rm -rf step usually takes between 2.2 and 4.6 seconds. The two SIGHUPs happened after 2.4 seconds.

They all make no output. When I changed the cp steps and added a -v, they stopped failing, but that could be just a coincidence.

We're having an email conversation with Jean-Paul Calderone ("exarkun") about the possibility of this being PTY-related, with no clear resolution so far.

And, hey, now this blog supports comments ;)

It's been a while since the last Expert Python Programming review on Planet Python. Y'all might've forgotten about this book by now. Time for a reminder? (Actually, I'm just lazy busy, and this is why this review hasn't appeared sooner.)

I received a free PDF copy of this book from Packt Publishing, with the understanding that I'll post a review on my blog. This is it. Short summary: it is a good book marred by a lot of mostly inconsequential little mistakes. I'd give it four stars out of five.

Aside: the PDF that I could download was personalized and had my name and address in the footer of every page. A very nice form of DRM that did not restrict my software choices for reading the book (Evince and also PDF Reader on Nokia Internet Tablets).

I bring it up here because it seems that Packt could've also applied fixes for the known errata to the personalized version, yet missed that opportunity. Perhaps it's technically more difficult than slapping a footer on every page. Or maybe it's better if everyone buying the book, whether in paper or in PDF, gets to see the same text.

The author (Tarek Ziade) covers a wide range of topics in the book, ranging from syntax (probably useful for those who've been programming in Python for quite a few years, and didn't have the time to keep up with the language changes before picking up this book) to style, source code organization, project infrastructure, software life cycle, documentation, testing and optimization, and finally ending with a review of some of the popular design patterns. The middle parts were the most interesting for me personally. I learned a thing or two, disagreed with the author on a few minor points (which are mostly a matter of preference), and managed to finish the book despite constant irritating little pricks I feel when I notice an error (I confess I'm a pedant. A missing space after a colon drives me up the wall).

As an example of the disagreement: I have an aversion to code-generating tools where you have to edit the generated code by hand. I could say more, but this is a topic for another time. Next, I strongly dislike sudo easy_install since it scribbles onto the part of the filesystem exclusively reserved for your OS's package management tools. And I don't think porting the original 23 design patterns to other programming languages is a good way to describe what those languages are about. (Also, set tabstop=4 in your .vimrc? Heresy! The Right Thing To Do is set softtabstop=4, as all right-thinking Vim users will doubtlessly agree. All hail the one true text editor! Oh dear, now I'm glad I don't have comments on this blog...)

The goodies: Chapter 1 (the bits about PYTHONSTARTUP on page 19) gave me persistent history for my interactive Python prompt, nicely complementing the coloured prompt and tab-completion I already had snarfed from somewhere else on the net (probably Peter Norvig's Python IAQ). Chapter 12 provided good examples of how to do profiling for time (page 281) and memory (page 291). I like Tarek's @profile decorator (measure time, pystones and memory at the same time). My profilehooks module was not mentioned, *sniff* ;-). Chapter 13 told me about Queue.join and task_done that snuck into the stdlib with Python 2.5 without me noticing.

I haven't mentioned topics covered in the book that I was already familiar with, such as setuptools, virtualenv, zc.buildout, Sphinx, Nose, Buildbot, or Mercurial. Yet, in my opinion, those are the most useful parts of the book. The breadth of the topics is amazing: I could hardly think of something that every serious Python programmer should know that isn't wasn't mentioned. I believe the depth was exactly right: mention solutions that are available, show how they feel when used and what they can do, point to the relevant web page and then stop. And not only tools, the descriptions of workflows (how to organize your source trees, how to develop software consisting of multiple packages, how to make releases), while hardly universal, are invaluable.

One thing prevents this from being a perfect book: errata. At around page 95, according to my notes, I invented a new metric of book quality: WTFs per page, It's closely related to WTFs per minute, but independent of your reading speed. At around page 165 I got tired of making a note of every little thing that I noticed and started just reading. This was considerably more enjoyable. I hope there's a second edition will all the bugs shaken out. To that end, I should go through my notes again and submit them via the online errata form. Yay, more work...

Ubuntu people want users to use apport to report bugs. There's a command-line tool called 'ubuntu-bug' that you can use if you know the name of the package or at least the name of executable. There's a "Report a problem" menu item in many, but not all GUI apps.

Here's what you can do if the GUI app in question doesn't have that menu item, and you don't remember what it's called, and you're the same sort of a crazy command-line person that I am:

$ xprop|grep PID

Click on the app's window. Watch that shell command return a line that looks like

_NET_WM_PID(CARDINAL) = 807

$ ps 807  # substitute the real number

You'll see the command name, e.g.

  PID TTY      STAT   TIME COMMAND
  807 ?        S      0:02 /usr/lib/indicator-applet/indicator-applet --oaf-acti

Now you can run

$ ubuntu-bug /usr/lib/indicator-applet/indicator-applet

If you're not running Jaunty, you'll need to do one more step to find the name of the Ubuntu package:

$ dpkg -S /usr/lib/indicator-applet/indicator-applet
indicator-applet: /usr/lib/indicator-applet/indicator-applet

You can use that with apport-cli or on the Launchpad online bug reporting form.

For some (many?) programs you can short-circuit this trail by looking at the WM_CLASS property instead of the _NET_WM_PID property:

$ xprop|grep CLASS
WM_CLASS(STRING) = "indicator-applet", "Indicator-applet"

While there is no requirement for the window class name to match the name of the Ubuntu package or the name of the executable, it may give you a reasonable guess.

Ubuntu 9.04 is going to be released in around three weeks. As usual I couldn't wait (and saw that some bugs that were irritating me every day were fixed in Jaunty), so I upgraded to the current beta.

After a little hiccough at the beginning, the upgrade was the smoothest Ubuntu upgrade I've ever had: I spent those two and a half hours browsing the web, watching screencasts and chatting on IRC, while update-manager worked in the background. Firefox was mostly very responsive, only stuttering when update-manager got around to unpacking openoffice.org-common. There were few debconf or conffile questions (one from sysstat 2 minutes into the upgrade, then a conffile question after 1 hour and 20 minutes, then two more after 15 minutes, and one more 5 minutes later. And the last one 10 minutes later). There were no ugly theme changes or failing GNOME applet error messages during the upgrade. Near the end X-Chat automatically started showing new-style notifications (beautiful!) and Firefoxes nicely asked to be restarted with a fold-down notification bar.

Nice. Now, after a reboot things were not so nice: I couldn't login. After typing in my password and a couple of mode changes I was kicked back to the GDM prompt. I panicked and started logging into the text consoles and trying to run startx, quite in vain, since when I just tried gdm again it worked fine.

The intel video driver feels slower, as promised by the release notes, but it's acceptable as long as you don't try to rotate the external screen. Then it's horrible and unusable—a regression since Intrepid. I'll have to retry with UXA.

Compiz failed to enable a plugin (GNOME Compatibility), so a couple of key bindings didn't work (Alt+F1 to get the menu, Alt+F2 to get the run dialog, my custom keybinding to open a terminal) until someone on FreeNode told me what to enable.

The Flash plugin is now swfdec, and it is unable to cope with Youtube music videos—the sound is all choppy. I'm wondering if this is swfdec's fault, pulseaudio's fault (it's common knowledge that all audio problems stem from pulseaudio, right? ;) or X.org's fault (top shows it's X that's eating 90% CPU when swfdec is trying to play a video).

A lot of very irritating bugs are gone. I don't need to restart Compiz after playing with xrandr. X doesn't crash after I play with xrandr. Two-finger scrolling with the Synaptics touchpad doesn't produce phantom scroll-down-17-pages events when I take my fingers off the touchpad. The GNOME panels don't migrate to the external screen when I play with xrandr (but one of them jumps from the bottom to the top when I play some more). The new splash screen has a pretty gradient for its progress bar (but is displayed off-center, maybe because I added vga=872 to my GRUB kernel options list to avoid ugly stretching of text consoles). X.org no longer distorts the aspect ratio of 1024x768 when stretching it to fit the 1280x800 screen—now I get sensible black bars on the sides. The new notification bubbles are beautiful!. I could stare at them all day. (But the new indicator applet is ugly.)

Overall I'm happy. A bunch of very irritating bugs were replaced with a smaller bunch of somewhat less irritating bugs. The intel video slowdown scares me a bit, though, but the prettiness of the notification bubbles outweigh everything else. What can I say, I like pretty things—Ooh, shiny!