Sean McLemon

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. 

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

... 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 :)

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:

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:

Python

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.

Oh well, onwards and upwards.

Grep

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.

Emacs

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.

Conclusion

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.

More messing around with primitive graphics in Processing, this time using OpenGL which I haven't touched since 3rd year at University. It's a little frightening to think that was five years ago! I thought it would be cool to see what it would look like you were to use each of the Red, Green and Blue components of a pixel's colour as it's co-ordinates across the X, Y and Z axes and plot it inside a cube.

I'll spare you the details, but this was another little one-evening job - after manhandling horrible legacy VB code all day I've rarely felt like doing anything particularly brain intensive when I get home at night. Anyway my favourite is the image comprised of a number of individual images to make a little spectrum. You can see little tendrils of alike colours arcing from one corner of the cube (0,0,0 - Black) to the other (255, 255, 255 - White):

Annoyingly something's up with OpenGL for Applets on recent-ish JVM versions so I can only embed the Applet using Processing's slightly lame P3D software renderer, which mangles the colours beyond belief. It's so ugly I'm not going to bother uploading it and embedding it on this page. You can view the video further down the page or download the program itself at the bottom of the page (to see it in all its technicolour OpenGL glory), or if you're sadistic you can download it and use the P3D renderer. Wash your eyes afterwards though. Anyway if you do download it, here are the keys to manipulate what's on screen:

The last function is a little odd, when I was having trouble with performance I started looking for ways to improve speed. After a couple of straight forward ones (no plotting duplicate points, precompute the co-ordinates rather than calling red(), blue() and green() on each point each frame) I noticed that I was creating a new shape for each vertex (i.e. beginShape(POINTS); /* add vertex */ endShape();). After a bit of playing around it turns out that the sweet spot is somewhere between 100 - 1000 points vertices per shape (this is a little vague as I've not been particulary scientific about it).

Here are some videos of a few of the images together with their rotating colorcubes. They're a tad jerky due to the capture software, it's a lot smoother when you run the actual software.

You can download the source code here, just load the PDE in Processing and run (the images used in the video demo are contained within so you don't need to fiddle around with anything).

I started playing with Processing (simple C/javascript-ish looking language which compiles to JVM bytecode) the other night. After scanning through the tutorials, I started messing around with a very primitive algorithm to approximate an input image by continually randomly drawing triangles on screen (discarding any which make the screen less like the input)

Think "Infinite Monkey Theorem" but with only a single monkey, and I whack him with a rolled up newspaper when he types something incorrect. OK that was slightly contrived, and not particularly accurate but who amongst us can resist a good "spank the monkey" metaphor?

To test things out I wanted to keep things simple by using a monochrome and contrasty image, so my first input image was a picture of a West Highland Terrier I took with my Kiev 6C on some cheapo Chinese black & white 120 film.

The first attempt was less than successful. I killed it off after a while, as it started to look a little eery.

Whoops, the problem was that only pure white or pure black triangles were drawn, so anything which wasn't white or black tended to be shaded with lots of thin spikey polygons. Let's try with a few more colours:

Once I was a confident that I was able to produce a reasonable image I messed around with full RGB colour, and with circles instead of triangles. Here's a few more images (click to embiggen):

Of course these pale in comparison to some of the things other people have created with Processing. It does just look like I've run images through a crude Photoshop or GIMP filter, but all the same I was impressed with how easy it was to get proficient enough to do this - a couple of hours at most. Code available here.

I've been using "Modify Headers" firefox addon for a while to watch US shows for research purposes, but until now I've never really questioned how it works. If you've never used it for watching South Park whenever the hell you want such research you can explore what it's about by downloading the addon here and configuring it as below:

This will insert an "x-forwarded-for" HTTP header (used by some proxies to identify the IP address from which the packet originated) with the specified value into each packet sent from firefox. Thankfully some sites, like Comedy Central, use this header to determine whether or not you're in a locale which is allowed to see their shows. This means that if you employ the hack outlined above, when you fire up http://www.thedailyshow.com/ instead of the familar "GO AWAY, BRITAIN"...

we get Jon Stewart's cheeky grin (in this case, unfortunately, accompanied by the sinister Paul Ryan):

The address I used, 12.13.14.15, is suggested by many of the sites describing how to do this. It's inside Bell Labs' IPv4 allocation and is presumably chosen as Bell are as American as Apple Pie (or at least they were before being bought out by Alcatel-Lucent) and would therefore be useful in a scenario where someone is masquerading as an American.

But is it only Americans who are permitted such unfettered access to Comedy Central's quality programming? I used XKCD's excellent map of the IPv4 space to select some IPs to use with the x-forwarded-for hack, and tested them with The Daily Show's website. The "Block" column in the table reflects the annotation it is given in the XKCD map:

Some obvious results (US companies, Canada), weird ones (Africa, Japan and Europe?) and couple of interesting entries (Multicast is OK, but Loopback and Local are not). Particularly troubling, however, is the final entry in the table. We can only hope this is resolved before word makes it to Chuck Himself...

Why, Haskell? We've been getting along so well, why you gotta play me like that? 

Couldn't match Int with Integer eh? Aggh just give it a try! Throw caution to the wind for once!

Perhaps the below, a separate program excreted late last night, is why we're struggling to get along. Beer + all day using VisualBasic = far too much enthusiasm for "concise" one liners in Haskell. Oh and unsurprisingly it didn't work.