About

I'm Nicholas FitzRoy-Dale, a software developer from London, UK. I'm interested in embedded systems and operating system research, code optimisation, 8-bit music, rock climbing, shiny things...

Personal blog

Contact

Thu
Aug 28

Short Chromium rant

In 2011, Google announced plans to remove H.264 from Chrome. They were terrible plans with no practical upsides for anybody apart from Google. H.264 is used everywhere, and three years later Chrome still supports it.

What is gone, though, is Chromium’s support for H.264. If you use Chromium you have to compile in support for the Web’s most popular video codec. So I did that — it’s not at all hard, just time-consuming. If you’d like to save yourself the pain, and use a Mac, I’ll send you a copy.

Wed
Jun 4

My favourite joke from the Swift documentation so far

let constantString = "Highlander"
constantString += " and another Highlander"
// this reports a compile-time error - a constant string cannot be modified

Mon
May 12

Evening hack: multiheaded Nokia 3310 displays

I know, I know, 84x48 pixels should be enough for anybody. But I just find that I’m so much more productive with the extra space.

SPI Flash programmer for Arduino

I’ve released an SPI Flash programmer sketch, along with a Python driver library (written for Python 3). It requires pySerial. Full docs are available on Github:

https://github.com/nfd/spi-flash-programmer

This isn’t particularly nice code, but I couldn’t find a usable SPI programmer sketch when I wanted one. This one has been tested on a couple of chips and should work, but let me know either way if you use it. 

One thing it doesn’t support is the extended command set for large SPI Flash chips, so for now it only works with chips up to 16MB.

Sun
May 11

Call-by-name semantics

I’ve been playing around with call-by-name semantics recently, and they’re kind of interesting. This post is about function calling behaviour, and I’m not an expert in the field, so I apologise in advance if I get some of this wrong. (Please point it out to me if I do.)

Most programming languages use call-by-value or call-by-reference semantics, or some combination. Under call-by-value semantics, when calling a function, each argument passed to the function is first evaluated. The values are then supplied to the function. So, for example, using a lisp-like language I’ve been playing with, here is a definition of a function called add1. It takes one argument, named lhs. When it’s called, it adds 1 to its parameter and returns the result.

(def add1 (lhs) (
(+ lhs 1)))

If you were to call it like this:

(add1 (* a 2))

… then, under call-by-value semantics, here’s what happens
  1. The expression (* a 2) is evaluated, yielding an integer (presumably).
  2. That integer is passed to “add1” and bound to “lhs”.
  3. add1 executes, adding the value of lhs, which is just an integer, to 1.
Call-by-name, however, behaves differently. Under call-by-name, function arguments are not evaluated immediately prior to the function call. Instead, the function can choose to evaluate them whenever it likes — it can also not evaluate them, or it can evaluate them more than once. Here is what happens during a call to to add1 if you rewrite it to use call-by-name semantics:
  1. The expression (* a 2) is compiled to a thunk, which is a parameterless closure — it’s a callable thing (i.e. it is code which produces a value), which retains the scope of wherever it was defined.
  2. A pointer to the closure is passed to add1.
  3. add1 evaluates “lhs”, which results in an integer.
  4. add1 adds the result of the evaluation to 1 and returns it.
On the face of it, this seems a lot more work for little gain. But thunks capture the scope of wherever they are defined, which means you can do very cool things. For example, you can implement iterators by having your expression return different things each time it’s evaluated. You can also implement control structures. For example, logical AND and OR are short-circuiting operators, which means they don’t evaluate their second parameter if they don’t need to. So you could implement them as taking their second parameter by-name. Here’s an example for “or”, where “>” is syntax for by-name calling, and “if” takes three arguments, being an expression, a list of expressions to evaluate in the true case, and a list of expressions to evaluate in the false case:

(def || (lhs >rhs) (
(if lhs (true) (if (rhs) true false))))

Note that rhs has parentheses around it to evaluate it, whereas lhs doesn’t.

Of course, what actually gives call-by-name its power is closures. But it’s quite interesting to see that call-by-name gives you quite a lot of the the same power without ever exposing closures to the programmer. By-name parameters let the function author choose whether arguments are evaluated eagerly or lazily.

There are two downsides to call-by-name.

Firstly, it’s quite a lot of overhead. Some of this can be ameliorated in the compiler, but I do recognise that “this isn’t a problem given a sufficiently powerful compiler” is a hymn which has been sung for a long time now.

Secondly, it’s potentially terribly confusing if you don’t realise what’s going on. For example, if you pass a side-effect-generating argument as a by-name parameter, then it will possibly be evaluated more or fewer times than you’d like. That seems fine for implementing simple, well-known things such as short-circuiting Boolean operators, and even for implementing complex, well-known control structures such as, for example, generators, but it’s probably not really a good idea for any other reason.

ALGOL was entirely call-by-name. Simula and Scala support it in roughly the above way (by annotating function arguments). Someone on the c2 wiki reckons that the C preprocessor is an extreme form of call-by-name. And of course you get some approximation of it in any language which lets you define closures.

Fri
Apr 11

Walter Bright on making programming languages

Hacker News has been on a bit of a Walter Bright (creator of D) festival recently, which is fine as he seems pretty great. Two articles of his from Dr. Dobbs:

So you want to write your own language?: “Redundancy is important” — Walter makes the point that a truly non-redundant syntax would mean that anything was valid and it would be impossible to generate error messages. So syntax redundancy is actually very useful. He also recommends not using a parser generator, also in the name of good error messages: parser generators aren’t very good at them. (I’d argue that hand-written parsers aren’t usually very good at them either but I guess you probably do have a better chance of adding them.) Other interesting parts of this article are error-message poisoning (he’s big on error messages) and the concept of lowering as proof of design (and a way to simplify the implementation).

How I came to write D: "In 1999, I decided I was retired and spent about six weeks watching TV until I thought I'd go mad.” (This isn’t what motivated him to write D, it’s what motivated him to stop not writing D.)

Thu
Jan 23

AOSP: emulator: don't copy the system image

The Android emulator seems to insist on copying the system.img file somewhere else (into /tmp/emulator-$USER on my system) before starting up. This is pretty annoying because the system.img file is 550 megabytes and it takes a while to copy.

The code doesn't quite know what it wants: there is the concept of an “initial system image” and a “rw system image”. If you create a file called system-qemu.img in the same directory as your system.img (i.e. in out/target/product/generic-whatever/) (or do what I did, and ln -s system.img system-qemu.img) then one part of the emulator will be happy to proceed without an initial image, using system-qemu.img only… but the Android initialisation portion will complain that there is no initial system image!

I guess all of this makes sense if you're supporting AVDs and don't want the system image corrupted, but if you're actually working on the system image it's a bit of a time sink.

You don’t need an initial system image. If you screw up the rw image you can fix it using make snod. To stop the complaints:

aosp/external/qemu$ git diff
diff --git a/vl-android.c b/vl-android.c
index 4b0c991..3b35a63 100644
--- a/vl-android.c
+++ b/vl-android.c
@@ -3601,7 +3601,7 @@ int main(int argc, char **argv, char **envp)
             pstrcat(tmp,sizeof(tmp),",initfile=");
             pstrcat(tmp,sizeof(tmp),initImage);
         } else {
-            PANIC("Missing initial system image path!");
+            VERBOSE_PRINT(init, "No initial system image specified. Ho hum");
         }
         if (android_hw->hw_useext4) {
             /* Using a nand device to approximate a block device until full


I haven't tested this for very long, so maybe it will break everything. As a precaution, you might want to remount as ro before quitting the emulator if you make any changes to /system (i.e. if you have previously done an adb remount): adb shell mount -o remount,ro /system.
Wed
Jan 22

WhatsApp: fake contacts



Natanji has created a tool to privacy-enable WhatsApp based on my Viber-hacking tutorial. Cool! 

(I haven’t tried it yet, but I want to)

Mon
Dec 30

Five-minute AOSP hack: remove proximity sensor support

I recently dropped my Nexus 4 and broke its LCD. If replacing this £85 part wasn’t annoying enough, I also managed to lose the tiny rubber part which makes the proximity sensor work. Without it, the LCD turns off, and stays off, during phone calls. (Actually, I didn’t break the LCD — I just cracked the front glass — but I had to buy a new LCD + glass + digitiser assembly anyway.)

Fortunately, the proximity sensor sucked even before I broke it. :) I don’t press phones right up to my face, so talking is often a flickery screen-on, screen-off business anyway. So I hacked AOSP to ignore any hardware-supported proximity sensors.

With this change, you can control the LCD normally using the power button, even during phone (or Skype, etc) calls.

wzdd@ubuntu:~/aosp-nexus4/frameworks/base$ git diff
diff --git a/core/java/android/hardware/SystemSensorManager.java b/core/java/android/hardware/SystemSensorManager.java
index 0204e94..9dd8d7f 100644
--- a/core/java/android/hardware/SystemSensorManager.java
+++ b/core/java/android/hardware/SystemSensorManager.java
@@ -265,7 +265,7 @@ public class SystemSensorManager extends SensorManager {
                     Sensor sensor = new Sensor();
                     i = sensors_module_get_next_sensor(sensor, i);
-                    if (i>=0) {
+                    if (i>=0 && (sensor.getType() != Sensor.TYPE_PROXIMITY)) {
                         //Log.d(TAG, "found sensor: " + sensor.getName() +
                         //        ", handle=" + sensor.getHandle());
                         fullList.add(sensor);
Wed
Oct 30

Five-minute AOSP hack: dismiss voicemail notification

My Android device (a Nexus 4) won't let me dismiss the voicemail notification icon without actually clearing the voicemail. This is pretty annoying, particularly since either my phone provider (Three UK) or my device sometimes gets it wrong and tells me that I have voicemail when I don't.

If you're compiling your version of Android from the AOSP source code (and I realise this means almost nobody) you can change this by removing the piece of code in the phone app which tells Android not to let you dismiss the notification. Here's a patch against 4.2.2:

wzdd@ubuntu:~/aosp-nexus4/packages/apps/Phone$ git diff
diff --git a/src/com/android/phone/NotificationMgr.java b/src/com/android/phone/NotificationMgr.java
index 42dcdb6..906ba61 100644
--- a/src/com/android/phone/NotificationMgr.java
+++ b/src/com/android/phone/NotificationMgr.java
@@ -1283,7 +1283,7 @@ public class NotificationMgr implements CallerInfoAsyncQuery.OnQueryCompleteList
             if (vibrate) {
                 notification.defaults |= Notification.DEFAULT_VIBRATE;
             }
-            notification.flags |= Notification.FLAG_NO_CLEAR;
             configureLedNotification(notification);
             mNotificationManager.notify(VOICEMAIL_NOTIFICATION, notification);
         } else {

Remember to envsetup and lunch. Then you can patch and "mmm packages/apps/Phone", then copy the new Phone.apk (from out/) to the device.

4.4 update: For Android 4.4, it all changed:

  • Modify packages/services/Telephony/src/com/android/phone/NotificationMgr.java
  • mmm packages/services/Telephony/
  • Install out/target/product/hammerhead/system/priv-app/TeleService.apk