[minecraft] That's right, I said Minecraft...

A couple weeks ago I decided I wanted to practice my Java coding. I looked around for possible Java projects, and I came across Minecraft modding. Writing a mod seemed like a great project because it would be fun and easy to get started (thanks to the modding community being very friendly and active).

There are two kinds of mods: single player and multiplayer. Single player mods can do neat things like add items and monsters to the game. Multiplayer mods are a slightly more restricted because only the server code is modified and the mods can't do anything the original client can't handle. I chose to create a multiplayer mod because I also wanted to run a server for my friends.

For multiplayer mods there is an unofficial extension framework called Bukkit. Bukkit is split into two pieces of software. Bukkit proper is an API programmers use to write their plugins. Craftbukkit is a modified server with plugin management. If you want to write a plugin, you want Bukkit. If you want to run a server with plugins, you want CraftBukkit. The Bukkit API is changing all the time, so the best documentation is the source, but I've also found these java docs to be useful.

My plugin is called HealingTotem. It allows players to regenerate health if they are in the proximity of a Totem. The concept is simple, but the design had some interesting twists. As far as I know, this is the only plugin which searches for configurable block patterns. Users can define block patterns, or structures, as a list of blocks with a relative offsets and material types. My plugin efficiently searches for structures as blocks are created and destroyed. Typically, other plugins require the use to enter a command to perform a check, or "activate" the structure by using an item on a block. As a bonus, my plugin searches for structures at different orientations.

I might write some more Minecraft modding related posts later, but for now I just wanted to share my work, so here it is:

HealingTotem - Health Regeneration from Totem Poles (source)

Google Labs is shutting down?

Today I learned that Google Labs is shutting down. Google has said it will be "ending Labs experiments," which seems like a nice way of saying, "pulling the plug." It seems like a real shame. That means no more cool things like this, or this.

[pymex] Or you could just use Jython...

I recently discovered an alternative to pymex: using Jython inside the Matlab interpreter. Jython is an implementation of the Python interpreter in Java. The Matlab interpreter allows the importing of Java objects, so all a programmer needs to do is import the Jython interpreter. Here is an example:

>> javaaddpath('C:\Jython25\jython.jar')
>> import org.python.util.PythonInterpreter
>> import org.python.core.*
>> interp = PythonInterpreter()
 
interp =
 
org.python.util.PythonInterpreter@22ff0470
 
>> interp.exec('import sys')
>> interp.exec('print sys')


>> interp.set('a', 42)
>> interp.exec('print a')
42.0

>> a2 = interp.get('a')
 
a2 =
 
42.0

Jython is really cool, but it does have a drawback. Modules written in C for CPython are not compatible with Jython. That excludes alot of modules, but that may not bother some people. If you do need to use a CPython module, you can use pymex.

[pymex] Threading

Threading didn't really work in the first version of pymex. You could create a Python thread, but it wouldn't actually get any execution time. I recently found out why, and fixed it!

Python has limited support for multi-threading. The Python interpreter is not fully thread-safe, and something called a global interpreter lock (GIL) is used as a sort of mutex on the interpreter. Only the thread which has acquired the GIL can interact with Python objects or use the Python C API. The negative side-effect of the GIL is that Python threads run more-or-less contiguously, instead of concurrently. Thus, Python threads can't take advantage of parallel hardware.

By default, Python runs in one main thread and the GIL is not initialized. Threads and the GIL are automatically initialized when a Python thread is created. Python automatically shares the GIL between threads so each thread can execute. This is accomplished by threads yielding on certain functions like I/O, sleep, etc. This doesn't happen for C extensions, they must explicitly release the GIL using the C API.

The old version of pymex would never release the GIL. The GIL would still get released, but only while the Python interpreter was running (during a call to PyRun_SimpleString). This meant that threads would only get CPU time during calls to pymex, and not during normal Matlab execution. Python scripts which joined their threads before ending didn't have a problem, but daemonized threads didn't work at all.

The fix was actually very simple. All I had to do was release the GIL using the C API before returning from the mex function, and reacquire it on reentry. This was done using PyEval_SaveThread and PyEval_RestoreThread. I also decided to release the GIL inside the matlab module during various (slow) mex calls, like mexPrintf. I did this to hopefully increase Python's threading performance.

But there was one drawback: added complexity. Programmers now need to consider thread-safety. Unfortunately, Matlab's mex interface isn't thread-safe. By extension, the matlab module isn't thread-safe. Don't use the matlab module inside a thread, it is liable to segfault! There is an exception to this rule. It is safe to use the matlab module in a thread as long as it ends before the script ends (i.e. the thread is joined). That way the underlying mex calls only occur during the call to pymex, so memory access violations are avoided.

Check out the pymex website for more details!

I graduated!

I graduated! After four years of undergrad in EE and two years doing my MS in CompE, I'm finally done with school and ready for the real world!

School has been great, and I was very fortunate to work and study with great people. My advisor John Spletzer is a great guy, a genius, and has taught me more than I can remember. My coworkers, Jason Derenick, James Evans, Amy Forando, Chao Gao, Sean Kelly, Ben Mak, Tom Miller, Mike Sands, Constantin Savtchenko, Justin Sonntag, Dave Stolfo, and Nick Welton, made VADER Lab a great place to work. They are all intelligent, stimulating, and fun people. I could not thank John and everyone else enough for their support, insight, and hard work.

It's always sad to leave, but I'm also happy to be moving forward. All I need now is a job... on to the job search!