I spent some significant time trying to hunt down a bug (or maybe heisenbug), on and off for the last week. Thought I’d nailed it last night, but it was back again this morning.

This is in our pure actionscript 3 game that we’re developing.
It was a crash to do with a null being dereferenced, which was traceable back to a flashvar that is passed into the SWF randomly getting lower-cased by unknown forces. This flashvar is supposed to be a case-sensitive string ID, so when it got lowercased, the thing it was supposed to refer to didn’t match it any more.

In the end, it all came down to firebug. If I hit refresh in Firefox normally, everything worked properly. However, if I opened firebug and then refreshed, the flashvar will be magically lowercased before being handed to the SWF. Putting a trace at the top of the main stage owner sprite like so:

trace("Flash var: " + embedded_variables.assume_stage);

Would normally reveal:
Flash var: MY_CASE_SENSITIVE_IDENTIFIER

But opening firebug and refreshing again gives:
Flash var: my_case_sensitive_identifier

At all times, the flashvar in the DOM (as revealed by Firebug) was unchanged and correct.

So, I added a call in actionscript to explicitly uppercase that flashvar so that we don’t crash with firebug.

Inexplicable. I don’t really know what to blame here: firebug, flash or firefox. I’m tempted to blame Flash though, which seems to infect everything it touches with Adobe’s personal brand of crazy.

I had to write this down somewhere, now I’ve got it figured out. I’ve been banging my head against the screen for the last day and a half in work trying to figure out how to get a Actionscript unit test do what I want.
Here’s the problem: The class is expected to fire a number of similar events, with slightly different payloads. Using flexunit you can tell the test to wait for these events to complete, and handle them with some additional test code. So far, so good. However, I was finding that the first event would fire all the handlers, instead of just the first. When the second event fired, it wouldn’t get handled (because its handler was “consumed” by the first event).

The asynchronous event handling mechanism in flexunit has a bit of a strange and badly documented behavior, which I’ve figured out through blind testing. In short, an event that fires during a test will be handled by every matching handler, in order, until it comes to a handler with a different event type. All the handlers it hits along the way will be consumed (I’m mentally picturing them getting shifted off the front of a FIFO queue, although I haven’t actually checked the source code).

Consider the following example:

public static const FIRE_EVENTS_TIMEOUT:int = 1000;
[Test(async, timeout="1000")]
public function fireEvents():void
{
    function eventHandler(event:Event, passThroughData:Object=null):void
    {
        trace('Received event_number: ' + passThroughData.event_number);
    }
    Async.handleEvent(this, this.instance.eventDispatcher,
                            MyEvent.EVENT_NAME,
                            eventHandler,
                            MyTest.FIRE_EVENTS_TIMEOUT,
                            {'event_number':0});
    Async.handleEvent(this, this.instance.eventDispatcher,
                            MyEvent.EVENT_NAME,
                            eventHandler,
                            MyTest.FIRE_EVENTS_TIMEOUT,
                            {'event_number':1});
    Async.handleEvent(this, this.instance.eventDispatcher,
                            MyEvent.EVENT_NAME,
                            eventHandler,
                            MyTest.FIRE_EVENTS_TIMEOUT,
                            {'event_number':2});
    // Fires 3 "MyEvent.EVENT_NAME" events.
    this.instance.doAsyncEventFiringStuff();
    trace('FUNCTION EXITING... SHOULD WAIT FOR EVENTS...');
}

The doAsyncEventFiringStuff() function outputs a trace statement with every event fired. Running this test gives the following trace:

FUNCTION EXITING... SHOULD WAIT FOR EVENTS...
Dispatching event number 0
Received event_number: 0
Received event_number: 1
Received event_number: 2
Dispatching event number 1
Dispatching event number 2

As you can see, the eventHandler got called 3 times for the 1st event, and the next 2 events didn’t get handled at all.
What basically happened is that flexunit got the first event, looked in its FIFO queue of event handlers, and (starting at the front of the queue) called all of them that matched the event type. If we changed line 19 to reference a different event type, we would have got:
FUNCTION EXITING... SHOULD WAIT FOR EVENTS...
Dispatching event number 0
eventHandler. event_number: 0
eventHandler. event_number: 1
Dispatching event number 1
Dispatching event number 2

(at which point the test would fail with a “Asynchronous Event Received out of Order” error).

The solution to this conundrum is to chain the event handler registration. That is, register the handler for event #2 in the handler for event #1, (similarly) register handler #3 in handler #2.

The code below shows this solution. Also note the lengths that it goes to avoiding the use of the “this” keyword inside the nested functions (“this” doesn’t make it into nested function closures in Actionscript).

public static const FIRE_EVENTS_TIMEOUT:int = 1000;
[Test(async, timeout="1000")]
public function fireEvents():void
{
    var event_dispatcher:* = this.instance.eventDispatcher;
    var test_class:* = this;
    function eventHandler0(event:Event, passThroughData:Object=null):void
    {
        trace('Received event_number: ' + passThroughData.event_number);
        // Register handler for next event
        Async.handleEvent(test_class, event_dispatcher,
                                    MyEvent.EVENT_NAME,
                                    eventHandler1,
                                    MyTest.FIRE_EVENTS_TIMEOUT,
                                    {'event_number':1});
    }
    function eventHandler1(event:Event, passThroughData:Object=null):void
    {
        trace('Received event_number: ' + passThroughData.event_number);
        // Register handler for next event
        Async.handleEvent(test_class, event_dispatcher,
                                    MyEvent.EVENT_NAME,
                                    eventHandler2,
                                    MyTest.FIRE_EVENTS_TIMEOUT,
                                    {'event_number':2});
    }
    function eventHandler2(event:Event, passThroughData:Object=null):void
    {
        // No more events expected.
        trace('Received event_number: ' + passThroughData.event_number);
    }
    Async.handleEvent(test_class, event_dispatcher,
                                MyEvent.EVENT_NAME,
                                eventHandler1,
                                MyTest.FIRE_EVENTS_TIMEOUT,
                                {'event_number':0});

    // Fires 3 "MyEvent.EVENT_NAME" events.
    this.instance.doAsyncEventFiringStuff();
    trace('FUNCTION EXITING... SHOULD WAIT FOR EVENTS...');
}

This finally gives us the desired outcome, albeit at the expense of readability:

FUNCTION EXITING... SHOULD WAIT FOR EVENTS...
Dispatching event number 0
Received event_number: 0
Dispatching event number 1
Received event_number: 1
Dispatching event number 2
Received event_number: 2

DemonWare Timeline

Posted: April 2, 2009 in Uncategorized
Tags:

Tilman has put together a great timeline of the history of DemonWare, my former company. It uses Dipity, which I’d never heard of before.
Anyway, it’s real cool:
http://www.dipity.com/tilman

Welcome to my new home

Posted: February 25, 2009 in Uncategorized

At some point recently I decided that Blogger just wasn’t cutting it and I should try WordPress instead. So, last night, I copied any existing posts here.
So far, it’s pretty neat, and seems much better designed. It’s also got a much more CSS-centric approach to text formatting, which I much prefer to Blogger (in which I found myself spacing out paragraphs with linebreaks).
Enjoy – I am!
ps, what do you think of my cool masthead? Free pints go to whoever can guess what I might have composited it from.

Python Memoize with Expiry

Posted: February 21, 2009 in Code
Tags: ,

To any readers that may exist: sorry for my silence. I’ve been incredibly absorbed with Front Square (our new company), and the three major projects that have splashed and gone splat since November.

Anyway, so that I don’t forget this blog exists, here’s a tasty morsel of python for anyone who cares to use it.

In python, I have often found myself in creating a global dictionary along with a timestamp to stash relatively static database data into. In one case, for example, I cached configuration information stored in the database. This is a perfect example, since it nearly never changes, and failure to do this would result in many pointless DB hits. I generally timestamped the cache so that the application would eventually reload the data without the necessity of a restart (nice for live systems).

Memoizing describes the programming pattern of caching results returned from a function, so that any subsequent calls to the function with the same parameters will return a cached value instead of re-computing it. In python, its possible to create a function decorator/wrapper that will do this for you.

The version below is largely copied from Django‘s memoize (django.utils.functional.memoize), which is a function decorator. It adds to the implementation the ability to specify a cache timeout period, so that old entries in the cache will eventually be recomputed.

To use it, just decorate your function with it, and provide a cache object as a parameter. This object should be dictionary-like (i.e., be subscriptable). At the moment, I’m just using a global dictionary (so that in my webserver, a cache will be kept per server thread).

You can also specify a timeout in seconds (default is no timeout), and the number of parameters to key off when saving to the cache (default: all of them).

Use it as follows:

@memoize_with_expiry(mycache, 60, 2)
def my_function(important_param1, important_param2, unimportant_param):
  ....

Here’s the implementation:

from time import time
class memoize_with_expiry(object):
   '''
   Modified from django.utils.functional.memoize to add cache expiry.

   Wrap a function so that results for any argument tuple are stored in
   'cache'. Note that the args to the function must be usable as dictionary
   keys. Only cache results younger than expiry_time (seconds) will be returned.

   Only the first num_args are considered when creating the key.
   '''
   def __init__(self, cache, expiry_time=0, num_args=None):
       self.cache = cache
       self.expiry_time = expiry_time
       self.num_args = num_args

   def __call__(self, func):
       def wrapped(*args):
           # The *args list will act as the cache key (at least the first part of it)
           # [:None] is equivalent to [:]
           mem_args = args[:self.num_args]
           # Check the cache
           if mem_args in self.cache:
               result, timestamp = self.cache[mem_args]
               # Check the age.
               age = time() - timestamp
               if not self.expiry_time or age < self.expiry_time:
                   return result
           # Get a new result
           result = func(*args)
           # Cache it
           self.cache[mem_args] = (result, time())
           # and return it.
           return result
       return wrapped

Update

Thanks to Villiros for pointing me to the python decorator module, which can improve things here. I’ve adapted one of their examples to achieve the same effect as the code above. To use it, you should make sure you have python-setuptools installed, and ‘easy_install decorator’.

The advantage of this code is that decorated functions have their docstrings and other metadata preserved.

# This module requires decorator. Install with 'easy_install decorator'.
from decorator import decorator
from time import time

def memoize_with_expiry(expiry_time=0, _cache=None, num_args=None):
    def _memoize_with_expiry(func, *args, **kw):
        # Determine what cache to use - the supplied one, or one we create inside the
        # wrapped function.
        if _cache is None and not hasattr(func, '_cache'):
            func._cache = {}
        cache = _cache or func._cache
        
        mem_args = args[:num_args]
        # frozenset is used to ensure hashability
        if kw: 
            key = mem_args, frozenset(kw.iteritems())
        else:
            key = mem_args
        if key in cache:
            result, timestamp = cache[key]
            # Check the age.
            age = time() - timestamp
            if not expiry_time or age < expiry_time:
                return result
        result = func(*args, **kw)
        cache[key] = (result, time())
        return result
    return decorator(_memoize_with_expiry)

Exciting New Company

Posted: November 14, 2008 in Life
Tags:

Straight back from eastern Europe, I got down to work with Brian McDonnell on our new company, which has a name that is secret for the moment. It’s great to be back with a mission. Well, several missions.

Our first was to clean out the temporary offices. We liked Paul Graham’s post on startups needing to the cockroaches of the corporate world. We couldn’t help feeling we were doing well then as we scrubbed down our little part of a building formerly of ill-repute. The guys upstairs say that 2-3 punters still call in every day in search of happy endings!

Well now, we are getting down to business. We’re going to do our utmost to avoid venture capital, for the moment at least, so are keeping it small and focussed, and will be financing the company through part-time consultancy, such as technology training.

We hope to have our first product in private beta by Christmas, and in the mean time, are open to hear from anyone who has a good idea that’s only missing a pair of ninja technologists to implement it.

Oh, and thanks to Dylan for the shout out in last weekend’s Irish Times.

Collision-Free

Posted: September 3, 2008 in Life

Having finally decided to learn to drive, and armed with a learner permit, I’ve begun to take lessons.

The first was the regular kind, where you drive around with all the other cars, bikes and buses and try not to hit them. Even though I got through it all without causing any damage, I found it a bit nerve-racking. This may have been because the instructor wasn’t great (and was the victim of a “You should learn how to teach!” verbal attack from another road user – she took one for the team).

My main problem was that I had no feel for the car (e.g., wasn’t sure I could slow down without causing whiplash), and therefore I wasn’t learning as fast as I’d like because I had to focus on the traffic first, not on the car.

So, I started complaining that there’s no purpose-made places where you can learn to make the car obey you without worrying about other traffic. My mother put me straight and told me that she’d read about just that kind of place in the Independent a little while ago. A bit of googling later and I found the article, and even more googling later the actual website (which the article didn’t publish). I took a 2 hour lesson there on Tuesday, and really liked it.

It’s a family kind of affair conceived and built by a father and his two sons, who also run it along with another guy they hired as the senior instructor. The course has roundabouts, lots of tricky turns and a skid-rink, for special classes they do. The instructor was great too, at least compared to my previous one. At €80 for 2 hours, it’s also cheaper than alot of other lessons. The only downside is that it’s in Maynooth, but getting out there isn’t too hard, and they seem happy enough to drive into the town to pick you up once you get there (the driving track is a couple of miles outside Maynooth town).

So, I heartily recommend it. I’m going back tomorrow for more, and will probably switch back to regular lessons soon enough once I’m happy that I have good control of the vehicle.