fidzu : Turbogears

19 Apr 2010 12:10pm GMT

19 Apr 2010 12:04pm GMT

13 Apr 2010 6:43pm GMT

13 Apr 2010 7:35am GMT

10 Apr 2010 4:15am GMT

This post is going to ramble a bit, and I apologize. Almost two years ago, I got an Asus EEE 901 netbook. This is a great little device, letting me have a highly portable laptop style computer. I then got the idea to use it for GeoCaching, and wrote Cache 901. The problem I face now is that it's time for me to hand Cache 901 over to somebody else.

When I wrote that program, GeoCaching was something that would be done every couple of months. We'd go out, find a couple caches, have some fun while doing so, record them, and get back on with our lives. Since then, something's changed, and we haven't done it for over a year by now at all. Since we're not GeoCaching, and it doesn't look like it will happen again anytime soon, I've stopped working on Cache 901.

Now, Cache 901 is a good program, and fairly popular (as of now, it's been downloaded nearly 900 times so far this year). I don't want the program to die. I also don't want to be responsible for taking it to the next level. I want to hand it off to somebody else. I want it to become active again. The worst part is that I don't know how to find someone to take it over.

If you have any suggestions, please let me know.

07 Apr 2010 10:36pm GMT

05 Apr 2010 5:26am GMT

29 Mar 2010 9:48pm GMT

29 Mar 2010 3:05am GMT

So, I've switched recently to EMacs. Mostly doing okay with the switch, but today I wanted to do something I'd not seen mentioned elsewhere: I wanted to use it as a 3 way diff tool, and integrate this with Mercurial. Turns out it's not too hard to do at all.

First, you'll need to make the following into a script. I named it "ediff3":


#!/bin/bash
if [ $# -ne 3 ]; then
echo Usage: $0 local base other
exit 1
fi
emacs --eval '(ediff-merge-with-ancestor "'$1'" "'$2'" "'$3'")'

26 Mar 2010 9:16pm GMT

20 Mar 2010 4:31pm GMT

17 Mar 2010 12:32am GMT

virtualenv is an absolutely wonderful tool. I use it every day in so many ways, and enjoy the freedom it gives to experiment with anything. Found a new tool, and want to try it out, but don't want to screw up your system's Python libraries? Try it out in a virtualenv!

Unfortunately, getting wxPython in a virtualenv is a painful process, and definitely takes some work. Here's the steps to do so:

1. Download this patch, and save it as $HOME/wxpatch.txt.Without this patch, wxPython2.8.10.1 will fail to compile properly. Hopefully, this will be fixed in the next release.
   
2. Make your virtualenv. If you're like me, you're going to be using virtualenvwrapper, so you'll run this command:
   
   
   
   

   mkvirtualenv --no-site-packages wxpython
   

   
   
   
3. Activate your virtualenv. If you are using the virtualenv wrapper I linked above, you would do "workon wxpython". Otherwise, it will be "source $PATH_TO_VENV/bin/activate".
4. Download the wxPython source and save it as $HOME/wxPython-src-2.8.10.1.tar.bz2
5. Now comes the messy command. Yes, all of these are genuinely necessary in order to make this work properly. Make sure to substitue "$PATH_TO_VENV" with the appropriate real path to the root of the virtual environment you made in step 2. Warning: The next steps will take a long time.
   
   
   
   

   cd $HOME
   tar -xjf wxPython-src-2.8.10.1.tar.bz2
   cd wxPython-src-2.8.10.1
   patch -p0 < $HOME/wxpatch.txt
   ./configure --prefix=$PATH_TO_VENV --with-gtk=2 --enable-unicode --with-opengl
   make install
   cd contrib/src/stc
   make install
   cd ../gizmos
   make install
   cd ../../../wxPython
   python setup.py install 
   
   

   
   
   
6. Finally, you will need to ensure that your LD_LIBRARY_PATH variable is configured. If you are using the virtualenv wrappers mentioned above, create a script named $PATH_TO_VENV/bin/postactivate that has the following contents (no substitutions of any sort here at all!):
   
   
   
   

   export LD_LIBRARY_PATH=$VIRTUAL_ENV/lib:$LD_LIBRARY_PATH
   

   
   Now, set the script to be executable.
   
   
   
7. If you're not using the virtualenv wrappers mentioned above, edit $PATH_TO_VENV/bin/activate and add that same line at the end of the file.

With all of the above done, you only have to activate the virtualenv, and you can then import and use wx inside of it without problem.

16 Mar 2010 7:14pm GMT

import this

16 Mar 2010 5:56pm GMT

tg.predicates.has_permission('manage')

15 Mar 2010 9:33pm GMT

EDIT: I added YAML testing data to the results. I'm not posting my original files, as I don't have a license to be converting this game, and don't want to trip any legal issues. Suffice to say that the names in the file give it away.

EDIT: I added ElementTree testing data to the results.

I've begun working on translating a board game into a computer game. In order to do so, I need to be able to represent the state of the game and its many (many) tokens. In addition, I need to be able to store and load that state quickly. Finally, I need that state to be something that I can represent with a single string.


Storing the state presents a simple hierarchical structure: Multiple decks of cards are shuffled, and the shuffled state must be saved. This allows for a web front end to the game. The cards are just one aspect: I have to store information about what cards the player has, what state the cards are in, where the player's token is, and what feels like about 500 pieces of information (no joke: I scanned 494 images for this game).

So, how do I represent this data? How do I make it so that a web server can load and save the state quickly? XML is good for hierarchical data, as are JSON and YAML. But which one is right this time?

I needed to test it out. So, I wrote three equivalent files, one in XML, one in JSON, one in YAML. I then ran the timeit module against those files, using the following commands:

• python -m timeit -n 100 -s 'from xml.dom.minidom import parse' 'd=parse("allboard.xml")'
• python -m timeit -n 100 -s 'from xml.etree.ElementTree import parse' 'd=parse("allboard.xml")'
• python -m timeit -n 100 -s 'import simplejson' 'd=simplejson.load(open("allboard.json"))'
• python -m timeit -n 100 -s 'import yaml; from yaml import CLoader as Loader' ' d=yaml.load(open("allboard.yaml"), Loader=Loader)'
• python -m timeit -n 1000 -s 'from lxml import etree' 'd=etree.parse(open("allboard.xml"))'
• python -m timeit -n 100 -s 'from xml.etree.cElementTree import parse' 'd=parse("allboard.xml")'

The results were simply staggeringly different.

XML (minidom) took 15.3ms per run. XML (ElementTree) took 19.6ms per run. XML(lxml) took 925usec per run. XML (cElementTree) took 1.35ms per fun.JSON took 250usec per run. YAML took 10.1ms per run when using the CLoader. Without the CLoader, it took 115ms per run.

JSON wins this one hands down.

Is it possible I chose poorly? Of course. There are many XML parsers for Python, just as there are many JSON parsers. I wanted pure Python here, so as to maximize portability. I chose these modules since they should be completely standard. If I'm wrong, tell me, and I'll revisit this.

12 Mar 2010 8:54pm GMT