Building Boost-Graph-Library with Python

Today I finally found why bgl-python wasn’t building, there was a three-line buglet in boost/graph/astar_search.hpp found by Andy Tompkins. By applying his patch to astar_search.hpp (and including it in the bgl-python codebase, it builds without errors (only some strict-aliasing rule warnings remain).

Best is: it also compiles on Mac OS X 10.6.3 with XCode 3.2.1

But, so far I must say I really hate bjam as a building tool. I’m seriously considering going with cmake as build system. Any opinions whether or not that’s a good idea?


Building Boost/Python/Graph library

There’s a nice library called bgl-python which can be used to handle graph related problems in python using the, in my opinion, good quality code of the boost graph library. However, bgl-python does not seem to be maintained anymore, which is quite a pity.

Following one of the comments on this blog, I tried to get bgl-python to compile and I got everything compiling with boost-1.42.0, except for one file, astar_search.cpp, which fails with an error message of roughly 50k. Yes. One error: 50k of tekst, it’s got to be C++. The offending line, property_map.hpp:325 looks fine to me:

static_cast(pa)[k] = v;

The problem appears to be in the [k], which, for some case, is a void* instead of unsigned int. I can understand that’s a problem, but I’m currently at a loss why this is happening.

To be continued…


Nothing so far has worked, astar_search keeps getting the compile error. Any ideas are welcome!

Building boost on Mac OS X 10.6

Today I finally had the time to verify that the problems building boost on Mac OS X 10.6 aka Snow Leopard using the compiler enclosed in XCode-3.2 were over. And indeed, building boost 1.42.0 is a nobrainer: just unpack and build.

I’ve built it with these options:

bjam --build-dir=../boost_build --layout=versioned toolset=darwin architecture=combined address-model=32_64 link=shared,static stage

Building boost on Mac OS X 10.6 with XCode 3.2

Getting boost to build in ‘fat binaries’ is a pain when you’ve just switched to XCode 3.2. Switching to XCode 3.2 is somewhat obligatory, because that also brings you the SDK for Mac OS X 10.6, aka Snow Leopard. And when you run the Snow Leopard, you want the SDK for it as well. It sounds so simple.

The Apple version of gcc, included in XCode, stops building boost in fat versions, it works for targeted versions (i.e. with only one architecture). But, if you want to build ‘universal’ binaries that work in 64bit and 32bit mode, you’re out of luck.

I got it to build this morning, thanks to some discussions on the boost mailing list. And it == boost 1_40_0, with XCode 3.2 on Snow Leopard.

This is the command-line I used:

bjam --build-dir=../boost_build --layout=versioned toolset=darwin architecture=combined address-model=32_64 link=shared,static install

And here is the patch I created to get it to work. It boils down to: remove all the ppc entries from the tools/build/v2/tools/darwin.jam, because the XCode compiler does not offer support for PPC anymore. And, you have to remove the “-m64” option in the gcc.jam, because the xcode compiler does not like to have -arch x86_64 -arch i386 -m64 all together on the command-line.

But, if you take the road of building your code on XCode 3.2, you specifically eliminate all those users still using a PPC based Mac. That might not be what you intended. In that case you probably need to add the -V 4.0.1. option to gcc/g++ in which case you use the older compiler (from XCode 3.1), which might or might not be what you need for your project.

(Sorry for the stupid looks on the patch, but wordpress mangles stuff with the <code> tag).

diff --recursive -u boost_1_40_0.orig/tools/build/v2/tools/darwin.jam boost_1_40_0/tools/build/v2/tools/darwin.jam
--- boost_1_40_0.orig/tools/build/v2/tools/darwin.jam 2009-04-14 09:59:30.000000000 +0200
+++ boost_1_40_0/tools/build/v2/tools/darwin.jam 2009-09-06 08:01:26.000000000 +0200
@@ -304,9 +304,9 @@
: $(values) ;

-arch-addr-flags darwin OPTIONS : combined : 32 : -arch i386 -arch ppc : default ;
-arch-addr-flags darwin OPTIONS : combined : 64 : -arch x86_64 -arch ppc64 ;
-arch-addr-flags darwin OPTIONS : combined : 32_64 : -arch i386 -arch ppc -arch x86_64 -arch ppc64 ;
+arch-addr-flags darwin OPTIONS : combined : 32 : -arch i386 : default ;
+arch-addr-flags darwin OPTIONS : combined : 64 : -arch x86_64 ;
+arch-addr-flags darwin OPTIONS : combined : 32_64 : -arch i386 -arch x86_64 ;

arch-addr-flags darwin OPTIONS : x86 : 32 : -arch i386 : default ;
arch-addr-flags darwin OPTIONS : x86 : 64 : -arch x86_64 ;
diff --recursive -u boost_1_40_0.orig/tools/build/v2/tools/gcc.jam boost_1_40_0/tools/build/v2/tools/gcc.jam
--- boost_1_40_0.orig/tools/build/v2/tools/gcc.jam 2009-07-11 13:04:31.000000000 +0200
+++ boost_1_40_0/tools/build/v2/tools/gcc.jam 2009-09-06 08:11:17.000000000 +0200
@@ -375,7 +375,8 @@
- option = -m64 ;
+ # option = -m64 ;
+ option = ;
OPTIONS on $(targets) += $(option) ;

Flexible keyboards

IMG_4194 IMG_4196

I’m a very happy user of the ‘old’ Sun Type 7 keyboard. Actually, I’m hoarding them, since, Oracle is going to kill the Sun hardware business and the Type 7 is one of those keyboards with all the keys in the right place. Control is left to ‘a’ and backspace is not in the top row, but one below, just above the ‘return’. In order words, I’m a sucker for keyboards and I’m really sensitive to their touch and feel and click and whatever there is to them.

Today I saw someone mysteriously put a silicone keyboard (it flappy and flexible, but no brand label to be seen) in my room and I had to try it. Actually, I’m trying to type on it for this blogentry. And, I’m not really a happy customer. Let me count the ways in which this board does not suck:

  • It’s very cool to fold away your keyboard when you’re not using it.
  • It has an uncounted number of shift keys. Well, there are four.
  • It’s featuring (sort of) in Die Hard IV.
  • It feels nostalgic.
  • You can spill stuff on it.
  • It fits in you backpack, or even the side pocket of your cargo pants.

Ok, that was the good stuff. Now for the less convenient stuff.

  • It stinks, as in, it has an awful plastic smell about it.
  • It stinks, because I’m actually trying to type less, because I’m prone to mistype on this thing a lot.
  • It gives me carpal tunnel syndrome with just using it for the past half hour.
  • It is very wobbly, even when I put it on a sturdy surface area.
  • Did I mention it has four shift keys? And two space keys, but you can still touch them without any reaction? It even has keys on them without any label at all.
  • It has windows keys on it, but more keyboards do, so I will not hold it against it.
  • It doesn’t have a brand label on it, so it must be crap. Otherwise, someone would put a label on it to say that they’re responsible for it. Probably they’re quite scared of someone suing them into oblivion.
  • The control key is broken.

So that’s it. Unless you want to look really cool and like you’re in Die Hard 4, get it. Otherwise, give your wrists and hands and the rest of your body some rest and stay away from it.

Coolness: 7/10 (hey, it’s in Die Hard Four) (but it does not glow in the dark)
Function: 3/10 (with working control: 4/10)
Weight: 8/10 (it’s very light)
Space: 10/10 (it takes up almost no space in your backpack. That’s good).
Total: 5/10. If function is not good, forget it.

Gems documentation

When trying metric_fu, gem told me quite gently, though persistently, that it did not know about metric_fu. Blimey. You’ve got to look around the Intarnetz, but then you can find the stuff you need to get more than one repository.

So, what’s the trick?

gem sources

lists the sources that are already available.

gem sources -a

adds that source to the other sources. Jay! That’s what we needed,

RSpec and Forensics

I’m currently reading the beta edition of the RSpec book by David Chelimsky Because a book like this can only be comprehended when actually using the content, I’ve decided to start documenting a new project I’m doing with it.

So far, it has been about Behavior Driven Design (BDD), which is an acronym I’ve head before, but I didn’t have the time to read more about it.

It feels a bit weird specifying stuff using mostly natural language, but on the other hand it’s naturally very cosy to do so. What’s really neat is that you start using the api you want to specify right up, instead of first formalizing a design for it. That way you known that all the methods in your api really belong there and actually work.

While I was busy to code up some small project I received the new linux journal, which had an article on metric_fu. It contains a lot of code that can measure the quality of your code. That is always good to do, because the more checks you perform on your code, the bigger the chance that you run into a bug waiting to happen. Of course, you also run into false positives faster, and most people stop using checks like these because they run into false positives too often.

But reading the article I was thinking to myself: why don’t we use BDD combined with something like metric_fu on hour one-off tools we create to solve a case? Most forensic practitioners I know are bound to run into the situation where all the available tooling is not adequate to perform a certain job. Things that come to mind are refiling images based on camera, but oh wait, based on resolution first, or extracting all email addresses from an image and compare them to some filter, These things should be rigorously tested before put in use, because a simple code snafu can dump all your stuff in the bin and will cost you valuable time to clean up again. There is in this case an obvious tradeoff between codingtime, solvingtime, clean-the-errors-time and the time you need in court to explain that you did everything in your power to not botch up the code. For that last part you would ideally show testing output that shows that your testcases have a 100% coverage and pass every test you thought was possible.