If you work with Google AppEngine and use task queues much, you know it can be annoying to have to press the ‘Run’ button on each task to make it actually run. Here’s a Greasemonkey script to push the button for you. It mindlessly pushes the first Run button it finds immediately on page load. Since the page reloads, that should eventually press them all away.

Have fun, but there are no guarantees that this won’t run tasks you didn’t really want to run or somesuch.

Dumb script

Hmmm, pi is a little bumpier than I thought. (It could just be that my statistical intuition is off, though.)

Each bar plot below represents the number of occurrences of a digit in the decimal expansion of pi. The y-axis is an index, and the frequency x is counted over the range of digits y*20 to y*20+400. I thought 400 would be a long enough length to make these graphs pretty flat. Higher lengths make it flatter, of course, but still not to the degree that seems ‘right’ to me.

I guess I could calibrate my perception by using a uniformly distributed sequence of digits…

Pi digit frequencies

Update: huh. I guess it is just me. Here’s the same sort of graph but with uniformly random digits (at least, assuming that RAND’s book, which I lazily selected as my source, is indeed uniform). Looks equally bumpy to me. Ah well, I’ll leave the post up as a reminder of my folly…

Random digit frequencies

Scott Stafford was nice enough to post code for asc-gzip/.xfd decompression to go with my asc-gzip/.xfd compression code. See this comment. I’m also reposting it here because the comment formatting is a little more bad than the main-post formatting.

Thanks for your post. Of course, I needed the opposite, I had one I needed to decompress. So I backwarded your algorithm and here is the result:

def decompress(fc):
    fc2 = fc.splitlines(True)
    fc3 = "".join(fc2[1:]) # could verify that it's asc-gzip here if we wanted to...
    unb64 = base64.standard_b64decode(fc3)
    
    ctr = 0
    ret = []
    while 1:
        if ctr == len(unb64): break
        
        ccltop = ord(unb64[ctr])
        ctr += 1
        cclbottom = ord(unb64[ctr])
        ctr += 1
        compressedchunklen = ccltop * 256 + cclbottom
        
        cltop = ord(unb64[ctr])
        ctr += 1
        clbottom = ord(unb64[ctr])
        ctr += 1
        chunklen = cltop * 256 + clbottom
        #~ print compressedchunklen, chunklen
        
        compressedchunk = unb64[ctr:ctr+compressedchunklen]
        ctr += compressedchunklen
        
        chunk = zlib.decompress(compressedchunk)
        assert(len(chunk) ==  chunklen)
        ret.append(chunk)
    
    return "".join(ret)

It’s always interesting for me to dig into XSLT. I don’t use it a whole lot, so when I do it’s all fun and new. This time around, I’m using 2.0, which wasn’t really implemented the last time I was doing anything much with the language. Loving the new features; so far I’ve used several to good effect.

It occurred to me today that document conversion is an interesting niche wherein a ‘pure functional’ paradigm is useful. I still can’t see myself using a pure functional approach in many other areas, but I do have to deal with document conversion often enough that I’m glad XSLT exists.

I find the tree-transformation model of computation is an interesting mind-bender, though when I think about it, it’s really only mind-bending in combination with the functional approach. And thinking further, I’d suppose that a functional program of any size would tend toward the nature of a tree transformation… Hmmm, something to ponder some more.