- Hey, what are guys up to?
- We are just enjoying some porn
- Hope you’re not doing Java and open source
- No!

The hilarious trailer of JAVATAR makes a brilliant psychological observation of human beings approaching different or new technologies. The technological emotions syndrome as pictured here is funny and scary at the same time. Had there been no emotions expressed about IT, we wouldn’t observe all the holy battles trolled out loudly out there.

- Dad…I have a confession to make
- I use…

Alternative link to the trailer.

Linux vs Windows. FOSS vs Proprietary. C++ vs Java. OSGeo vs ESRI. Python vs PHP. <your favourite technology> vs <your hated technology>

The funny part is the situation comedy being pictured. The worrying thing is, had the comedy not been pictured, we wouldn’t see it’s a comedy. A kind of drama, actually.

I’m amazed, shamefully, how often I forget about it and I drift away thinking how to save on keyboard use and typing.

I’ve just submitted abstract of Boost Geometry presentation for FOSS4G 2010. I’m looking forward to spreading the word and give Introduction to Boost Geometry Library at the FOSS4G conference. Fingers crossed!

In spite of the fact I’m listed as a speaker for BoostCon’10, I will not attend this amazing event. I’ve planned to be there, I can’t make it this year, unfortunately.

“See the turtle of enormous girth!
On his shell he holds the earth.” — Stephen King

Infrastructure supporting a project becomes insufficient, maintenance is difficult, release process is a full-time job and situation has taken a lot of the fun out of participating. Population of users and developers has grown. As the Community gathers appreciable portfolio of masters of the software development craft, it is in constant state of snowball war exchanging fire of ideas, new projects and discussions. It’s truly a pleasure to learn about them but, well, it pours oil on the fire of entropy. Here we come to the crux.

Gain of entropy eventually is nothing more nor less than loss of information — Gilbert N. Lewis

Today, David Abrahams posted, somewhat provocative, e-mail to the Boost project mailing list. It is titled Boost, Decoupled and Accelerated and delivers the following message: It’s time to make Boost development fun again.

It may sound like yet another internal discussion within an Open Source project. There are zillions of similar debates archived around. Yes, indeed, but not exactly. In fact, David announced something that may be of wider interested. It is

a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects

followed by yet more interesting comment

I believe this project has the potential to change the face not only of Boost, but of open-source software in general.

One may think, well, it seems related to the issue of the current trends or we’re suffering redundancy in IT prophets. Perhaps, perhaps, perhaps… but what I know for sure is that David Abrahams is one of my favourite and highly regarded software developer and author. I can hardly recall any of David’s comments, observations or suggestions that would be lacking of point, I mean a very rational point.

I have licked a bit of experience myself of working with or maintaining complex projects or projects that feel complex. I think I wouldn’t risk anything saying David has a point. I’m looking forward learning more about the whole idea.

I hope I’ll be able to confirm it myself while listening to David’s presentation at BoostCon’10.

Here I go we a bit delayed announcement: http://barendgehrels.blogspot.com

Anxiously, however, my enthusiasm is being a little bit repressed. The idea is a double edged sword and instead of navigating ourselves straight to donut heavens, we should rather start hiding such dangerous places from all publicly available maps and guides. This could be a part of health promoting geocaching campaign “Burn to Find”.

And I’m not going to put any smiles in here.

Direct costs are estimated to be £4.2 billion and Foresight have forcasted that this will more than double by 2050 if we continue as we are. — UK DoH report.

One of Boost Geometry (aka GGL) users, Mark, reported that he can not compile his program using the library with GNU C++ compiler from XCode. The compiler throws mysterious complain of a very low-level nature of C++ programming language:

Expected unqualified-id before 'do' in
/usr/local/include/boost_1_42_0/boost/geometry/geometries/concepts/check.hpp

Thanks to follow-up by Stjepan we quickly know who to blame for that. It is XCode header AssertMacros.h. It even might be one of public headers from development package of XNU, the Mac OS X kernel, what’s even more fun.

What actually happens that causes the problem?

Boost Geometry defines function template for concept checking:

template <typename Geometry>
inline void check()
{
    detail::checker<Geometry, boost::is_const<Geometry>::type::value> c;
    boost::ignore_unused_variable_warning(c);
}

Apple XCode defines macro using exactly the same name as the function check. The C++ preprocessor, which operates before compiler, substitutes the name check with content of the macro. For the Boost Geometry function check it means that a pile of garbage is injected in place were the function name is expected:

template <typename Geometry>
inline void do { if ( __builtin_expect(!(), 0) ) { DebugAssert('?*?*',
0, "Third Party Client" ": " "", 0, 0, "/usr/local/include/boost/
geometry/geometries/concepts/check.hpp", 181, (void*)0); } } while ( 0 )
{
     detail::checker::type::value> c;
     boost::ignore_unused_variable_warning(c);
}

Obviously, it makes compiler to give up to instantiate the check function from the template and to compile it properly.

C/C++ macros are evil, however, not by design but by insanity of programmers. Every macro defined in a public C/C++ header, should be defined using as unique as possible, but still usable name. I wish Apple folks designed their C/C++ macros as unique as they make their hardware products, even if made in China eventually. This particular macro that caused the problems discussed here, could be named to APPLE_XNU_CHECK and life would be easier. Or, given the fact that almost 3000 files using these identifiers live in Boost C++ Libraries only, I probably should say: life would be more productive, efficient and cheaper.

By the way, it’s a known problem @ Boost and it looks Boost Folks are trying to figure out best solution. See ticket #2115 – Avoid bad Apple macros.

…to be continued

Hehe, and I didn’t do it because I expect to be given back with a kudo from RMS or Torvalds. I did it because I appreciated the bloody good software development works they do: my favourite C/C++ compiler from GCC, one of my favourite text editors GNU Emacs and my favourite operating system – Unix for Masses and my favourite version control system Git.

Kudos to Duane! And, I suggest any SVN user who reincarnated as Git user to grab and try it.