Technical Ramblings

One of the nifties things I have on my cell phone is a bluetooth capability: the ability to communicate with other devices nearby at relatively high speeds over a wireless protocol. Bluetooth is a very useful tool for development: I don’t have to worry about USB cables or anything else, and I can talk equally well to my Linux desktop with an abicom BT adapter as I can to my Powerbook with its built-in bluetooth.

One thing that no one has mentioned yet about the new Python release is the Bluetooth console. It took some doing, but I finally got it connected to my Linux desktop, and found an app that will let me connect to the port. Now, I basically have a way to tell my phone what to do over Bluetooth:

[crschmidt@peanut ~]$ sudo cu -l /dev/rfcomm0 
Connected.
Python 2.2.2 (#0, Dec  2 2004, 18:12:32) 
[GCC 2.9-psion-98r2 (Symbian build 540)] on symbian_s60
Type 'copyright', 'credits' or 'license' for more information.
Type 'commands' to see the commands available in this simple line editor.
>>> 

This has sped up my application development significantly: with this in place, I can start to experiment with different code at a rapid rate: without sending almost identical files to the phone several dozen times to test them, nor typing on the 3650’s keypad to enter my code. I just type into a normal tty, and it acts exactly like a local python interpreter.

This is also possible, and documented as such, using TCP/IP over GPRS instead of Bluetooth. However, the speed restrictions of that cause it to be much less practical. It’s like typing into ssh over bluetooth: sure, it’s okay, but you almost never want to do it if you can avoid it.

Here’s what I ended up doing to get it working:
– Get a working bluez install. Bluez is the standard Linux protocol stack, and is built in to most recent kernels.
– Test that you can talk to the phone, using hcitool scan, hcitool info.
– Register an “SP” (serial port) service with sdpd. sdptool add --channel=3 SP
– Ensure that sdpd is running
– Set up an rfcomm port to receive the communications: rfcomm listen /dev/rfcomm0 3
– (On Phone) Open Python, then bt_console.py
– On the computer, you should see:

[crschmidt@peanut ~]$ sudo rfcomm listen /dev/rfcomm0  3
Waiting for connection on channel 3
Connection from 00:60:57:41:86:C2 to /dev/rfcomm0
Press CTRL-C for hangup

– Using taylor-uucp, type cu -l /dev/rfcomm0
– Welcome to the phone!

If you want to test to make sure it’s working, you can do something simple like:

import appuifw
appuifw.note(u'Howdy!', 'info')

from there, refer to the excellent Nokia documentation for more tips and tricks on what you can do. I think this is definitely a great example of what power the distribution has, and I’m surprised that more people haven’t been writing about it. Has anyone besides me (and Nokia employees) gotten this working?

With the advent of a language I can program on my phone, my first goal was to learn the language, and my second goal was to rewrite something that I think is an almost-great service, but missing a couple key features. With that in mind, I headed to work, first with my FOAF app. My work after that concentrated on a locative service based around cell towers, and learning the user interface aspects of the Python interface.

Last night, I got my first victory in both: I wrote a decent (although minimal) user interface, which was able to communicate information about my location based on cell towers I was near. You can see the start of the work at http://crschmidt.net/cell/ . As I just described it to another mobile user, it’s going to be “Like CellSpotting, without the suck.” Using services for anything is completely unneccesary, especially with how simple python makes it to build user interfaces. I don’t know how hard it is with the Symbian interface, but I want to make it better.

My code is pretty simple so far, but it works. I will be continuing work on it tonight, but I’m already seeing other people start similar work, and I believe in shared efforts. So, the code is available: the .py.txt is the Nokia python program, and the .php is the server-side script I’m using.

I will be working on changing the way things work a lot, but I just want to show some of the cool things that can be done via the exposed Python interfaces on the mobile platform. Note that the actual Nokia code is only a dozen lines: which builds a nice interface, allows you to edit the form, and to send the data off. There’s not much funtionality yet: not even a way to update your location without exiting and reentering the program. However, it’s a start, upon which others can build.

Over the weekend, I had some fly time to work on my image annotation application. I had asked for a bit of help on the way to get input in Python, and sbp pointed me towards “raw_input()”, which is what my application is based around.

Originally, it was going to be written using the Redland python bindings. I had prepared myself for the flight by installing Redland, and browsing a bunch of pages with annotation examples, which Slogger grabbed for me and stuck into a local log. With this, I thought I was prepared. So, I got on the plane, got past 10,000 feet, opened the laptop, executed my program (I already had about 20 lines of code)… and smacked myself in the head as it complained that there was no module RDF.

You see, Redland has two parts: the library itself and the language bindings. You kinda need both for working in Python.

So, after a little bit of thinking, I remembered that I had installed rdflib for testing of n3p, and decided that I would convert my existing code to that. In about 15 mintues, I was back up and running.

The program is simple, although it’s still lacking some important functionality. It basically just asks a series of questions about the image you tell it to annotate. Sample program input is available, as well as the sample output, and the sample passed through cwm to demonstrate how it looks when cleaned up.

You’ll notice that there’s data there that I didn’t enter: that data is brought in from a FOAF file. This file is only specified in the code at the moment. The code intelligently works on the name you give and checks for either a nickname or name matching: if there are multiples, it provides you a list from which you can choose a number given. In any entry form, you can just skip enter to either accept the default or skip past it.

The source is available, as depiction.py. This source code is messy, the way it’s laid out is very procedural, and you’ll have to modify things inside the code in order to get it to work for you. (Specifically, the foaf.rdf file is hardcoded to the location of mine.) The wordnet features are the newest and the least complete. I’m going to continue working on it, and the application is not considered even alpha-level release yet. However, I know that other people are interested in the arena, so feel free to take the code. You will need RDFLib to run it. It is MIT licensed. Share and enjoy!

An update to my previous post about bad documentation:

I’m blind.

Quite clearly described on page 18 in the API documentation is the popup_menu feature. I’m not sure how I missed it, as I thought I went over the entire UI section 2 or 3 times looking for it, but it’s right there, plain as the nose on my face. Thanks to Jukka Laurila for pointing this out to me.

Secondly, the additional documentation referenced in the references section of the API doc are included in the distribution: I had lost them in the sea of documents in the folder I unzipped into, since the zip file that I downloaded didn’t have the files inside it stored in a seperate folder. (Yet the Examples zip file inside that folder did). I still think that at least mentioning that they are included would be a good idea, for people who don’ot realize it.

So, my two issues with documentation are mostly resolved: both were due to me not seeing what was right in front of me.

However, the error with hitting return while on a word in t9 is definitely reproducible, so I don’t think that one is something I’m just making a mistake on.

Nokia has earned more than I’ve given them credit for. Nice job, and thanks again.

Although I love being able to develop things quickly and easily on my 3650, there’s a few major sticking points for me that I don’t understand. I know that my phone is considered an “untested” phone for this application: it’s almost the oldest Series 60 around, so I don’t expect everything to work nicely, or even at all. I was totally psyched when I learned that I was on the accepted list. Yet there are some things that bug me.

Lack of Documentation: Nokia has done an admirable job at documenting what their Python does and does not do, and has done pretty awesome, except for a couple things. First of all, there is completely undocumented UI funtionality in the Examples code that they give out. (Specifically, for the pop up choices: appuifw.popup_menu). I don’t know how much it bugs me that I looked through their entire PDF documentation 3-4 times looking for this feature described and found nothing. For a great project otherwise, to skip things like this when you’re releasing a public version is just a bit annoying. Additionally, 3 of the 6 references from the API reference don’t go anywhere: they’re just titles of publications, with no additional information. I believe two of these files are included with the distribution (I can’t check right now: The batteries of the computer I downloaded it to are dead), howeverm, to not even mention that and only list a title is again, quite silly.

Clear Lack of Testing: Again, as I said, the 3650 is not a “well supported” phone in this endeavour. However, there is a relatively major crasher bug in the Python distribution: when running in the Interactive Shell, if you press the “return” key equivilant while still on a word while using predictive text… it crashes.

That’s right, if you’re using a built in feature of the interface, it crashes. For no apparent reason. Doing something that most python programmers will do first, before anything. (The interactive shell in python is impressive, and is a good “sandbox” type environment to test small scripts out.) Granted, on a cell phone, the interactive shell users are going to be relatively slim: who wants to type on a phone when you can just type on a computer and send it over? However, to leave a standard python feature so broken is just silly.

Other than these two minor niggles, I’m very impressed, and hope to see the available UI interfaces grow over time: I’d like to be able to have as much control over user interface tools as Symbian native apps do, and I think Nokia would like to see that as well. I’m especially happy with the “location” module, which allows you to retrieve Network, Area and Cell IDs: I can now write my own tool to do MiniGPS-type cell storage, as well as uploading data to MeNow.

A list of standard modules which are included:
anydbm, atexit, base64, bdb, binascii, cmd, code, codecs, codeop, copy, copy_reg, cStringIO, dis, errno, exceptions, __future__, httplib, imp, keyword, linecache, marshal, math, md5, mimetools, operator, os, pdb, quopri, random, re, repr, rfc822, socket, sre, string, StringIO, struct, sys, thread, threading, time, traceback, types, urllib, urlparse (urlsplit only), uu, warnings, whichdb, xreadlines, as well as a “location” module for determining GSM cell info and “messaging” for sending SMS messages. Additionally, there is a UI Specific module, appuifw, the e32 Module, which offers some Symbian related utilities, e32db, a relational database module, and the e32dbm module, which offers an API to the Symbian RDBMS.

All in all, an impressive an useful subsection of the modules which most people use. The socket library has been extended to include a number of bluetooth functions, which apparently work quite well (I wouldn’t know, haven’t tried them yet.) I’m very pleased. It’s fun. But I think nokia could have waited just a little longer to ship this, to make sure that some things weren’t broken.

Today, Nokia released Python for Series 60 based phones. I’d been hearing about this stuff for months, but it had been in closed beta, so I hadn’t paid much attention to it. In addition, when this stuff was being discussed originally, back in April, I’d never had a hand in any Python coding: I was a Perl and PHP hacker only.

However, when mattb asked today who would be the first to write an RDF parser that would run on the phone, I asked what he was talking about, and received a pointer to Nokia’s announcement. I immediately started playing. (A bad thing, given that I had work today.)

So, in 5-10 minute increments, plus hacking after the kids went to bed, some help from sbp in the form of an ntriples parser written in Python, some help from Dave Beckett and Redland in the form of an easy RDF/XML->ntriples conversion, I now have a working (although clunky) FOAF application for the Series 60 phone running Python.

So, without further ado, I explain to you the steps behind the process:

First, the user runs Python. This is installed the way any other application is. Once Python is installed, the user must send two files to their phone: an ntriples parser and the actual FOAF Service script. The ntriples script is installed as a “library”: this means that it is installed on the include path, so that it can be imported as a module. The FOAF script is installed as a script.

The user opens Python, and chooses to run a script. They choose the script that they installed, and run it. A standard query box opens, and asks the user for a URL. Here, they enter the URL of a FOAF file. Once they do, the file is passed through an rdf/xml->ntriples web service: this converts most FOAF files to a format the phone can understand. An example URL for this webservice is http://crschmidt.net/semweb/xml2nt.cgi?uri=http://crschmidt.net/foaf.rdf : It is created using Redland, and source is available at http://crschmidt.net/semweb/xml2nt.cgis . It uses the Redland Python bindings. You can feel free to use this web service: however, if you’re going to be exceeding 10 hits/minute, please let me know so I can find someplace better to host it.

Much of the time for the script to run is simply fetching this content: my FOAF file generates 70k of ntriples, which is then parsed into a simple list of triples. Some post processing sorts the data, and looks for a personal profile document to whom the document can be attributed. If it is found, then the script prints out a list of contact information for that person, including email and contact IDs.

Many thanks to mattb for pointing out the Python release, sbp for his invaluable ntriples parser and his help getting it working, and to other people who muttered encouragement throughout the day.

The source is available at my Symbian Semantic Web Page. More images are available in my Symbian Hacking gallery.

Chris: 2, Redland: 0

For quite a while, I’ve been having some problems with installing the latest version of the Redland RDF Application Framework. I’m sure that these were problems of my own: I know that my system is a little goofy, in part because I’ve got a combination of ebuild-built and non-ebuild versions of things. So, for a while, I’ve been unable to compile the lateset Redland, because whenever I’d try and compile, the system-wide redland-config would get in the way, and then Redland would try to link against the already installed libraries, etc. etc.

However, yesterday I started having issues with julie crashing, returning a glibc exception. I wrote a small test script, and found that the issue was occuring any time I was using two “AND” clauses in an RDQL query. I recompiled glibc with debug info this morning, and was amazed to find that my backtraces suddenly became much more informative: Instead of gdb returning ?? in ?? in my backtrace, it actually gave me function names and line numbers. I didn’t think that just recompiling glibc would have helped so much.

After I was able to do this, I sent mail to the Redland-dev list: Here’s my problem, here’s my backtrace, where do I go from here? That Email got several responses back and forth from Dave Beckett (maintainer of Redland) and Morten Fredrickson (maintainer of the MySQL storage backend). I ended up stopping all services which used Redland, uninstalling redland completely, and making the latest release successfully. In combination with discussion on IRC, I moved onto testing with valgrind, an open-source memory debugger for x86-GNU/Linux and ppc-GNU/Linux. Sending the data dump from that helped Dave to find the problem, which was related to the way that the mysql backend frees results.

One patch later, the problem was cleared up. There’s still the question of why it broke, which seems to be related to some broken statements in my database. However, it’s good to know that I helped to find a bug in Redland, rather than just finding something broken locally.

In the end, I did learn a few things:

1. Having glibc debug symbols on is a Good Thing.
2. If you can’t install the latest version, try uninstalling the previous version first.
3. valgrind is an app which may help you locate the source of bad free() calls
4. glibc has some extra sanity check memory detection: you can adjust its behavior via MALLOC_CHECK_. Levels of sanity are 0->3, with 0 being “display error message and kill application” and 3 being “do nothing”. (I found this via fedora core release notes.)

I also was able to compile new Redland bindings: this means that I fixed my Perl Query problem (which has been fixed for a while, but I couldn’t install new bindings), as well as adding Sparql support to my local Redland tools. Now, I just need to write something that uses it.

So, in the end, I helped squish a bug, and upgraded all my Redland related stuff on my system. That’s what I call a good day.

I have about 1500 images that I’ve taken over the last 1.5 years since I got a digital camera. These photos vary wildly in what they contain, from parties with friends to buildings to family photos to stuff around the house. There is a variety of images depicting people from all walks of life, from my college friends to my family now.

I want to search them.

I’ve become very convinced that the best way to store the information about these photos is in RDF: It’s the only data description framework that lets me extend and expand my descriptions to include everything I need. (There’s also the fact that I’m an RDF nut, so everything is a case for RDF.) Once the data is created, adding it to an RDF store and asking that store questions will not be difficult; the main problem is to get the data created.

There are some web based tools for photo/image annotation: mortenf uses a tool he created which spits out ntriples, and there is also the java app attached to the foaf codepiction project. However, neither one of these lets me describe my images very easily; There’s a lot of effort to go through for it.

My ideal photo annotation tool works like this:

• Provide a URL to a photo.
• This photo may or may not have EXIF data included. If it does, use the exif data to generate the appropriate RDF; something along the lines of the EXIF metadata created by Mashide’s exif2rdf web app would be good.
• Allow me to describe the image with a title and description: dc:title and dc:description.
• Allow me to describe the person who took the photo: foaf:maker. This part can work from the existing triple store I have; Let me enter a name, and then use that name, along with an mbox_sha1sum, to describe the person.
• Offer me a license list: a list of CC licenses to choose from.
• Allow me to describe “things” that are included in the photo: entering a term and checking it against wordnet, then using the right sense of the word.
• Allow me to describe “people” in the photo: enter a name or nickname, and then present me a list of options from my triple store, or the option to describe a new person. Once I choose a person, a name + IFP should be included in the output so that I can smush the data together.

I’d like for the entire interface to be text based. I don’t want a web or graphical app: with 1500 photos, that’s just too damn much. I want to be able to describe these things quickly and easily, so very little should get in the way, with as few keystrokes as possible. If I want to skip something, I can just hit enter to skip over it.

I’m lucky in some respects, because some of the hard work of gathering information about people is already done for me: I have a large triple store at hand that can help me with this project. I also have some limited experience in working with the Redland framework, so I may even have the experience I need to make this work. So, here’s how I see it working on the inside:

Create an interface along the lines of what Config::Tiny (in perl) does: Question [default] ? then allow for the user to either skip past (and use the default, which may be none in some cases) or to use their option: if their option, possibly provide a list of choices after that. For example, if I enter “Jessica” as a name, it should tell me “There is no name Jessica in the database: would you like to create a new user?” with a yes or no option; if no, it would go back to the previous step and let me enter a different name. Dump the data, as its created, to an in-memory Redland model. Once the photo description is complete, serialize the model to a file, which can then be run through cwm to clean it up for more permanant storage.

I’m probably going to actually get off my butt and write this pretty soon: I have a lot of interest in describing this data, in part because it’s another case where a nifty project can lead to a great demonstration of why and how RDF can work. I’m most interested in someone who may have suggestions on what kind of tools would be good for creating the interface: the last time I did any kind of user input other than command line was when I was working with cin>> statements in C++. I’m probably going to write it in Python (I feel that I really accomplish things much more quickly writing in that language than in either perl or PHP), so tips on how to create command line user interfaces in Python are appreciated.

A number of people have expressed interest in my posting some of my more technical ramblings as a seperate resource to the oftentimes personal weblog I’ve used in the past, my LiveJournal. Because I’ve always been one to aim to please, I have decided that I will seperate my more personal postings from my technical ones, although not because I mind people reading my personal life, but more because I want to ensure that people can read what they want and not feel discouraged, as well as ensuring that I can post in specific places and have people read it only if they want to.

Of course, this entire problem could be alleviated if LiveJournal ever got a decent categories system in place, under which people could subscribe or filter to certain categories, however, I do not think that this is a very likely occurance.

LiveJournal has long been my “home” on the web. It offers a number of features that I don’t understand the lack of in other tools: for example, the emails for comments act much like any other mailing list which takes place through email, something that I’ve never seen another blogging system do. However, as the author of this weblog, this is less likely to be an issue: there will probably be few “threads” back and forth, and even if there are, I will receive information on all the comments being left.

Perhaps one thing to do with this new blog is to make communication be a bit more like a mailing list; email subscriptions to posts, so that when they’re updated or a comment is left, people can tell.

I’ve chosen a relatively odd permalink structure for this weblog. In part, this is to prove that it can be done: Many people do not realize that WordPress offers the ability to completely change what your permalink structure is like. In part, it’s simply to shorten post URIs: with only %postid% and %posttitle%, I’m keeping it simple, but still unique from both the %postid% perspective, and informative to the human who may be dereferencing the URL manually.

Expect me to add categories, links, plugins, and possibly change the style over the next few days. If anything I change is something that you feel makes this weblog less usable, please let me know.

The weblog that I was using previously will continue to be available, although I will no longer update it. From now on, posts go to LiveJournal or to here, depending on their nature.