Thursday, July 31, 2008

Pygame 1.8.1 released!

Stick a fork in it, it's baked... nice and toasty. Pygame 1.8.1 is now available for download.

Many bug fixes and improvements, including:

  • BLEND_RGBA_* blitters and blenders to go with the BLEND_RGB_* blend modes.
  • documentation updates (mainly for new sprite classes released in 1.8.0)
  • sound fixes, and streaming some music from file like objects
  • image saving fixes
  • greatly expanded tests
  • Pixelarray, and surfarray updates and fixes.
  • Enhanced Color class, reimplemented in C for speed.
  • New Windows and Mac binary installers.
See the WHATSNEW for a full list of changes.

Many thanks to Marcus, Lenard, Brian, Nicholas, Charlie Nolan, Nirav Patel, Forrest Voight, Charlie Nolan, Frankie Robertson, John Krukoff, Lorenz Quack, Nick Irvine, Zhang Fan and everyone else who helped out with this release.

Monday, July 21, 2008

Ludumdare 48h game competition -- #12

Ludumdare 48H is coming - Aug 8 - Aug 10.



Ludum Dare(ld48) is a regular community driven game development competition. The goal is, given a theme and 48 hours, to develop a game from scratch. Ludum Dare aims to encourage game design experimentation, and provide a platform to develop and practice rapid game prototyping.

Here’s the time-horizon:
- July 19 - July 25: You may submit themes to the wiki
- July 26 - Aug 2: Themes will be edited for awesomeness by the #ludumdare regulars
- Aug 3 - Aug 8: Various rounds of voting. Check back daily so you don’t miss any!
- Aug 8 - Aug 10: Ludum Dare #12 !!! (Starting at 8pm PST)


www.ludumdare.com - the super awesome website, refresh hourly
irc://irc.afternet.org/ludumdare #ludumdare - the compo IRC channel, waste your time here
http://www.ludumdare.com/compo/ - the compo blog, be sure to sign up here
http://www.ludumdare.com/wiki/ - the compo wiki, submit themes & read rules here
http://www.ludumdare.com/planet/ - the compo planet, read about our exciting lives here

Sunday, July 20, 2008

zodb + cherrypy python

Here's a small example of how to use cherrypy and zodb together. It just adds what ever you pass into the /put url as arguments into the db.


easy_install ZODB3
easy_install cherrypy


You can see the website here, once you run the script: http://localhost:8080/



import cherrypy
import cgi

from ZODB import FileStorage, DB
import transaction

class MyZODB(object):
def __init__(self, path):
self.storage = FileStorage.FileStorage(path)
self.db = DB(self.storage)
self.connection = self.db.open()
self.dbroot = self.connection.root()

def close(self):
self.connection.close()
self.db.close()
self.storage.close()



def ehtml(s):
return cgi.escape(s)

class HelloWorld(object):
def index(self):
# list everything passed, and allow adding more.
r = ""
for k,v in dbroot.items():
r += "k:%s: v:%s:<br>" % (ehtml(k), ehtml(v))

r += "<form action='put' method='post'>"
r += "<textarea name='stuff'></textarea>"
r += "<input type='submit' name='submit' value='submit'>"
r += "</form>"
return r


def put(self, **kwargs):
# store all the args passed into the zodb.
dbroot.update(kwargs)
transaction.commit()

put.exposed = True
index.exposed = True

if __name__ == "__main__":
db = MyZODB('./Data.fs')
dbroot = db.dbroot

cherrypy.quickstart(HelloWorld())
db.close()

Tuesday, July 15, 2008

Wordpress 2.6 with post revisions.

Finally wordpress has revisions on posts.

Which makes it a lot easier to share writing between people -- since you can save your copy, and the other person can see what you changed.

Also you can revert to previous revisions of posts you've made.

Very nice.


Theme preview, so you can try out themes before others.

But most importantly they have made images easier to use. 2.5 was seriously 'special' when it came to uploading images. A lot of people couldn't upload images in 2.5 because of they way the interface was not-designed.

It also has partial support for google gears (to serve some parts from a local cache). Which apparently speeds up loading the admin section.



Full details of wordpress 2.6 release.

ps. Also pygame 1.8.1 release candidate 2 was released, with 1.8.1 release planned for this weekend.

Friday, July 11, 2008

RFC: Leaky abstractions for HTTP encoding, and a better high level abstraction.

So I was spinning some webs in late 1884, like many others in this time of industry. Everyone is doing it these days(spinning webs). With the lantern hanging over my carbon fibre 100% macrobiotic desk -- the soft flickering light cast a long shadow through my webs.

I stared into the webs, and something struck me!! It was a blow to my head brain.




Most people in 1884 have made the wrong abstraction for HTTP


At some point most web code decided to use a dictionary for GET and POST variables.

Like a leaky boat, a leaky abstraction is bareable, but also annoying. I hate leaky boats so mostly get around on horse back or by horse and carriage. I also enjoy a brisk walk through the country side in the morning, and I love to scuttle through dark alleyways at night in the exciting colourful parts of the townships slums.

[Editors note*1: my friend wants me to try out one of his chain powered Pull Bicycles. I told him he is crazy and that his Pull bicycles will never catch on. Saying that they do look like fun, especially the ones that fly.]

Now I like hash as much as the next person... but too much hash is not good.


What abstraction do they use for GET and POST variables?

Sometimes it is a dictionary with unique decoded keys, single decoded values, with no ordering of the keys.

Most web codes for languages including python, php, and other vices get http wrong in this regard.

They often lose these useful properties of the encoding:
  • ordering.
  • duplication.
  • streaming.
  • raw encoding.


  • A generator/iterator of tuples of ((key,value), (raw_key, raw_value)) is the nicest high level abstraction I can think of. You don't lose any of those properties.



    ...


    ... **.... .*. . . *##. . ..........


    ...

    Sorry for the mess. There was an ink blot in my quill -- so I had to fix it to write more paper words.


    Now with the new abstraction you can build more leaky abstractions on top if you like. WHATEVA. You can use your hash if you like too, but maybe there is a better way than using a dictionary that isn't leaky.


    Using hash is like a bad DOM. You have to use it all before you can get anything out.


    Say I would like to inspect this POST:
    stop_the_war_now_you_bastards=4&blabla=asdf...69MB_of_data_here

    Now by putting everything into your dictionary(hash, or array) you have to read over all of the 69MB of data.

    But what if I just wanted to get the value for the first 'stop_the_war_now_you_bastards' variable? Using an iterator or a generator I wouldn't need to process all of that 69MB of data, and everyone could just live in peace. No one likes to give 69MB to someone if there is no need to send 69MB... it's just a waste of bandwidth on the intarwebs.


    raw encoding is needed sometimes


    The problem is that http encoding is not always correct. Sometimes you need to look at the raw encoded version. Like how sometimes different clients/servers encode/decode '+'. This can cause subtle bugs in some cases (like when you are comparing things). I won't explain further... you'll just have to believe me... like how you believe the news.

    Unfortunately keeping the raw encoding around with the decoded version wastes memory. Wasting memory leaves a yucky taste in my mouth. So laziness comes to the rescue again!!! Lazily decode your variables. Hey, no point decoding that 69MB if you don't need it eh?


    Ordering, and duplication of variables


    You are allowed to put any number of different variables in the same request.

    So this means ?a=3&b=2&a=4 is valid.

    But what does GET['a'] give you in most web codes? Are you getting 3 or 4? This is why you need to figure into your abstraction both ordering and duplication.






    *1 The editor and I are the same person. Did you read the editors note words with the same internal voice as the rest of these words? Is the editors voice a deep manly voice, or perhaps a mousey womans voice? Note that the first chain powered bicycles came out later in 1885, a year after my friend was talking about starting a company up to make them. I think someone heard about his designs one night at the pub. oh well.

    Wednesday, July 09, 2008

    Arts grants Australia

    Hacker artists in Australia looking for arts grants? http://artsgrantsfinder.com/ is a fresh site to find grants... if you're in Australia.

    Tuesday, July 08, 2008

    pygame 1.8.1rc1 released for testing...

    See what's new for the release candidate for what's new in pygame 1.8.1. It's what will most likely be pygame-1.8.1release.

    Mostly it will be a bug fix and polish release, but there's a few new goodies that were sneaked in.

    I think we'll release 1.8.1 next week, unless there's any fixes that need to go in.

    See the recent mailing list post for download links, or subversion/trunk if you would like to test it out.

    Thanks to Marcus, Lenard, Brian, Nicholas, Charlie Nolan, Frankie Robertson, John Krukoff, Lorenz Quack, Nick Irvine, and everyone else who helped out with this release.

    Next up for pygame 1.9.0 will be a lot of changes... a camera module with computer vision algorithms, extensive tests, new drawing code, a physics module, a new movie module, an improved mac osx port amongst other things.

    Protocol Buffers - is it really faster than xml?

    It seems google is claiming their protocol buffers are faster than xml... without any proof.

    Consider AsmXml, which can process xml at over 200MB/s on old machines.

    The protocol buffers from google also generate wrappers for different languages, and other nice things. But for loading structures into and out of memory, xml can be very fast.

    Before claiming things like that, I think proof in the form of benchmarks are needed.

    I don't doubt they thought that xml was slower, since many implementations are slower. Maybe xml is slower, but there is no proof yet. Also I'm sure the other nice features of protocol buffers make them perfectly suited for their task.

    Url encoding could have been used nicely too.