My lovely girlfriend now wife and I have attended the first four days of Buschenschanksprint 2011, in the beautiful hills and vineyards of Berghausen, in Styria, Austria.

We had some great time, visited some Buschenschänke, and, of course, wrote a lot of code. I mostly worked on code that was related to the project I’m working on. Nevertheless, during the sprint we’ve implemented a new library, a YAML connector for the YAFOWIL form/widget library, called yafowil.yaml. I also contributed a patch to rod.recipe.appengine, which is already publisted on PyPI.

We’ve also fixed a few small bugs in cone.app and cone.tile, AnneGilles and rnix improved the documentation/tutorial, Gogo worked on the axg stack, and AnneGilles showed us a tutorial on their new S3-compliant database.

This was the sprint location…

…and this was the view from the location.

Inspired by Ivan Vanderbyl’s implementation, I also put together a progress bar, in pure CSS. The transition of the blue bar is also done with CSS, only the text is being updated with JavaScript. The animation is done using JavaScript to make sure it synchronizes nicely with the percentage text. It is also possible to animate it with pure CSS though.

The full code is in one simple HTML file, available in the public domain. Demo code can be found here.

Tested with:

• Chromium/Chrome 12
• Firefox 4
• Opera 11
• Android Browser (Froyo, with minor style glitches)

Today I had some free time, so I played around with the OpenStreetMap API. It turns out it’s quite easy to draw 3D-looking buildings on a canvas. After an hour or two of coding, I was able to render actual buildings from the OSM database:

Buildings rendered on a canvas

On the above picture, red buildings are “primary” ones (i.e. ones with an address or a house number), while the grey ones are “secondary”. A demo version of the canvas map can be seen here (but only by people with decent browsers).

As a comparison, here’s how Mapnik renders the same data:

Same map rendered by Mapnik

Even nicer is the result when it is drawn over Mapnik’s tiles:

The two images merged together

The above result could be improved by not rendering any of the buildings by Mapnik, only the ground, & the roads. Then the canvas renderer could just place everything else on top of the Mapnik layer (including amenities and other interactive elements).

While maps rendered on the server side are more compatible with old browsers, canvas-based maps can be made more interactive (e.g. hovering or clicking on a building could highlight it and pop up a message with the complete address or relevant information). Other projects, such as Cartagen, are capable of rendering a high variety of objects, not just buildings, but they still require a lot of improvements, for example the display of road names is note very optimal.

Hopefully, as more browsers support HTML5 and canvas by the day, people will implement great interactive applications using this technology.

Yesterday I figured I’ll try to factor the first few numbers greater than 10¹⁰⁰⁰⁰⁰⁰⁰⁰ (or at least find their smallest divisors). The idea was to see how hard it is to find the divisors of the first few hundred 100,000,001-digit numbers.

I took a pretty simple approach: for each prime number p, calculate 10¹⁰⁰⁰⁰⁰⁰⁰⁰%p (the remainder after dividing by p). Then I used the result to create a partial sieve. After the first 300,000 primes, I still couldn’t find a divisor for 10¹⁰⁰⁰⁰⁰⁰⁰⁰+37.

Update

10¹⁰⁰⁰⁰⁰⁰⁰⁰+37 is divisible by 6,870,527 (the 468,407th prime). The next one without a known divisor is 10⁹⁹⁹⁹⁹⁹⁹⁹+69 (tried to divide by the first 2,348,559 primes, no factors found so far).

Here’s the smallest prime divisor for the first few 100,000,001-digit integers (I = 10¹⁰⁰⁰⁰⁰⁰⁰⁰):

.------------------.
| number | divisor |
---------+----------
|      I |       2 |
|  1 + I |   10753 |
|  2 + I |       2 |
|  3 + I |       7 |
|  4 + I |       2 |
|  5 + I |       3 |
|  6 + I |       2 |
|  7 + I |     113 |
|  8 + I |       2 |
|  9 + I |     197 |
| 10 + I |       2 |
| 11 + I |       3 |
| 12 + I |       2 |
| 13 + I |      29 |
| 14 + I |       2 |
| 15 + I |       5 |
| 16 + I |       2 |
| 17 + I |       3 |
| 18 + I |       2 |
| 19 + I |    2087 |
| 20 + I |       2 |
| 21 + I |      11 |
| 22 + I |       2 |
| 23 + I |       3 |
| 24 + I |       2 |
| 25 + I |       5 |
| 26 + I |       2 |
| 27 + I |      37 |
| 28 + I |       2 |
| 29 + I |       3 |
| 30 + I |       2 |
| 31 + I |       7 |
| 32 + I |       2 |
| 33 + I |      17 |
| 34 + I |       2 |
| 35 + I |       3 |
| 36 + I |       2 |
| 37 + I | 6870527 |
| 38 + I |       2 |
| 39 + I |     139 |
| 40 + I |       2 |
| 41 + I |       3 |
| 42 + I |       2 |
| 43 + I |      11 |
| 44 + I |       2 |
| 45 + I |       5 |
| 46 + I |       2 |
| 47 + I |       3 |
| 48 + I |       2 |
| 49 + I |      13 |
| 50 + I |       2 |
| 51 + I |      71 |
| 52 + I |       2 |
| 53 + I |       3 |
| 54 + I |       2 |
| 55 + I |       5 |
| 56 + I |       2 |
| 57 + I |      31 |
| 58 + I |       2 |
| 59 + I |       3 |
| 60 + I |       2 |
| 61 + I |      59 |
| 62 + I |       2 |
| 63 + I |  399389 |
| 64 + I |       2 |
| 65 + I |       3 |
| 66 + I |       2 |
| 67 + I |      17 |
| 68 + I |       2 |
'------------------'

A while ago I wrote two widgets for awesome. Later on I’ve added a little more look&feel to my awesome desktop.

Compositing

Very easy, via xcompmgr. I don’t like the huge default shadows (nor pretty much any of the default settings), so I start it from my rc.lua like this:

awful.util.spawn("nautilus -n")
awful.util.spawn("xcompmgr -c -C -f -F -D 2.5 -l -2 -t -2 -r 2 -o 0.25")

Note that I need to start nautilus before running xcompmgr, otherwise tha background won’t word. Passing -n to nautilus will get rid of the desctop icons. Now I get to see the GNOME desktop background instead of my awesome background image, but it’s easy to change using the gconf-editor.

A shiny new GTK engine

While there, I also set up a new GTK engine. For a while I was using the Aurora GTK engine, but I wanted something simpler. Then I stumbled upon the Equinox GTK engine. Simple and nice. The tooltips are very similar to my awesome’s color theme. The buttons are smaller, good for laptop screens. With the light shadows and fading provided by xcompmgr, this engine looks great and works really well with awesome.

GTK Equinox theme

Neutral Plus cursor theme

This is probably the best looking cursor theme in awesome. It’s very similar to the default X cursor theme, so it is unnoticable if an app doesn’t support Xcursor and falls back.

Easy to install, just add this to your ~/.Xresources:

/* Cursor theme: */
Xcursor.theme: Neutral_Plus

Color theme & font settings for urxvt

My ~/.Xdefaults looks something like this:

/* Fonts: */
URxvt*font:             xft:Bitstream Vera Sans Mono:pixelsize=12:autohith=true:antialias=true
URxvt*boldFont:         xft:Bitstream Vera Sans Mono:pixelsize=12:bold:autohint=true:antialias=true
URxvt*italicFont:       xft:Bitstream Vera Sans Mono:pixelsize=12:italic:autohint=true:antialias=true
URxvt*bolditalicFont:   xft:Bitstream Vera Sans Mono:pixelsize=12:bold:italic:autohint=true:antialias=true
/* Colors: */
URxvt*colorBD:          #ffffff
URxvt*foreground:       #b2b2b2
URxvt*background:       #000000
URxvt*color0:           #303030
URxvt*color1:           #b21818
URxvt*color2:           #18b218
URxvt*color3:           #b26818
URxvt*color4:           #1818b2
URxvt*color5:           #b218b2
URxvt*color6:           #18b2b2
URxvt*color7:           #b2b2b2
URxvt*color8:           #686868
URxvt*color9:           #ff5454
URxvt*color10:          #54ff54
URxvt*color11:          #ffff54
URxvt*color12:          #5454ff
URxvt*color13:          #ff54ff
URxvt*color14:          #54ffff
URxvt*color15:          #ffffff
URxvt*underlineColor:   #b26818
/* Borders: */
URxvt*externalBorder:   0
URxvt*internalBorder:   0
/* Scrolling: */
URxvt*saveLines:        12000
URxvt*scrollBar:        false
URxvt*scrollTtyKeypress:true
URxvt*scrollTtyOutput:  false
URxvt*scrollstyle:      plain
URxvt*secondaryScroll:  true
/* Misc: */
URxvt*loginShell:       false
URxvt*urgentOnBell:     true
URxvt*fading:           30
URxvt*shading:          15
URxvt*transparent:      false

This may have been obvious to others, but I have just found out that in Python, when Exceptions get raised, they are converted to strings. That is:

>>> class C(object):
...     __str__ = lambda s: '<C: str>'
...     __repr__ = lambda s: '<C: repr>'

>>> c = C()
>>> exc = Exception(c)

>>> exc
Exception(<C: repr>,)

>>> repr(exc)
'Exception(<C: repr>,)'

>>> str(exc)
'<C: str>'

And now comes the interesting part:

>>> raise exc:
Traceback (most recent call last):
...
Exception: <C: str>

The traceback displays the Exception class’s name (__class__.__name__), and the parameters passed when instantiating the exception, converted to string (str())! The same thing happens in both Python 2 and Python 3.

The thing is, I’d expect repr() instead of str(). But good to know how it works. If I want to see consistent output in both pdb and tracebacks, I just need to use classes where str(obj) == repr(obj), that is, obj.__str__ is obj.__repr__.