Victim of the California Budget

January 1, 2010

With a name like “Theatrical Programmer”, I guess I should post something theatre-related from time to time. Unfortunately, my first theatre post is going to have to be bad news: I found out a couple of days ago that the playwriting class I’ve been taking at Foothill College since 2004 (and with which I was affiliated as an actor from 2002) is not going to be available in Winter quarter, due to budget cutbacks. This isn’t entirely surprising: over the last couple of years, Foothill has been continuously decreasing the amount of slack they give the instructor with regard to the number of students required to sign up for the class in order for it to take place. They’ve also been closing off the number of avenues available for people to sign up for it.

Nevertheless, I’m very disappointed that the class isn’t going to happen. It’s a great way to motivate me to write, and I don’t want to lose that.  It’s also a great way to stay in touch with fellow theatre people, and a nice break from the technology world.


Handling Ampersand Codes in ThrededTweet

December 21, 2009

One of the architectural issues I’ve been having with ThrededTweet is handling HTML ampersand codes, such as & , ⁁ , etc. ThrededTweet uses a UIWebView instance to display whole tweets, and that handles ampersand codes automatically. But the summaries of tweets that are displayed, such as on the main Feed page, use a UILabel.

For release 1.0.0, I manually added handling of what I assumed were common cases, but then immediately found an example of a tweet with an M-dash (—), which I didn’t handle. Version 1.0.1 expanded the set of ampersand codes that are handled, but as you can probably guess, as soon as 1.0.1 came out, I found example of another code that wasn’t handled. So I needed a comprehensive solution.

For verson  1.0.2, I decided to use a program called gperf to create code to automatically handle all ampersand codes. gperf is the GNU perfect hash function generator:

For a given list of strings, [gperf] produces a hash function and hash table, in form of C or C++ code, for looking up a value depending on the input string. The hash function is perfect, which means that the hash table has no collisions, and the hash table lookup needs a single string comparison only.

The first step was to get a list of all HTML ampersand codes, along with their corresponding Unicode code points, which is available on the “List of XML and HTML character entity reference” page on Wikipedia. I cut-and-pasted the code list, separated out the parts I wanted with a one-line Perl script, and stored the results in a file called codelist:


The default behavior of gperf is to create a function that just verifies whether or not a given string is in the hash table, but I needed it to return the Unicode code point as well. So I added the definition of the struct that would be stored in the hash table at the start of the codelist file:

struct code { char *name, int val; };

I then fed this to gperf (the “-t” means that I’m providing my own struct definition):

gperf –t codelist >amp.c

That created a file I could import into Xcode. The important function is that file is:

struct code *
in_word_set (str, len)
register const char *str;
register unsigned int len;

Feed it a string, and its length, and it will return the instance of “code” that corresponds to that string, or NULL if none was found.  If the pointer was not NULL, I still needed to compare code->str to the string I was looking for, in order to validate that we found the correct entry. Note that, for this case, the only reason that it would not match is there was a garbage ampersand code (e.g. “&iowfdna;”).

I then did some cleanup. “in_word_set()” became “is_amp_code()”, and I changed the function to something more modern than ye olde K&R style generated by gperf:

struct AmpCode *
is_amp_code (const char* str, unsigned int len)

The structure definition changed from this:

struct code { char *name, int val; };

to this:

typedef struct AmpCode { char *name, int val; } AmpCode_t;

Finally, “amp.c” became “Amp.m” (perhaps not strictly necessary), and I created an “Amp.h” that contained the struct definition and the prototype for is_amp_code().

I then imported Amp.m and Amp.h into Xcode, removed most of my old ampersand-code parsing code (keeping the part that found substrings that started with “&” and ended with “;”), and put a call to is_amp_code() in its place.

Voila! An ampersand-parser that handled anything I threw at it. If you were following my Twitter test account, you would have seen a string of tweets with all sorts of random ampersand codes, some legal, some not.

And It’s Out

November 18, 2009

ThrededTweet 1.0.0 was released last night!  Click here to get it.


November 16, 2009

My current project is a iPhone Twitter app, called ThrededTweet. So called because it’s threaded by user, rather than solely by time, which make Twitter a lot more usable, in my opinion. Especially if one subscribes to someone who posts quite a bit.

I originally decided to write the app out of frustration: I didn’t find Twitter useful when 80% of the latest twenty posts available to me were by the same prolific author. But I soon realized that it was an opportunity to do some network programming, which I hadn’t done since grad school but which I think is vital for today’s software engineer.

ThrededTweet stores user information in an SQLite database, internally to the app. This is not really the best way to implement this sort of functionality (though it’s not bad), but it gave me an opportunity to try my hand at writing database queries in SQL. Storing a user name and password isn’t quite the same thing as maintaining Facebook’s database, but it’s a useful start.

So this app has turned into a nice way for me to play with some technologies–database programming and network programming–that I’m interested in, but don’t have an opportunity to use at my current job. Which, I suspect, may be the major benefit I get out of writing apps for the iPhone.

ThrededTweet is currently in review, and I hope to have it in the App Store by the end of the month.

First Post

November 10, 2009

Hi. I’m Dave Schreiber, a software developer and amateur playwright in Mountain View, CA.  I’ve created this blog so as to have a space to write about my interests: software, technology, theatre, travel, and life in the Bay Area.  A place where it doesn’t feel awkward to write more than a couple of sentences (hello, Facebook).

And yes, I suppose I should use “developer” instead of “programmer”, but “The Theatrical Developer” would make me sound like a dramaturge or something.  It’s C++ and character development. Linux and plotlines. Plus the occasional trip to New Orleans.