Monthly Archives: June 2009

What? Where did the last 2 months go?

Well, somehow we’ve made it to the end of the first semester of this year, and I quite inconveniently forgot to write about anything since the start of April. This is quite problematic. I guess that means it’s time for me to do my semi-regular dump of notable things. Bleh.

So, where to begin?

ACM-ICPC Trip

So yes, we did arrive safely in Germany, spending a week with my relatives who live just outside of Frankfurt-am-Main in centre of the country. That was a fun week, we spent many days taking in the area, sampling the culture, and preparing for the programming contest the next week. We spent a week in Stockholm, where the contest was held, which was great fun in general (despite being somewhat colder than Germany and indeed Australia), we met many like-minded people, and thoroughly enjoyed the week. In the end, we solved three problems in the contest, which was (just) sufficient to see us getting a ranked position of equal 49th (yay!).

I’ll write up the two weeks spent overseas in greater detail soon (hopefully).

Twitter & Co.

So I succumbed to peer pressure roughly two weeks ago, signing up for Twitter and Identi.ca. As a fun experiment into the field, I investigated how long it would take, and what measures would be necessary, for someone to notice that I was on Twitter, and then follow me. I did this by following one or two people per day, and getting them to drop relatively silent hints about my existence. In the end, it took about a week for someone to notice me, with a fairly blatant reference to me needed to make it obvious. Despite the great scientific breakthrough observed, I don’t think the result is sufficient to write a paper about… :P

My main observation is that Twitter is miles behind Identi.ca in terms of useful features (I like group notices, denoted by ‘!’ tags in Identi.ca, and Jabber-based updating in particular), stability (updating my Avatar in Identi.ca does indeed work first time, every time, whereas it took me 10 tries to get it to work in Twitter), and ability to store my own name (This would make Twitter the first site that I have ever needed to call myself “Chris” as opposed to “Christopher”), that said, Twitter is ahead greatly in terms of the number of people on it, which makes sticking around there a necessary evil (boo for centralisation!).

End of Semester/Undergrad

And yes, it would be amiss to not note that last week was my last week of lectures as an undergrad student (presuming, of course, that all of my exams go sufficiently well), it was mostly uneventful, with the exception of having to hand in two major assignments, prepare and present a lightning talk, and run the session in which it was presented. All-in-all rather busy!

Cocomo: An experiment in metaprogramming in python

Friday saw the second edition of the UTAS Computing Society Lightning Talks, if you haven’t seen them already, I highly recommend that you check them out — this semester’s were at a very high standard indeed, and I wish I’d printed out more certificates for good talks :) . My talk was a demonstration of using metaprogramming in Python, though that’s not what it seemed to be about.

An introduction

I went to the Apple University Consortium’s Cocoa Workshop at the University of New South Wales in February of this year, it was a heap of fun, and we learnt heaps whilst there. One of the key distinguising features of Cocoa is its use of verbose English method and attribute names, the idea being that each line of code should make a reasonable amount of sense when read aloud, hence:

NSString *str = [[NSString alloc] initWithString @"Hello World!"]

does indeed allocate memory to hold a string object, and initialises the newly-allocated memory with a string containing “Hello World!” (this code is highly redundant!). Supposedly such a naming scheme allows coders to write code that is easily maintainable by the original coder, and easily learnable by people who pick up the code for the first time.

On the other hand, my friends, collectively known as Maclab (named after the room at UTAS we inhabit) have developed a rather unique vocabularly, which in particular involves replacing as many words as possible with either ‘thrust’ or ‘fork’, so “Thrustingly thrust the forking forker” is not an uncommon utterance amongst my friends. If this is indeed their usual mode of conversation, then Cocoa’s way of identifying methods and attributes is not necessarily going to be a particularly intiuitive one. So, clearly, we need a version of cocoa that meets their needs.

The setup

So, conveniently, Apple provide a comprehensive version of the Cocoa API, thanks to the PyObjC project. We can therefore use the Python bindings for Cocoa facilitate our new version of Cocoa. Since Cocoa has a very consistent naming scheme, we can simply perform string replacement to translate from our maclab language to the standard cocoa language, using a routine somewhat like this:

 def translate(inp): ''' Translates an input string from key language to value language ''' for i in LANGUAGE: if i[0].islower(): inp = inp.replace(i, LANGUAGE[i]) inp = inp.replace(rtitle(i), rtitle(LANGUAGE[i])) else: inp = inp.replace(i, LANGUAGE[i]) return inp def rtitle(i): return i[0].upper() + i[1:] 

Here, LANGUAGE is a dictionary, with keys in the language code will be written in and values being the target language (in this case, Cocoa). There’s not all that much of a sophisticated nature going on in here. Now that we have a method by which we can translate our attribute accesses, we can get to the meat of the the code.

The implementation

To achieve the new API, we need to use a technique that I will call proxying. This involves the use of objects whose sole purpose is to intercept attribute accesses and calls to an underlying object. In this case, the point of intercepting the calls and accesses is to perform translation from our new objects to standard Cocoa objects. In Python we can do this by overriding the standard attribute access and call methods.

First up is __getattr__, the attribute accessor method — for this, we are passed a string; the name of the attribute that we’re looking for, which we translate, and then attempt to access upon the method on the underlying object (in this case, self.__u__). There is one slight hitch: in certain cases, we may not want to translate the attribute name. This is true, in particular, of the attribute that represents the underlying object. Hence we provide a REAL_ATTRS list, for which we use the default __getattr__ method for. This results in code that looks something like this:

 def __getattribute__(self,name): if name in REAL_ATTRS: return object.__getattribute__(self,name) else: new_objectname = "self.__u__.%s" % translate(name) new_object = eval(new_objectname) return CocomoProxy(new_object) 

Notice that we use eval to perform the lookup? It turns out that __getattr__ doesn’t work universally, whereas . notation does — so we use that for less failover.

Being able to call methods on the objects is important, but slightly more difficult — we want behaviour to be maintained, so we need to make sure that proper Cocoa objects are passed as arguments, rather than the Proxy objects that you may have originally dealt with. We can do this with Python’s argument unpacking — we build up a list of arguments, and unproxy them as necessary:

 def __call__(self,*a, **k): new_a = [i.__u__ if type(i) == CocomoProxy else i for i in a] new_k = dict( (translate(i), k[i].__u__ if type(k[i]) == CocomoProxy else k[i]) for i in k) return CocomoProxy(self.__u__(*new_a,**new_k)) 

We may also need to deal with iterators. This can be done using a standard generator function, thusly:

 def __iter__(self): for i in self.__u__: yield CocomoProxy(i) 

Finally, there may be legitimate reasons for extracting Cocoa objects, these include printing strings, so we provide an accessor method called no_really:

 def no_really(self): return self.__u__ 

And that’s the entire implementation! The final thing we need to do is provide a pre-proxied version of the base module for Cocoa. Let’s call it GypsyMagic.

The payoff

So now that we have a working bridge from Maclab English to Cocoa English, we can take this sample code that puts some stuff into an array, and then prints it:

 import AppKit hworld = AppKit.NSString.alloc().initWithString_("Hello, World!") arr = AppKit.NSMutableArray.alloc().init() arr.addObject_(hworld) arr.addObject_("Boop!") for i in arr: print i 

And write it in the far more palatable:

 from cocomo import GypsyMagic hworld = GypsyMagic.OGMouthWords.subsume().makeGogoWithMouthWords_("Hello, World!") arr = GypsyMagic.OGForkableTrinketHolder.subsume().makeGogo() arr.thrustinglyThrustForker_(hworld) arr.thrustinglyThrustForker_("Boop!") for i in arr: print i.no_really() 

If you’re interested in seeing how it all fits together, see Cocomo’s website.