I have been using a Palm Pre (Plus) for a while. It is a great device; the form factor is excellent with a hardware keyboard and I really like WebOS. Unfortunately, the build quality is not so great so it always felt a bit cheap. Additionally, it was also always kind of on the slow side (it took much longer for it to render HTML than it took to download it, and many other operations were slower still).

HP basically killed off WebOS and there is no new hardware on that front, so that basically left me to choose which Android phone I wanted. Luckily, AT&T was gracious enough to push the release date of the HTC One X until after Samsung’s Galaxy S III launch event so I could see what the big two had in store this year. Also fortunately, Samsung’s offering was disappointing enough that I could jump on the HTC One X without reservations. HTC definitely won on the design front and the internals were close enough to not matter to me. Samsung’s only advantage was including a microSD slot, but my on-phone storage needs are modest enough for that to not factor into my calculations at all. Also, based on my interactions with Galaxy Nexuses, the One X screen is much nicer.

Initially, I was a bit worried about getting a phone this large. Fortunately, my hands are large enough to deal with it. I never want to see a phone larger than this 4.7 inches, though. Despite its size, it actually feels lighter than my Pre did, which is pretty weird. As everyone else has noted, the screen is stunning and far crisper than any SuperAMOLED screen I’ve ever seen. The phone is also very fast. Coming from my Pre, it is like night and day. I’m not used to seeing such responsiveness in a mobile device.

Many people expressed concern over the battery life. My usage patterns are probably weird (I don’t want notifications and I don’t poke at it every few minutes), so I can get three full days on a charge. The non-removable battery doesn’t bother me – I only removed the battery in my Pre once and that was to get it to reboot after a lockup. I suppose most of the battery life comes from Ice Cream Sandwich being pretty smart and the newer manufacturing process in the newer Snapdragon chips. Battery life was my biggest concern when upgrading to a modern phone and I am pleased that such concerns were completely unfounded.

As for software, I never used any prior versions of Android. I also haven’t had many interactions with stock ICS, so I can’t really make any comparisons to other Android versions. I do see why some people complain that Android is a bit inconsistent and scattered compared to WebOS. I think I even agree with that assessment, but I think it is mostly because Android just provides so many more features and so much more configuration options than WebOS. Part of the reason WebOS could be so simple and consistent was just that there was less to do and fit on screen. I haven’t had any trouble adapting to ICS (with HTC’s Sense mods). I’ve read that Sense used to be a gaudy monster, but the ICS version doesn’t seem to have any problems like that. Everything also seems much more polished and featureful than WebOS, which isn’t surprising considering the disparity in resources applied to the two systems.

Overall, I am quite happy with this phone. Good job HTC.

Lately, I have been making my presentation slides with LaTeX beamer. I use SVGs created with inkscape (and my handy wacom tablet) for most diagrams and the minted package (which eventually calls pygments) for syntax highlighted source code listings. This combination works well and produces very nice PDFs that I can present with evince.

Unfortunately, the compile time for a large presentation is excessive and makes incremental updates a bit of a pain. It is also wasteful since I am not using many of the good things that TeX provides (I try to minimize my reliance on bulleted lists and math in slides). Many of my slides are just SVG diagrams converted to PDFs.

I decided that I needed a bit of a change, so for a short presentation I am giving soon I decided to use HTML + Javascript for my slides. I am not a huge fan of web technologies or doing much of anything in a web browser, but if most of my slides are SVGs surrounded by a bit of colored text, that is halfway to a web page anyway. Looking around, I saw a few options:

• The classic s5
• A relative newcomer, prezi
• The similarly flashy impress.js
• deck.js

I remember using s5 once in undergrad. It works but isn’t particularly impressive. prezi is really neat, but it requires using some web-based editor and is based on flash, which make it obviously a no-go. impress.js produces very nice results. It takes a different approach from a slide-based presentation; your entire presentation lives in a big poster and the viewport zooms around to different sections, subject to various scaling and rotation transformations. The effect is very slick, but distracts somewhat from the content. I don’t think it is particularly suitable for any technical content. It would probably go over well for some kind of sales fluff-piece presentation, though. The additional effort of manually arranging each slide in the plane of the poster is also a bit more than I would want to deal with.

I decided to go with deck.js, which uses a more traditional slide-based scheme. At the end of the day, it really is a lot like LaTeX beamer in your browser. I threw in highlight.js to highlight my source code snippets, and I can directly embed SVG graphics without conversion. I’m very happy with the results, and it doesn’t require any fancy LaTeX hackery to safely work with fragile slides. It even has a nice navigation overview that you can bring up with the ’m’ key to randomly jump between slides. This setup has the additional advantage of being able to use any HTML-friendly content, including forms, javascript, iframes, and embedded videos without having to switch away from the slide viewer. Styling is also a bit easier with CSS than beamer’s lightly-documented internals.

I have to see how it performs at presentation time, but it seems to be perfectly acceptable. Now I have to try it with a more complex presentation.

I finally feel like a real programming languages person. I just used unification to solve a problem besides type checking a variant of the lambda calculus. I used the excellent unification-fd package; it is a bit light on documentation but the included tests were enough for me to figure out how to use it. I might post something more detailed later on.

My problem arose due to the type system rewrite in LLVM 3.0. Prior to this, types were all uniqued: there was one instance of each structurally equal type. This is no longer the case. Each struct type is named and there can be multiple structs with the same structural type. That is fine and actually closer to what I always wanted. Unfortunately, sometimes different names are assigned to the same type in different compilation units (the duplicates have the same base name but a numeric suffix). Unfortunately, types sharing a name are not always the same – some libraries actually do re-use type names for different types in different compilation units.

Example of the first case:

%struct.glp_long = type { i32, i32 }
%struct.glp_long.0 = type { i32, i32 }

Example of the second case:

%struct.csa = type { %struct.glp_prob.10*, %struct.glp_bfcp.8, ... }
%struct.csa.556 = type { i32*, double*, i32*, double* }

The first type is expected to unify, while the second is not. I used this to pick a representative type for the first case and to treat each type name used in the second case as opaque. Oddly enough, everything worked the first time I ran it. I noticed that some types I expected to unify did not (e.g., the glp_prob and glp_tree types in glpk). It turns out that the library (intentionally?) does not always include the correct headers to define types. In those cases, it uses the C preprocessor to just define them to be

struct foo { double _opaque_foo[100]; };

This is a bit annoying, but I managed to work around it outside of the unification framework. I’m not sure why they don’t just forward declare types like normal libraries.

I just put the code for this blog up on github. This gives me another backup and could serve as an example for how to use Hakyll. One more example of Hakyll 3 never hurt anyone.

I enabled IPv6 on the machine hosting this blog a few months ago, but I hadn’t actually tested it. In fact, I don’t have any other hosts with IPv6 support so I can’t really test it myself. Since World IPv6 Day is coming soon, I decided it was time to get things working.

Looking around, I found an IPv6 website validator, which actually let me figure out if things were working out. There were just two problems:

• My AAAA DNS record didn’t transfer automatically when I switched from GoDaddy
• My web server supported IPv6 but wasn’t listening on any IPv6 interfaces

I guess I am ready for the future now. Maybe I’ll even be able to test my IPv6 support personally one day.