Not Even My Wife Reads This

I like working on my own bikes, but I'm not very good at it.

This morning I had a rear flat on my junker 1970s Azuki fixed gear.  Pumped it back up with the frame pump; it went flat again quickly.  Not a slow enough leak to defer the repair.

Pushed the bike a block to a nicer spot.  Removed the back wheel (with some difficulty; the quick release was on very tight), removed the tire, discovered my spare tube was Presta while my fixie has Schrader valves, decided to patch the tire instead, actually did a good job patching it, put the tube back in the tire and the wheel back on the bike, pumped up the tube, rode to work.  The flat cost me about half an hour; I was slow and careful fixing it, and I hadn't removed the fixed-gear wheel in a couple of years.

Got to work, and decided to pump the tire better using the floor pump there.  (I never get enough air in with a frame pump).  The tires (Nashbar Cheng Shin 27″ cheapies) are rated for 90 psi, but past experience says they actually explode at 90, so I stopped at 85.  Went back to my desk.  A few minutes later,"Bang!"  What was that?  I didn't even realize it was my tire until someone told me.  My patch held, but the tube had a big gash in the side, so I either needed to use my Presta tube, or go to the bike store and buy a Schrader tube.  I opted for the Presta.

Wheel off again, tire off again, new tube in, and put it all back together.  Went pretty fast this time.  Unfortunately the tube started bulging out the Schrader-sized hole.  Not good.  An excessively handy guy at work managed to whittle a plastic washer into a near-perfect Presta-Schrader adapter.  (Thanks Mike.)  I put some rubber cement around it to keep the tube out of the small remaining gap, waited a few minutes for the glue to dry, then put the wheel back on the bike.  All done, but I didn't get the quick release quite tight enough.  So I tightened it some more, pushed really hard — and snapped the skewer.  (Looked like a vintage 1970s cheap skewer, so I'm not too surprised I broke it.)

Dammit.  Borrowed the company van, went to the bike store, bought a skewer (none were marked for separate retail sale but they gave me a used Shimano one out of the parts bin for $5) and a Schrader tube.  I couldn't get the skewer on tight enough by hand so I used pliers, which meant I now need to carry pliers in my bike bag, until I replace the replacement skewer with a better one.

The bike got me home fine.  I meant to go really slowly and carefully in case of further drama but ended up averaging 17 mph, about normal.

Tomorrow I'm going mountain biking.  Wonder what I'll break next.  As long as it's not bones…

The previous benchmark was too fast, and mostly only measured startup time. Here's a slower one. Project Euler Problem 10

Basically, find the sum of all primes up to a million. Best of 5 runs for each Python version.  Basically the standard Sieve of Eratosthenes in a loop.

python2.4 13.131s
python2.5 12.67s
python2.6 11.517s
python3.0 13.764s
jython2.2.1 11.542s
pypy-c (r56024, translate.py –gc=hybrid –thread targetpypystandalone –faassen –allworkingmodules), 12.774s
python2.5 with psyco: 1.926s
python2.5 using gmpy.is_prime 2.441s
python2.5, psyco, gmpy.is_prime 1.762s

So on this one all the Python versions are pretty close, with a nice steady improvement from 2.4 to 2.5 to 2.6. Jython and pypy are both in the same ballpark.  psyco makes it run about 6 times as fast. Using gmpy's is_prime function (written in C) instead of my Python sieve has a similar result.

Python 2.6 beta 1 and 3.0 beta 1 were both released Wednesday. This gave me the urge to run a quick speed comparison on all the versions of Python installed on my Linux box.

The program in question is my solution to Project Euler problem 100. (Source code not provided, because that would be a spoiler.)

$ time python2.4 euler100.py > /dev/null

real 0m0.010s
user 0m0.006s
sys 0m0.005s

$ time python2.5 euler100.py > /dev/null

real 0m0.013s
user 0m0.010s
sys 0m0.003s

$ time python2.6 euler100.py > /dev/null

real 0m0.012s
user 0m0.009s
sys 0m0.003s

$ time python3.0 euler100.py > /dev/null

real 0m0.024s
user 0m0.021s
sys 0m0.004s

$ time pypy-c euler100.py > /dev/null
debug: WARNING: library path not found, using compiled-in sys.path

real 0m0.042s
user 0m0.009s
sys 0m0.033s

$ time jython euler100.py > /dev/null
Traceback (innermost last):
File "euler100.py", line 58, in ?
File "euler100.py", line 49, in main
OverflowError: float too large to convert

real 0m3.372s
user 0m2.707s
sys 0m0.092s

Executive summary: Python 2.4 through 2.6 are all about the same speed, for this test. 3.0 is about twice as slow. PyPy is four times as slow. And Jython is way slow and blows up converting big numbers.

Of course, this is just one data point. I should scale this test up to run all my Project Euler solutions that don't rely on external libraries. (It would probably take significant work to get libraries like gmpy to work with 3.0 or PyPy.)

We have some code at work that uses the old GnomeCanvas. I wanted to update it to a Cairo-using canvas to get antialiasing and better font scaling. Looked at CrCanvas, FooCanvas, GooCanvas, and HippoCanvas. Decided to use GooCanvas, based on docs and examples and Python bindings and license.

Unfortunately, the latest GooCanvas (0.10) wants Cairo 1.4, and Red Hat Enterprise 5 (which we have to use at work) is stuck at Cairo 1.2, and half of the Gnome stack seems to depend on Cairo.

The solution was pretty simple: use GooCanvas 0.9. Feels weird to deliberately install an old version of something, but when you're running Red Hat, sometimes you just have to pretend it's still 2006.

After a few hours of working with GooCanvas (from Python), I'm pretty happy with it. The install went well except that it put the Python libraries in /usr/local/lib/python2.4 instead of /usr/lib/python2.4 by default. I got a bit confused by SvgSurface (which is for output not input), but ended up using an SVG example that comes with 0.10 to make a custom SVG-based component. (The alternative was converting SVGs to PNGs on startup and then every time the scale was changed, which would have worked but seemed a bit gross.)

I see that gtkmm (C++ bindings for GTK+) is now using Cairo behind the standard GTK DrawingArea widget by default, so you don't need to scrounge up a third-party Cairo canvas. Great idea. I hope it spreads to the other GTK+ bindings.

Took a 33-mile bike ride Saturday, which is pretty normal. I rode most of it through a thunderstorm, which is not. I knew the forecast called for thunderstorms and possibly hail, but it was the last day of the month, and I had 30 logged fewer miles in the month than the previous May. So I got soaked. (Luckily nothing worse.)

Next time, I'll at least start earlier in the day. We rarely get thunder at 9 a.m.