Bake me a painting

Because I am a cheap bastard

Against my better judgement, I have started poking at Twitter. I do not have an unlimited SMS plan on
my phone so I have been relying on the Jabber endpoint which
is sometimes on and sometimes not. Or my IM client is wigging
out and it just seems that way. Did I mention I am impatient?

Then it occurred to me that I do have an
unlimited data plan and use a phone with a Python
interpreter and Twitter has an API. Then I
remembered that I am using a freedom-hating Series60 3rd
Edition phone. Then I decided to write
something (in pure Python) to fetch and display my
contacts recent mutterings, anyway.

What follows is not something you can download to your
phone and just start using. It is only the guts of the
application divorced of all the usual Series60 setup, GUI
bindings, polling and error handling. I suppose I will get to that over the
weekend. Otherwise, you can run it from the command line.

Obviously, the best thing would be to create a new inbox
message and let the phone take over at that point, beeping
and blooping according to whatever rules a person has set up
. This does not appear to be part of any of the APIs
yet.

If I had to pick, though, I'd still choose a built-in XML parser
first....

Update:

Oh, and still it gets better. If by
better you mean I should want to write my own XML
parser this weekend. It turns out that Series60 Python does
not support the re.DOTALL flag, for pattern matching. The result of
which is that the following piece of nastiness :

Which is really salt on the still sore wound created by
the goofy pattern nonsense, but at
least it works. Until it doesn't. When I tested this on my phone, xml ended up
being a string 7144 characters long. Somewhere between 0 and
7144 is the wire that will trip the
SRE_ERROR_RECURSION_LIMIT wire in your phone's
regular expression library :

I have a working version for a Series 60 2nd edition
phone that uses the PDIS Element Tree XML magic. I wrote it
largely out of stubbornness since my phone's lack of
vibrate-ability makes the whole thing sort of
pointless. Some day the stars will align themselves in a way
to make sense of all this crap and when they do I will be
ready.

I have also chunked out the guts of the program in to a
base library from which I've written a tool for
displaying notifications using Growl and its Windows
equivalent Snarl. It would be reasonable to ask why I don't
just continue to use the Jabberbot to display messages. All
I can tell you is that I like eye-candy as much as the next
person. I was also thinking of writing a proxy API which
would keep track of which messages I had already seen
regardless of the device I was using but that seems
like something better done at the service layer.

Tommi asks Symbian Signed - should it be changed somehow?

I've tried to post a reply to this post three times now, but Movable Type has cranked the suck knob and keeps asking me to re-enter my security code without providing any input field for doing so. By the time you read this my comments may have been added thrice-fold but on the assumption that they haven't, this is what I said :

In so far as S60 Python development is concerned, the 3rd edition signing process has effectively poisoned the well.

None of the scripts I've written for 2nd edition phones work due to permissions issues despite the fact that the (3rd edition) interpreter itself is signed with access to all of the APIs in question. Even then, my understanding is that access to the calendar API has been removed from the spec altogether.

I may get around to requesting a certificate and going through the process of having each app signed but I might as well also start writing everything in C++ or Java. The "killer app" in the Python application is the ability to quickly brainstorm and prototype tools that can actually do something *with* the phone : the calendar, the address book, the camera, cell tower information, etc.

I haven't really tested Raccoon for the 3rd edition yet but I can only assume that the same (signing) restrictions apply to mod_python scripts. I love the fact that I can run a web browser locally on my phone (BTW, browser-app people : requests to http://127.0.0.1 do not need to connect to the Internets). The ability to use the browser's rendering engine to handle all the boring UI stuff combined with JavaScript and Python to manage and manipulate the information on my phone is in a word : Awesome!

Sadly, I don't think it's a realistic prospect on 3rd edition phones given the burdensome nature of the signing process. There are some people for whom the cost of signing their scripts won't be an issue. For some people it will be. For most people, it will just be a barrier too high for them to want to care.

Perhaps a signed certificate for SIS files is prudent (I remain unconvinced) but to extend the same policy to scripts whose interpreter already has a complete permissions set shuts down an avenue of possibilities that was only just beginning to open up.

locatr-er

BUT WAIT! THERE'S MORE!!
As of version 0.2 locatr is also able to determine your location by
passing your device's cell tower information to the ZoneTag celltower-based geocoder
API and then again through Yahoo Local's geocoder API.

To be fair, I have never planned on using a wiki to
store recipes. Now that I've played with it a bit I
definitely like the idea of using the SMW tools, as a
collaborative space, to reference
and define ingredients and measures.

Say hello (in a couple days) to : http://eatdrinkfeelgood.org/terms#.

{{Easy|like pie}}

Recipes are really tempting, though, because it's hard not to love
the Wikipedia syntax. It's ruleset is easy to memorize and, better
yet, lends itself to wild guesses. It can be written offline
in nothing more than a text-editor. The wiki-ness of the
format makes it more forgiving of stupid mistakes and the
wiki-ness of the storage makes it easier to fix those
mistakes.

But : Exporting anything besides wiki-text
out of Wikipedia remains a daunting prospect, at
best. Daunting is probably unfair given that any
recipe markup will be a limited subset of all the possible
syntax and easy enough to parse although there appears to be a
deficit of tools for creating custom dumps of data in Wikipedia.

I think I can tolerate using wiki-text as the principle
storage medium for ingredients and measures. The problem
with using if for recipes is that the markup is basically
useless for doing anything with it outside of
Wikipedia. Doing stuff in Wikipedia is also pretty limited
but that's mostly made up for by the fact that what little
is does do it does very well. Ultimately, I am not willing
to pour all these stories in to a twisty maze of database
dumps and lost, or forgotten, backups. (Never mind upgrades
to the underlying PHP code and interpreter.)

I have started adding hooks to read and write
semediawikitext in erdfg.py. If
I can make it do reliable round-trips (import, export,
edits, etc.) between a set of static (N3)
files and a site running the SMW stuff I will bundle
up all the various templates, extensions and config tweaks
and post them for your pleasure.