I had some automatically code generated files that I wanted to mark as read-only. I knew it was possible to flag a file as read-only in both emacs and vim. However, I found it really hard to Google for the exact syntax.

In Vim, the flags go in the file’s “modelines“, which by default can go anywhere in the first or last five lines of the file:

// vim:set ro:

In emacs, there is the “local variable list“. Sometimes known as the “magic first line” or the “file mode line”. This is a list of variables to set when the file is opened. So for a read only file, set the buffer-read-only variable:

// -*- buffer-read-only:t -*- 

This only works on the first line of the file. There’s a different form for the end of the file, follow the link to see details.

Here is a first line that flags the file as read only in both emacs and vim:

// vim:set ro: -*- buffer-read-only:t -*- 

The code generator now automatically adds this line to generated C++, Erlang and Java files, in order to prevent accidental edits.

I first read about the Engineyard Programming Contest yesterday and I thought it was a silly contest, winnable only through the application of raw brute force.

For some reason, I woke up this morning obsessed with it. This is despite the fact that this “competition” is basically a lottery, in which you buy tickets with basic programming skills and large amounts of computing time.

In the spirit of sharing, I have a few (fairly obvious) things I’ve noticed in an evening of messing around.

I’m not any kind of cryptographer, but from what I know about the known weaknesses in SHA-1, none of them will apply significantly to this contest. Maybe I’m wrong though.

The Avalanche effect means you don’t have to change much in the input to see a big change in the output. So making large changes (whole word permutations) is a waste of cycles.

Permutating the word list at all is almost unnecessary. One core on my 2.2Ghz Macbook pro takes 45 minutes to check all 7.7 billion combinations of printable five-character strings for a single word list combination. Once you add the possibilities for varying capitalisation in a single sentence (at least 2^40), you have more permutations in a single word list string than a single core can run in many times the 30 hours of test time. So distributing word list permutations is, at most, the “top level” job to distribute work to each cpu.

SHA-1 uses 64-byte blocks so if your total string is more than 64 bytes and the first 64 bytes don’t change, you can calculate that hash separately just once. Testing on an 85-character test string (the one from the competition blog posting), this got me from 1.6 million hash checks per second per core to 2.5 million/second/core.

Using gcc’s __builtin_popcount() and/or the x86 popcntl instruction lets you compute hamming distance in a handful of instructons.

None of this matters at all, although it’s fun to think about. Even with all these optimisations, I still have at most 16 cores (work and home) to run this on. The winner will have hundreds or thousands of parallel cores at their disposal.

Programming skills seem to only play a minor part. Several hours of optimisation only yielded me a 60% improvement compared to my original naive C program. Although, one of the posters on HN suggested he was only getting a tenth of that performance, which suggests a combination of language choice and savvy performance design may be statistically significant in the long run.

I will laugh if the winner is a shady programmer with a medium sized botnet as his or her disposal.

Does anyone have any more optimisations to share? Despite it being kinda pointless, I find this kind of thing really interesting. I honestly don’t plan to enter, except for maybe out of curiosity to see how close a single consumer computer can get to the winning results.

I recently bought a couple of cheap MG996R high-torque servos on ebay, and I want to use them with my Arduino.

Arduino + MG996 + Dusty Breadboard

These have the “JR” servo pinout, so orange = signal, red = V+, brown = V-.

You control these servos by sending a 50Hz pulse width modulated signal. The pulse width determines the position of the servo. Arduino wraps this in a nice Servo library. So you can just use servo.write(<angle>) to set the servo to a certain angle. Cool!

The servo library defaults to pulsing 544ms to 2400ms for angles zero to 180. This is too wide for the MG996R, the servo only moves when you write angles through 20-150 or so. Setting the value outside this range stresses the servo and can wear it out!

I wrote a quick sketch to interactively find the real minimum and maximum values: . You just watch the serial port and follow simple prompts:

Download the sketch here.

Servo Range Sketch (running)

Using that sketch, I found my MG996R servos to have minimum pulse width around 771 and maximum around 2193 when running off 5v1. The full sweep is approximately 0-130 degrees.

So, to use the servo library with correct angles the sweep will be 771 to 27402. So I can call:

servo.attach(servopin, 771, 2740);
servo.write(0); // Min
delay(2000);
servo.write(65); // Midpoint
delay(2000);
servo.write(130); // Max

Note: If setting up the Servo range like this, it’s important not to drive the servo past 130 degrees – which corresponds to pulse width 2193 and the maximum position of the servo.

EDIT 2018: Fixed a nine year old bug in the formula above, thanks Dillon and Stavros for pointing it out.

Yay Arduino!

  1. While the servo is unloaded I’m powering it from the Arduino via USB, but this won’t supply enough current for a loaded servo. []
  2. The adjusted max of 2740 is calculated as ( (MaxPW – MinPW) * (180 / MaxAngle) ) + MinPW, ie ( (2193 – 771) * (180 / 130) ) + 771 []