I’m starting to use gpg.

This isn’t the first time that I have said to myself, “Hey, I should start using gpg!” I have had that idea twice before. And each of those times I made myself a key then just forgot about actually trying to use it and collect signatures on it. I never published those keys, and as time went by I forgot their passphrases.

I’m off to a much better start this time, as I cross-signed with my friend Asheesh today, published my key, and configured gpg integration in my MUA. So my new key will actually be seeing some use.

For those of you interested, my key ID is 9C121F46, and the fingerprint is C25D 9D2F F3F1 3D72 ADEB D54C F1DB 6C38 9C12 1F46. I uploaded my key to keys.gnupg.net and pgp.acm.jhu.edu. I will put this information on my contact page too.

(The svn won’t be going anywhere – further development in git will be mirrored into svn.)

I had been wanting to do this for some time, but I was finally convinced to do it when I had an hour-and-a-half-long power outage (and therefore lost Internet access) when I was about to commit a change to libfogg. The inability to do more work and keep clean development history without resorting to diffing out what would have been my commit really got to me.

Happy distributed hacking!

Since I’m starting to use this more regularly after precisely 16 months of sporadic activity (counting from the welcome post), I figured I’d analyze said welcome post and see how much of it I have managed to stick to.

Welcome to my blog of code, freedom, gaming, computing, and some other stuff. (I will say it now: most of my blogging will probably be software-related.)

How right that last part has been. Since establishing this and letting it (most of the time) just sit here, my computing focus has switched almost entirely to software. I just haven’t felt inclined to blog about the other stuff.

I have many software projects going on now. I am in the process of placing all of them onto my Subversion server, but the ones I work on the most are there. Check it out (literally) at https://svn.stump.jstump.com/svnroot/ (read-only – I commit through svn+ssh) or browse around at https://svn.stump.jstump.com/websvn/. Patches are always welcome! I will always post when I tag a release, including full build instructions.

It’s http://svn.jstump.com/r/ and http://svn.jstump.com/websvn/ now, but help is of course still welcomed. Some projects have even grown their own mailing lists and Trac instances now that I run my own VPS. I haven’t stuck to what I said about blogging releases, but I didn’t feel any were that major anyway – the only stuff with release tags is Python extension modules used by FoFiX (which I probably should move to the FoFiX repository). There’s stuff that’s nearing completion that is more blog-worthy though (if, say, the kexec project’s intentions are any guide to go by). Also, when I amass the willpower to rewrite lots of my infrastructure code, we’re going to git, as mentioned in my most recent post before this.

I write software for Windows and GNU/Linux; nearly all of it is under “GPLv3 or later”. I will post about specific software projects whenever something interesting happens.

Since that post, I have indeed maintained a habit of writing strictly cross-platform code unless there is a reason not to, and have stuck to the GPL wherever it makes sense.

I am an avid player of Dungeons and Dragons (version 2) and the Classic Marvel RPG. (My GM is the very best.) When it comes to downtime, it’s hard to beat rolling oddly-shaped dice. Knights of the Dinner Table is the most epic magazine.

The place in which I played in said campaign closed up in July 2009, and the campaign died with it, but I got involved with other campaigns around that time. Unfortunately, moving into college killed those, and nothing I have found since has been the same. (In a way, though, the timing of the closing of the store worked out for the best, as I’m not sure how well I could have borne having to leave that campaign behind were it still active.)

Until Stump GNU/Linux works (which is probably quite a long time from now), I primarily use Ubuntu and Debian. (Naturally, I will be “eating my own dogfood” once it’s feasible.) My preferred non-free OS is by far Windows Server 2003, and I know both Windows and GNU/Linux quite well (as both a user and an administrator). (Indeed, I have dabbled in Windows enough to gain a certification or two.)

I shelved Stump GNU/Linux very soon after that post but am interested in picking it back up again at some point. ’03 is still my favorite non-free OS, even with Windows 7 now out, though 7 came close to unseating it.

See you when something interesting pops up 😉

Yes, yes, yes…

For some patches and scripts that I contributed to the Performous project to help with Windows portability, I now have one more commit bit (since it’s git in this case, push access) to my name.

Probably the best part of deciding to contribute was actually learning git itself so I could maintain the history of my own changes even before I shared my changes with the other developers. This marks the first time I have made serious use of a DVCS of any kind, and I must say that I am impressed by the new workflows DVCS makes possible, especially those that would be nigh-on impossible under a non-DVCS such as my current VCS of choice, which is Subversion.

You can probably reasonably expect any new projects I create on jstump.com to use git unless there is a major reason to still use svn. I may even convert some of my other projects. (The main obstacle, of course, is forcefully shoving git into my awesomely-constructed current svn+trac+custom authentication setup. I guess we’ll see how that goes when I have some extra time on my hands.)

Performous is a GPLv2+ band rhythm game that started out with just vocal play and expanded into guitar and drums not too long ago; this is the opposite of how Frets on Fire X evolved. (My commit access to FoFiX was granted last New Year’s Day, and in that time I have arguably become one of its core developers. I will look back on my experiences working with FoFiX once I hit the one-year mark since it’s so close and I’ve digressed enough already.)

It’s a strange feeling, now having commit access to two projects that the uninitiated observer might say are directly competing. Things are friendly and fair, though, and I have only the best intentions for my participation in both.

Merry Christmas to all, and to all, happy hacking!

If you have ever had to py2exe a Python program using pyOpenGL, you know that it’s a painful, tedious, but above all unclean process. (Even back with 2.x, that “version” file was so troublesome, but here we have one of py2exe’s worst enemies: funky import hooks.)

I actually figured this out some time ago and have been using it in many of my projects; I first did it for Frets on Fire X (FoFiX), and now, upon finding a certain lack of this information elsewhere on the Internet, I’m bringing it to you here.

Other documents advocate excluding the OpenGL package from your distribution and manually adding it back in after you actually run py2exe.  However, it’s actually quite trivial to work around the weird import hooks.  The hooks don’t care whether import (well, really, __import__…) is operating the standard CPython way (loading modules and packages directly from the filesystem) or through zipimport, just as long as it returns something useful and doesn’t raise ImportError.  So we can just force the stuff that gets indirectly imported to be included when py2exe does its thing.

It’s a case of passing the necessary module names to py2exe via the py2exe includes option.  To do that, pass a dictionary as a keyword argument named options to setup. In that dictionary, assign the key py2exe to another dictionary. In that sub-dictionary, set includes to a list that contains (at least) the following strings:

OpenGL.platform.win32
OpenGL.arrays.ctypesarrays
OpenGL.arrays.numpymodule
OpenGL.arrays.lists
OpenGL.arrays.numbers
OpenGL.arrays.strings

(Note that you probably won’t need all of those array converters, and you may in fact need extra ones. Those should cover practically all use cases, though. FoFiX, which is a quite involved codebase, only needs those.)

If all goes well, everything that pyOpenGL 3.x needs to run should end up actually in the distribution (cleanly!) once py2exe is invoked with the new includes.

If you need to see an example of this in action, see FoFiX’s setup.py script, and all will become clear to you.

Happy py2exeing with pyOpenGL 3.x!