There should be an app for that pt. 92

Sometimes you install an app for your phone that works well and does what it says on the tin. At a later date you install an update which introduces some serious problem that turns your phone to a slow, creaking, unusable heap of crap (Roaming Angel from Orange, I'm looking at you) or simply removes all the useful functionality (I'm told this happened to First Direct banking on the go).

The app's "star rating" in the marketplace might appear average, but if you look in more detail you'll see the ratings are almost all polarised, giving either one or five stars. If you look into it in even more detail you'll see that the older reviews give it five stars but all the recent reviews give only one star. The app has rotted.

App stores should weight ratings so that every time the app is updated all older ratings have less weighting than ratings since the update. Another alternative would be to show a chart of ratings against time, so you can tell if the rating is dropping over time and see at a glance that the average rating dropped suddenly at a particular time.

But that wouldn't help existing users of the app, who are unlikely to go and check the popularity of apps they've already installed, and may not realise which app update made their phone slow to a crawl. Someone should write an app that tracks the rating of all your installed apps and warns you if any of them suddenly gets worse according to the reviews in the app store, so you can remove the rotten apps. The app should be called Rotten Apps (Rotten Apples is unlikely to get past the censors in Cupertino) or Approbrium. You're welcome. I'll accept royalties for this idea in cash or beer.

Hey, C++ programmers, stop writing Strict Weak Orderings by hand for your classes.

For two members it's manageable:

bool operator<(const Widget& l, const Widget& r)

{

  if (l.x < r.x)

    return true;

  if (r.x < l.x)

    return false;

  return l.y < r.y;

}

But for three members it starts to get tricky:

bool operator<(const Widget& l, const Widget& r)

{

  if (l.x < r.x)

    return true;

  if (r.x < l.x)

    return false;

  if (l.y < r.y)

    return true;

  if (r.y < l.y)

    return false;

  return l.z < r.z;

}

If you think that's not tricky, are you sure I got it right? Maybe I put in a deliberate mistake. Maybe it wasn't deliberate. Now consider that everyone who writes that does it slightly differently e.g.

bool operator<(const Widget& l, const Widget& r)

{

  return l.x < r.x ? true : r.x < l.x ? false : l.y < r.y ? true : r.y < l.y ? false : l.z < r.z;

}

Or even:

bool operator<(const Widget& l, const Widget& r)

{

  return l.x < r.x || (!(r.x < l.x) && (l.y < r.y || (!(r.y < l.y) && l.z < r.z)));

}

Now do that for ten members.

Stop right now and do this instead:

bool operator<(const Widget& l, const Widget& r)

{

  return std::tie(l.x, l.y, l.z) < std::tie(r.x, r.y, r.z);

}

This creates a tuple of references and does a lexicographical comparison, so it just does the Right Thing. All you have to do is list the data members in the same order in each call to the tie function template, and even PHP programmers could do that.

If you haven't caught up with C++ 2011 yet you can use Boost's tuple, just #include <boost/tuple/tuple_comparison.hpp> and then use boost::tie instead of std::tie.

Gah, stupid brain. I need to remember that the modified pattern space after a series of sed commands will only be printed and deleted right away if that modified pattern space doesn't match the addresses of any later commands. If it does match, it might get further modified and then not printed. Stick ;p;d after the series of commands to avoid that, and not spend an hour scratching your head.

In more interesting news, I've been having fun with new Fedora releases. I upgraded my desktop to F17, because it's not possible to upgrade straight to F18 from F16, but once there I found it so miraculously beefy I decided to keep it. On x86_64 F18 doesn't offer me much that isn't in F17, and what I really want is glibc 2.17 which includes the most excellent change I asked for, but isn't in F18. Following the advice of freenode's #fedora-devel I've got a mock chroot where I can use rawhide, so that I can make some changes to libstdc++ so that a high-resolution std::system_clock will be enabled by default on systems using glibc 2.17+

I have, however, installed F18 (beta) on the shiny ARM chromebook I got for xmas, thanks to lots of help from #fedora-arm. That's a huge improvement on my ageing eeepc netbook. Kudos to the Fedora ARM team on excellent work.

I've also got round to sending my paperwork to the FSF so I can contribute to GDB, which means I should resume working on my patch to teach GDB about C++11 rvalue references. That's been on hold while I sat on the paperwork, wrote a C++ standard proposal and started work on my talk for this year's ACCU conference. (If my wife wasn't working so hard on her studies she'd probably be asking me to stop all these extracurricular activites by now!)

I've often joked that instead of picking up Djikstra's cute acronym we should have called the basic synchronization object "the bottleneck". Bottlenecks are useful at times, sometimes indispensible -- but they're never GOOD.

David Butenhof on mutexes, from the illuminating Re: recursive mutexes

Gold linker + CentOS5 NFS client + Solaris 10 NFSd = ballache

I've spent a day and a half being completely bewildered by a weird NFS bug where ELF binaries (but not other files) written to an NFS mount show up on remote hosts with the correct file size but consisting entirely of nul zero bytes, but only when written from CentOS5 hosts, not from Solaris, Fedora or RHEL6 hosts.

I eventually narrowed it down to the Gold linker, which writes files using mmap, and the CentOS5 2.6.18 kernel has a bug when writing files with mmap to NFS mounts.

There was a very similar RHEL4 bug that should be fixed in my kernel, but for some reason the kernel-2.6.18-redhat.patch file in the SRPM comments out the fix. I don't know why.

Maybe this post will show up for anyone else searching for the symptoms, because I didn't have much luck searching the web for it.

My solution is to avoid Gold on CentOS5 (since we can't easily stop using NFS, unfortunately) but I wish I could get that day of my life back.

Update: The distcc FAQ (search for Files written to NFS filesystems are corrupt) mentions this problem and refers to a post to the distcc list and a post to the linux-nfs list where a workaround using the no_subtree_check option for nfsd is given, but that assumes the NFS server is linux, and mine isn't