taps aff


taps aff: /tæps æf/, interjection

The removing of one's shirt or other upper body garments, most often in the event of warm weather but also often for purposes of celebration or simple antagonism.

 taps.af: /tæps dɒt eɪ ɛf/, website

Weather service at http://taps.af borne of a drunken evening's nonsense talk followed by Easter Sunday morning in bed learning to use CherryPy and Heroku. Given a location a one word verdict on the weather is decided: "AYE" (indicating warm weather) or "NAW" (denoting colder, more unpleasant weather)


dcraw and stdin

You may or may not have noticed that dcraw.c has a "-I" command line argument reserved for read_input_from_stdin, however it doesn't as yet do anything - when you attempt to use it you'll see that dcraw outputs "No files to process" and quits. I crafted a quick-n-dirty hack to allow you to use this functionality.

Just apply the patch to dcraw.c and you're all set:

$ cat _MG_2184.CR2 | dcraw -e -v -w -I
Writing data to /var/tmp/tmp.0.thumb.jpg ...

It's rather shoddy but it did what I wanted it to do. One happy/weird side effect of how I implemented it (writing stdin to a temp file and stuffing the filename into argv[]) is that as well as converting from stdin it will also take care of any RAW files supplied as a command line argument:

$ cat _MG_2184.CR2 | dcraw -e -v -w -I _MG_2041.CR2 
Writing data to /var/tmp/tmp.0.thumb.jpg ...
Writing data to _MG_2041.thumb.jpg ...

The reason I employed this hack rather than substituting stdin for the FILE* objects used by dcraw to open and read the files was that fseek() was used at various points, and it doesn't play nice with stdin.

iTunes: Agree to what?

I installed iTunes 11, and hit "Agree" when the all-too-familiar license agreement appeared (which may have been a bad idea) and it opened to greet me with this:

I have no idea what I'd be agreeing to if i hit "Agree", perhaps the irritating and false assertion that "iTunes is the simplest way to enjoy your favorite [sic] music, movies, TV shows and more on your computer".

Awkward Texter (SL4A/Python is fun)

Have you ever felt like there's not enough awkward moments in your life? Well I have the solution in 3 easy steps!

1. Download SL4A by doing scanning the QR code below

2. Download the Python libraries for SL4A:

3. Paste this badboy in and run

SL4A is my favourite App. Now I just need to figure out how to use the text-to-speech interface in voice conversations...

I got bored and recreated donut.c in C# (aka donut.NET)

While waiting on a release to finish, I got thinking about donut.c, then got more bored and made it in C#

Sincerest apologies to Andy Sloane, the formatting is awful and to be honest it's pretty much just his code line-for-line but in c#. I'm not sure if the worst part is my templated memset() or the nl() function (which inserts a new line in the buffer passed to Console.Write()). Hideous. It does manage to generate a passable torus rotating through two axes, however:

Blackbox on Mac OS X

Blackbox is a lightweight X11 window manager I used to use when I used linux as my main OS. The only UI elements on display by default is a small bar down the bottom to control what workspace you are using (called the "slit") and you can launch programs and configure blackbox from a menu visible when you right click the desktop:

It's quite nice to use something so uncluttered after the colourful noisy UIs I'm used to, so I figured I'd see if it's possible to use it under OS X and share the steps involved.

As a prerequisite make sure you have XQuartz installed as well as either Xcode or the Command Line Tools for Xcode. To get a working copy of blackbox you can either use MacPorts or build it from source by hand:

1a. MacPorts (easy)

First install macports, and open up a terminal window and enter the following

   $ sudo port install blackbox   

All the requisite dependencies should be downloaded for you and once it's complete you should have a functional blackbox binary installed in your system.

1b. Build by hand (less easy)

You'll likely need to download and install the following, as they're not provided by default in OS X (well one version of libtool is, but it's not what you want. To prevent overwriting this we'll use --prefix=/usr/local). I hacked together a script you can just copy + paste into your terminal (you'll need to enter your password to allow the `sudo make install` step to work.

Next grab the blackbox sources:

 $ cvs -d:pserver:anonymous@blackboxwm.cvs.sourceforge.net:/cvsroot/blackboxwm login </br>   
 $ cvs -z3 -d:pserver:anonymous@blackboxwm.cvs.sourceforge.net:/cvsroot/blackboxwm co blackbox   
 $ aclocal & autoheader && automake && autoreconf -i 
And do the standard ./configure && make && sudo make install malarkey. I ran into an odd error during ./configure where something to do with xft was dying. Running with -disable-xft didn't help, so I opted to skip it from the build by hand - you can do this by downloading this patch...

and then applying it + building:

 $ patch -P0 < fix_xft.patch 
 $ ./configure   
 $ make   
 $ sudo make install 

2. Configuration

By now you should have a working blackbox binary in /usr/local/bin. Now create an .xinitrc

 $ cat << END > ~/.xinitrc   
 export PATH   xterm &   
 exec /usr/local/bin/blackbox   

3. Launch!

Open up XQuartz, go to Preferences and tick the "Full-screen mode" box, and on your keyboard hit ⌘-⌥-a (press and hold command, option and "a") and you'll see a lovely blackbox desktop. You can use the same sequence to switch back out of XQuartz and see your OS X desktop again.

Palestine in iOS Maps

There's been a lot of criticism of the new iOS Maps app, and rightly so. However I'm not going to go down that path here. In a previous post I was puzzled by the omission of Ramallah and Bethlehem from all but the closest zoom levels of Google Maps. Well by accident or otherwise Apple have correctly identified where they are at roughly the same zoom levels.

Sadly they have also missed out about 70% of my adopted hometown of Brno's city centre - the big empty blob in the middle should be a feast of winding alleys, cobbled roads and wide squares:

Stupid Post-it Art Creator

I recently moved into a new floor in work which has giant windows - an excellent opportunity for post-it art. So knocked up a quick program in Processing (as it's easy and I'm lazy) to approximate given the fairly standard palette of colours below:

There's bound to be millions of such programs floating around the internet, but hey-ho it filled a half-hour or so. Fire up the code here into Processing and use the following controls to adjust the image. 

key action
- decrease size of postit (increasing resolution)
+ or = increase size of postit (decreasing resolution)
w toggle dark lines between postits
[mouse click] open another file

It'll display an image, together with the post-it approximation to the right, like so:

That's not particularly good, but if I hit "-" a couple of times...

... a better approximation is displayed. Based on a size of roughly 72.6mm x 72.6mm per post-it, the real world dimensions of the post-it masterpiece are dumped to the Processing console:

I just need to find a suitable pack of post-its and an interesting image, and I'm all set :)

C No Evil - In Practice

John Regehr, an Associate Professor at University of Utah, posed an interesting question recently:

Your mortal enemy would like to ship a really great product in a week or two. Towards the goal of maximally delaying this product, you may inject a single C preprocessor definition into one of their header files. What is it?

There was also an interesting discussion on HN where a number of people offered their own suggestions which ranged from cruel to downright devious. I was curious to see what would happen if you were to inject any of these into the sources of some commonly used Open Source software. Which changes would cause a catastrophic failure to run, and which cause slightly more subtle runtime errors that permit reasonably normal use (albeit with the odd confusing moment).

First I selected a couple of programs I use fairly frequently:

Application Testing
GNU grep 2.9 make check after rebuild
Python 3.2.1 make test after rebuild
Emacs 23.3 mess around a bit (really scientific, eh)

Next I selected a number of the macros to test, I picked the ones which I thought were likely to build and run fine for the most part but introduce weird isolated errors:


#define unsigned signed
#define long short
#define volatile
#define continue break
#define struct union
#define if(x) if(rand()<0.0001 && (x))


The location I chose to change was in Include/Python.h, right at the top. Either this was a bad choice or Python itself was a bad choice, because only one of the builds completed, and even then there was no effect to the results of the testing. Take a look at the screenshots for the failures, the failures are mostly at the same step in the build.

Macro Result
#define unsigned signed Build failure.
#define long short Build failure.
#define volatile Build succeeds. Tests fine too.
#define struct union Build failure.
#define continue break Build failure.
#define if(x) if(rand()<0.0001 && (x)) Build failure.

Oh well, onwards and upwards.


Again I chose one of the "included everywhere" headers - src/grep.h - and put my macros right at the top. The unadulerated grep actually fails `make check` because one test unexpected passes (word-delim-multibyte). I'll do as the message tells me to and report the failure, and for the purposes of this post I'll ignore the word-delim-multibyte failure.

Macro Result
#define unsigned signed Build succeeds. Tests fine
#define long short Build failure.
#define volatile Build succeeds. Tests fine
#define struct union Build failure.
#define continue break Build succeeds. One test (fmbtest) fails!
#define if(x) if(rand()<0.0001 && (x)) Build succeeds, all sorts of random runtime failures, brilliant!


The file I changed this time was src/s/darwin.h. Unfortunately there's no automated testing for emacs, so when it built fine I just had to play around for a while. As I said earlier, not very scientific really.

Macro Result
#define unsigned signed Build failure (executable built fine, emacs is invoked to build lisp libs and dies)
#define long short Build failure
#define volatile Build succeeds, runs OK
#define struct union Build failure
#define continue break Build failure (executable built fine, emacs is invoked to build lisp libs and dies)
#define if(x) if(rand()<0.0001 && (x)) Build failure


Well this wasn't the greatest experiment ever, I was hoping for odd random behaviour and dramatic failures. Alas I was stuck with build failure after build failure. Perhaps the problem was that I wasn't devious enough with where the macros were inserted - the locations I chose tended to affect the entire codebase. I could also have selected the programs I was testing a little better, maybe a few more with automated 'make test' steps.