My plan to buy a Chumby and convert it into a somewhat over-
I had to junk the original version of the software I wrote for it, because it turned out that the Chumby's Flash player was apparently never intended to keep running the same program for more than a few minutes at a time: every three days or so it would leak enough memory that the clock became unresponsive and had to be rebooted. So I threw the whole thing away, thus fulfilling Brooks' Nth Law, and wrote it again from scratch in C. It is now lovely and fast, it doesn't leak, and as an added bonus it's much easier to persuade it to store persistent data and make network connections.
So the clock program now does everything I originally envisaged, including tying in over the network to my existing calendar software. Yesterday was the first test of this on live data: it correctly spotted the impending bank holiday and automatically cancelled the usual weekday alarm arrangements, and it has correctly not tried to do the same thing again for tonight. Success!
So now it's working, the real question is: was it worth it? And already I'm confident that the answer is yes.
As I originally planned, I can now get up early with impunity. I can just press ALARM OFF, get out of bed, and not worry about it. Where I would previously have had to come back to the clock at 8am to stop it beeping, or remember to turn the alarm back on properly that night, I now need do nothing at all –
But there's an additional advantage which I hadn't considered, which revolves around the snooze function. With my previous clock's snooze function, you would press the Snooze button and then be pretty much committed (on pain of thundering inconvenience if you go back on it) to staying in bed for another nine minutes. So you might as well drift back off to sleep, and then when the alarm goes bwarp again nine minutes later you're just as unwilling to get up as you were the first time.
But with my snooze function, because you can trivially cancel it at any time in the middle of the snooze interval, it's now feasible to lie in bed and gradually wake up rather than going straight back to sleep; my normal usage of the snooze function is now to hit Snooze, lie around for three or four minutes, then cancel the snooze and get up. The alarm at the end of the snooze period has now become a safety feature just in case I accidentally drift back off during this process; in normal usage it never actually goes off. It's as if my redesign has completely changed the nature of what the snooze function is fundamentally for, and the new model feels much more sensible and useful. (Of course the old usage is still available if I should want it: there's nothing stopping me hitting the snooze button and dozing straight back off).
There's always a danger, when you want something for ages and finally get it, that it will turn out not to be as good as you'd hoped, or that your imagination had not correctly envisaged the way it would be used and that it will therefore turn out not to be as useful as you had believed. Today I own an alarm clock which has well and truly avoided these traps, by not only fulfilling all my original expectations but also by turning out to be useful in extra ways. I got it right!
I wasn't so interested when I found you'd written all your modifications in flash, to run on top of their software edifice. Now I know you've got some C code that will hopefully be available open-source very soon to do some important things in elegant ways I'm much more interested.
Good point; it's probably about time I moved it out into my public svn repository. I'm not yet sure it merits an actual web page of its own, since it's a pretty niche program, but as of now the code is available from
svn://svn.tartarus.org/sgt/tring(or you can browse it on the web here) if you want it.I don't know how much of my code will be directly useful to you. Probably the thing you'll find most useful is the enormous comment at the top of
chumby.cwhich documents everything I know about the programming interfaces to the Chumby hardware from the POV of a userland application.pollfds = malloc(npollfds_both * sizeof(*pollfds)); pollfds[0].fd = touchscreen_fd;Shouldn't there be a check for malloc failure in there?(Not very important in practice: that code only runs once at program startup, and unless I'm doing debugging that's always just after a reboot so the Chumby will pretty reliably have plenty of memory to spare at that point. But thanks anyway.)
pollwas mostly dictated by the ALSA library API, which provides a pre-cooked set ofstruct pollfds for detecting when more data needs to be sent to the sound device. I suppose I could have read those and translated their contents into mypoll-equivalent of choice, but it didn't seem particularly worth doing.epolllooks like massive overkill for a job this small, anyway!