making apps, making webs.

http://duckduckgo.com/

Is there a way to find the memory usage of python processes? Trying to find some portable way of doing this. However, so far I think a new module might be needed... I've got linux mostly covered, but maybe you know how with freebsd, OSX, windows(9x-7)? So is there something built into python already? Is there a X-platform third party module already? Or a module just for one platform available? update: here's the linux code I found and cleaned up a bit memory_usage.py if anyone is interested. bytes_resident = memory_usage.resident(). It reads /proc/PID/status... eg, like "$ cat /proc/PID/status | grep VmRSS" would. pympler : 'Pympler is a development tool to measure, monitor and analyze the memory behavior of Python objects in a running Python application.' psutil : 'psutil is a module providing an interface for retrieving information on running processes and system utilization (CPU, memory) in a portable way by using Python, implementing many functio...

MacOSX can sometimes corrupt a drive (like most OSen). I've seen it happen a few times, in a couple of different ways. One way is if you interrupt some file transfers. Like by pressing 'stop' on a big transfer - this can trash your partition table. You'll likely see vfs errors in your log at this point. Anyway... linux, ubuntu and 'testdisk' came to the rescue. testdisk found the partition for me, and wrote it back... luckily it worked and my friend and I did a happy dance. The HFS+ partition was saved.

Ever wanted to get your multi media keys to do something other that play multi media? You could get these key events any number of ways. One way is through dbus. Here is an example: gnome_multimedia_keys.py Here is a version which does not block your mainloop. So it's useful for integrating with other libraries (like pygame :) I made a dbus with pygame example too.

pygame already has a sub-surface, which is part of a larger surface. Sub-surfaces refer to the same pixels as the surface they come from, and share the same Interface as a Surface. It's good for doing sprite sheets, where you save one file with many smaller images - but then being able to manipulate them as if you loaded the images as smaller separate surfaces. However, sometimes we would like to operate on a whole bunch of smaller surfaces stuck together. This is what I'd like to call a Super Surface - a collection of smaller surfaces which can act as one big surface. It's a complementary idea to the sub-surface, and intuitively it should be there... but it's not yet. Unfortunately it's a lot harder to code a Super Surface compared to a sub-surface. Since a Super Surface would need to have all the surface affecting routines changed to work with it. For example, everything in the draw modules would need to be redone. So would all of the surface methods. So whe...

Why bzr and launchpad? Bzr AND Launchpad are open source. launchpad: open source github: closed source sourceforge: closed source (was open source in the past) bitbucket: closed source googlecode: closed source You can submit changes to launchpad at: dev.launchpad.net . As well as ( submit launchpad bugs ) and feature requests against it if you don't want to make the patch yourself. When there is a good open source alternative, I always choose the good open source option. I initially had problems with bzr a couple of years ago... but it has been quite good to me over the last couple of months. So I'm moving over all of my projects from other version control hosting services to launchpad. Of course bzr and launchpad are also written in python (with selected optional C optimizations), so that makes for happy hacking :) update: reported a bug here about the 'can not find source code easily on launchpad' issue. Any other issues with launchpad?

Details, and booking here: http://ldnpydojo.eventwax.com/7th-london-python-code-dojo """What is a coding dojo? This is a coding dojo . Last time we attempted to refactor the various adventure game solutions from the January dojo. Whilst interesting, perhaps refactoring isn’t that exciting an activity for a dojo :-). Nevertheless, people seemed to be having fun and we did achieve our goal of a “one true” adventure game code base that allows us to define and navigate around a game world. The code can be found here: http://github.com/ntoll/code-dojo/tree/master/adventure/week2/ . After discussion at the end of the February dojo (and later in the pub) we decided that this time round we’re going to try another small-groups based exercise with a “show and tell” at the end as we continue to build the world’s greatest adventure game. Problems we might want to tackle include: a command parser, keeping track of game state/score/objects, NPCs/AI, authoring tools, turning it...