An interesting Python programming
contest ended today. The task was to write the shortest Python module for
converting a string of digits to seven-segment display format. The module
was to be used like this:
>>> from seven_seg import seven_seg
>>> print seven_seg('0123456789')
_ _ _ _ _ _ _ _
| | | _| _||_||_ |_ ||_||_|
|_| ||_ _| | _||_| ||_| _|
Solutions were measured with the Unix command wc -c seven_seg.py.
The
shortest solution (by André Roberge, who is apparenly some kind of a
genius) is 117 characters long. My best try was this 120-character-long
one-liner of obfuscated Python:
seven_seg=lambda i,j=''.join:j(j(' _ _|_|_ | |'[ord('f\xda($\xbaDFZ64'[int(d)])>>r&14:][:3]for d in i)+'\n'for r in[6,3,0])
(Replace \xda and \xba with actual 8-bit characters, and
make sure the file has no trailing newline to get a 120-byte long file.)
There is also a 30-character-long
cheat that fools the test suite into thinking it is a valid solution:
class seven_seg(str):__eq__=id
It was fun to read about various solutions by other people in this thread
on comp.lang.python, and in other
places.
Update: Read André's Deconstruction
of the 117-character solution (with insightful readers' comments about the
Chinese Remainder Theorem).
I keep my home
directory in a Subversion repository. A month ago that repository broke
down. Subversion developers were unable to help me without access
to the repository, which I didn't want to grant, since my repository
contains some private data (Jabber account passwords and the like).
I spent a day debugging the problem until I found the cause (a loop in a
data structure). Then I was too busy to do anything, and a month went by
without regular backups. Two days ago I finally hacked a workaround and
managed to extract a nearly complete repository dump. All is well again,
except for my confidence in Subversion, which is a bit shaken.
All of my Subversion repositories now use the fsfs
format. I only had troubles with the bdb
format so far.
Backups: everyone knows they're important, but no one does them until they
lose data (or barely escape losing data, if they're lucky).
My old laptop's old hard disk almost died once, and that made me think about
backing things up. I read an inspiring article by
Joey Hess, and decided to keep most of my home directory (all the numerous
small files) in a Subversion repository on a remote server. It worked quite
well for almost a year. I changed the hard disk, got a new laptop, and
switched Linux distributions (Debian to Ubuntu), and every time all I had to
do was install Subversion and check out my home directory.
I can also check out various subdirectories (such as ~/bin, ~/.mutt,
~/.vim) on other machines, and keep useful scripts and configuration files
synchronized.
I have a shell script 'autocommit' that runs svn add and svn
commit for a few common places (Tomboy notes, Firefox profile, IRC
logs). I review changes to other and commit them manually. I have included
a large number of automatically generated junk files in svn:ignore
properties (~/.gconf falls in this category, since the diffs are numerous and
useless).
Some subdirectories are not versioned (~/img, ~/mp3, ~/src, ~/Mail). I
back up large amounts of data (such as my photo collection) with rsync. I
keep my source trees in separate repositories. I keep all my mail on a IMAP
server, and use offlineimap to
synchronize it with a bunch of Maildirs on the laptop.
I do not keep my private keys (GPG and SSH) in the repository.
Here's how I do backups:
$ backup-to-musmire
Rsync ~/img, ~/mp3 etc. to my home file server.
$ offlineimap
Synchronize all my mail folders.
$ autocommit
Commit periodically changing files to Subversion.
(The three commands above can be run in parallel)
$ svn st
See if there are any uncommitted changes. If there are,
I'll commit them separately with meaningful log messages. If there are
unknown files, I'll either svn add and svn commit them, or
I'll add them to svn:ignore.
