0xAB Home

Archive for April, 2010

If you’re thinking of buying a copy of the Complete National Geographic but are weary of having to run it under wine, despair no more. It’s written in Adobe Air and runs acceptably well. I used wine to install it so I could get at the air package inside, but it turns out NGM is nice and provided us with a handy download for the viewer. I couldn’t get it to run without unpacking it, something about an API version mismatch (originally I repacked it with the correct settings but that’s overkill). You can just unzip it in its own directory and run it with something like: /opt/AIR-SDK/bin/adl -nodebug /opt/AIR-apps/CNGViewer/META-INF/AIR/application.xml /opt/AIR-apps/CNGViewer &> /dev/null. Note that as with most Adobe technologies on Linux it’s needlessly CPU intensive, it pegs my CPU at 100% regardless of what frequency it’s set at.

As for the content itself, it’s fun; I specially like how many of the more interesting articles are organized into reading lists. My main complaint is that they used jpeg to compress the images and did so at really high compression leading to lots of artifacts. Looking at a page that has a black background can be painful. Which is a bit of a shame as one of the greatest things about NGM is the high quality of the photographs and printing. The viewer also has way too many needless animations and there’s sadly no way to disable them. So I wouldn’t mind knowing the file formats involved, an app for the n900 or more importantly a viewer that just does its job and gets out of the way would be great.

I had the great fortune of getting into the whole Linux thing and playing around with computers thing when I was really young. When you’re in 6th grade you’ve got unlimited amounts of time, I at least had a propensity to make things crash intentionally (I guess that’s why I’ve been connected to the mains three times). So of course once you get used to Linux the interesting question of sabotaging it in progressively more creative ways comes up. My housemate managed to surprise me today though, he removed the SD card that contained his running Android system. You’d rightly expect it to crash sooner or later but check out the screenshot; in the crashdump somehow the screen looks as if it’s trying to face the other way around. That’s a new and exciting feature. Click the picture to see it in all its glory.

When giving a talk about robots it would be a criminal offense not to include videos. Unfortunately the options for outputting pdf files from LaTeX with video on Linux are sort of slim. You can chain yourself to Acrobat, but even then it uses realplayer and I don’t know about you but my distribution got rid of it years ago. So you’re left with showing grainy and rather choppy flv files. You can try okular or evince but I’ve yet to find a single movie that they would play reliably without crashing. I also wouldn’t want to give a talk with evince as it’s sort of buggy, nothing like standing in front of a hundred people and it showing a blank screen. This leaves xpdf.

xpdf is sort of ugly being motif-based and all but it’s great for showing a fullscreen talk. Unfotunately since Beamer embeds videos as hyperref links you end up having to click the picture and press ok in a dialog box. Not fun and it sort of throws you off while giving a talk. I’ve made a version of xpdf that eliminates the dialog box (with a new flag -autoexec), automatically runs any external links when loading up a slide and puts the size and location of the link in environment variables so that mplayer can pick them up. There’s still a little flicker as it invokes mplayer to draw the window but I’ll handle that when I have a bit more time. Talks look and feel much slicker now. Although you really don’t want to use this as your default xpdf, running external programs embedded in a random file you download is the definition of a security hole.

And who knows? Perhaps this even will be usable on an overclocked n900.

My laptop has been keeping my room nice and toasty for the past few hours and now 240 chicken eggs are available from the repository! That’s out of my list of 290 eggs. A caveat, these are all entirely unmodified with dependencies automatically migrated into the deb. This means that the eggs depend on each other correctly but eggs can’t record dependencies on external packages; so you can install an egg and not have the appropriate deb package from the standard repositories. I don’t particularly want to go through 240 eggs and record this, so we’ll have to live with this situation for now. It shouldn’t affect many packages anyway.

In the process I’ve built the most inefficient package manager that I could, it finds the fixpoint of a function which filters out working packages from a list. Oh well, at least it’s short.

OpenGL is one of the reasons why many of the packages fail to build. Unfortunately the n900 only provides OpenGL ES which eliminates a lot of the fixed pipeline and changes almost entirely to a programmable one. That means a lot of the old OpenGL API was removed. Until someone comes out with an OpenGL layer for the n900 this this won’t be available.

srfi-19 doesn’t build, which knocks out most of the remaining packages. setup-api looks in the wrong place for the srfi-29 bundles, I’ll have to look into it at some point.

The n900 really needs some sort of voice recognition. While the keyboard is nice, it’s sometimes a real pain and I really just want to be able to tell it ‘find all restaurants nearby’ or ‘call X”. There are a few options when it comes to voice recognition, I think the most likely to work well enough is CMU Sphinx especially now with the advent of pocketsphinx. pocketsphinx is specifically designed to be small and fast and it seems to deliver on both points. I build the pocketshpinx libraries for the n900 (patches to the upstream version of pocketsphinx are available here) and I’ve been playing around with them for the past two days. The accuracy is good enough and integration with the rest of the system so that you can give commands like switch task should be doable. To test things out and get my feet wet I’ve been using a quick python script called voximp, it’s simple to set up and it’ll let you issue commands immediately.

The main holdout to submitting the qt egg back into chicken have been the Maemo bits that crept in. Now all of that code has been moved into its own, chicken-maemo, egg so hopefully I’ll get around to submitting diffs against svn to the list later today.

With Maemo having its own egg I don’t feel bad extending adding in support for more of the basic infrastructure anymore. Now we have a full set of bindings to MCE over DBus, aside from the stackable windows, notes, banners, and orientation control that we had before. This means accelerometer data, calling, vibrator support, locking various aspects of the device, using the leds, and more. Sadly I still haven’t figured out how you generate documentation for eggs.

I’ve also built my first app that will see real-world usage. My advisor is a session chair ICRA and he wanted an application to manage speaker time during it (they’ve got this 12 (talk) + 2 (questions) +1 (cleanup) minute format). This also brought up an interesting problem of how device rotation is going to work when the guy needs to change its layout, I’ll have to investigate further. Now that the MCE bindings exist, I should add things like vibration and manging the screen state. Still, it’s not a bad app for an hour of work and it’s a decent demo so it lives in the chicken-n900 repository as test4. Obligatory screenshots follow.

I recently added a whole bunch of new eggs: check-errors, doctype, easyffi, eggdoc, filepath, fmt, foreigners, html-parser, htmlprag, input-parse, iset, json, matchable, message-digest, miscmacros, numbers, packrat, protobj, rss, setup-helper, sha2, silex, sql-null, sqlite3, ssax, sxml-transforms, sxpath, synch, test, utf8 and yelp. These are all unmodified and just running the debianize-egg script on them suffices so I didn’t need to import them into my code repository. Adding in this optified repository on your n900 and doing an apt-get chicken-eggname will fetch the egg and its dependencies. Hopefully all eggs will be available soon once I finish the autobuilder script.

chicken-qt got networking support recently, nothing fancy just HTTP Get for now. On the upside it integrates well with Qt so it’s asynchronous by connecting to something like the done() signal. Check out tests.scm for an example.

For the past two weeks or so I’ve been working on getting Chicken scheme up and running on my brand new Nokia n900. The n900 is really lacking a lot of apps and it’s time to have an environment to quickly develop them. Python isn’t an option, try out gPodder and see your device slow to a crawl and your battery drain, so Scheme it is. Things are looking rather good and in the process I’ve expanded the qt egg, hopefully it can leave it’s tech-demo status now.

Some highlights:
– support for QObject attributes
– QVariantList and qvariant are supported so interfacing with qt is a
lot more natural
– removed the simple receiver and replaced it with an object that
crafts the correct slot on request
– arbitrary number of arguments to slots and support for some common
argument types (although notably pointers aren’t yet handled)
– invoking arbitrary qt methods/signals/slots
– support for qt-maemo (stackable windows and various information boxes)
– it now builds in C++ so that making bindings is faster
– qt-dbus is now supported so that polling isn’t required, it too
works with an arbitrary number of arguments and provides all of the
basic capabilities: receiving/sending dbus signals, method
invocation, and exposing methods over dbus
– 0% cpu usage when idle so it’s battery-friendly
– it’s debianized along with its dependencies so that it can be
deployed to the n900
– ported the dbus egg to version 4

I'm a Research Scientist at MIT working on vision, language, robotics, with a touch of neuroscience. My research interests span many disciplines but are all driven by a desire to know how machine and human intelligence works in the real world. I received my PhD from Purdue University, my undergrad from University of Waterloo, and somewhere along the way I worked for Amazon for a bit. After a few years as a postdoc at MIT I became a Research Scientist. Check out my research page! I also love hacking and reading anything fun!