lunglet.net

Java Genetic Algorithms Package (JGAP) is (surprise) a genetic algorithm package for Java. JGAP 3.2 was recently released. Coolest feature: you can use JGAP to evolve a Robocode robot (more about Robocode).

After reading this post by Bill Pugh to OpenJDK’s quality-discuss mailing list, I immediately gave FindBugs a try. The Eclipse plugin for FindBugs is highly recommended. Getting FindBugs going is Maven is a bit more… interesting. I think you want the findbugs-maven-plugin, although there’s also a maven-findbugs-plugin. It seems findbugs-maven-plugin includes support for FindBugs 1.2.0, but I wasn’t able to consistently convince it to use that instead of 1.0.0. Good luck.

I promptly unleashed FindBugs on Apache ActiveMQ and found some minor issues and some more serious issues. Maximum respect to Rob Davies for fixing the latter collection.

Update: I unleashed FindBugs on JRuby. See JRUBY-1173.

Quote of the day from Java Concurrency in Practice: “The primary abstraction for task execution in the Java class libraries is not Thread, but Executor.”

I received what I am choosing to call the first pyactivemq bug report. World domination is now but a mere formality.

I recently ported one of the JMS examples from the Java EE 5 tutorial to Python and pyactivemq. Check it out on the Examples page. Everything works, except the final call to cancel the subscription. This should work once AMQCPP-132 gets fixed.

I’m currently working on some algorithms for which I’ve found it very useful to be able to generate the same random numbers in Python (using NumPy’s numpy.random module), C++ (using the Boost Random Number Library) and MATLAB (using the rand function).

I use the random numbers in tests, where being able to generate the same random numbers everywhere has been very useful. It allows me to compare the output of my algorithms exactly. For example, I might implement an algorithm in Python with NumPy first, write some tests, and then rewrite it in C++ (for the cases where I need the extra speed).

Getting MATLAB and NumPy to generate the same random numbers is straight forward. It seems NumPy uses the Mersenne Twister algorithm. MATLAB can be configured to do the same. Specifically, the following code generates the exact same 10 numbers with NumPy 1.0.3:

numpy.random.seed(0); numpy.random.rand(10,1)

and MATLAB R2006b:

rand('twister',0); rand(10,1)

However, the Mersenne Twister combined with a uniform distribution generator from the Boost Random Number Library don’t generate this same sequence. A quick glance through the NumPy and Boost code seemed to indicate that they use the same magic constants. I used the following C++ code with Boost 1.34.0:

#include <boost/random.hpp>
boost::mt19937 rng;
rng.seed(0U);
boost::uniform_real<> uni_dist(0, 1);
boost::variate_generator<boost::mt19937&, boost::uniform_real<> > uni(rng, uni_dist);

I’m guessing that NumPy and Boost simply do slightly different things with the bits that come out of the MT algorithm to generate the respective uniform distributions.

To work around this problem, I cooked up a Boost.Python wrapper for the Boost Random Library classes so that I could generate exactly the same numbers in Python and C++. You can take a look at the code here (the tests are still a work in progress):

• random.cpp
• test_random.py

The interface exposed by this wrapper behaves more like the stuff in numpy.random, compared to the wrapper in pyboost, which could be considered a very literal translation. It probably also wouldn’t be too hard to wrap these classes with MEX for MATLAB, guaranteeing you the “same” random numbers across all three platforms.

Disclaimer: I am not an expert on anything related to random numbers (except making them up in my head).

Unbeknownst to me, libstdc++ has some very cool debugging features that can be enabled by defining some or all of _GLIBCXX_DEBUG, _GLIBCXX_DEBUG_PEDANTIC or _GLIBCXX_CONCEPT_CHECKS. You can read more about these defines in Debugging schemes and strategies and Concept checkers — new and improved! Combined with Valgrind, this provides most of the tools you need to find bugs in many C++ programs.

Along these lines, you might also be interested in libcwd, which is “a thread-safe, full-featured debugging support library for C++ developers.”

Spotted a mention of the libstdc++ defines in a comment to Memory Checker Tools For C++? on Slashdot.

Update: I think the documentation mentions this somewhere, but I still got bitten by this issue: you can’t mix code compiled with these defines with “normal” code. In my case, I was trying to link some debug code against CppUnit installed on my system, with strange results (for example, you’ll see a destructor in the normal code segfault as it tries to deallocate a debug std::string instance).

After employing various debugging techniques (mostly some RTFM and printf debugging), I was able to get C++ threads to call back into Python code successfully. In pyactivemq, this allows you to register a MessageListener on a Session and have the thread associated with the Session call into Python whenever a message arrives.

All the info I needed to solve the problem was contained in PEP 311: Simplified Global Interpreter Lock Acquisition for Extensions and Thread State and the Global Interpreter Lock. My main mistake was that I didn’t call PyEval_InitThreads() in my module’s initialization code, which seems to turn attempts to acquire the GIL into a no-op, which meant that I had multiple threads calling into the interpreter at the same time, with the associated “interesting” results.