- 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’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!

“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

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

By the way, I crafted AX_LIB_LIBKML macro for Autoconf. This macros checks for headers and libraries of specified version (or newer) of Google libkml library and defines compilation and linking flags.

I submitted the macro to GNU Autoconf Archive. It is the new incarnation of well-known autoconf-archive.cryp.to. Peter Simons announced not long time ago that

The archive has moved to Savannah: http://www.nongnu.org/autoconf-archive/. Version 2009-04-26 was the last to be released at autoconf-archive.cryp.to.

Happy detecting libkml!

A: The lesson is I ought to get things right the first time.
B: The issue with const method is that if you want to add lazy loading later, it can cause problems
C: GDAL is rather painful to use with const correct code, unfortunately :(
B: The solution is obvious: don’t write const correct code

Who’s right then, A or B?

I recall another motto from #gdal channel that sounds like “when unsure, do nothing” which has the following rationale:

especially when I realize afterwards that I’ve f**cked things because I neglected to follow the motto

Remembering these recommendations, it’s pretty clear why the const-mess in GDAL has happened. I’d conclude paraphrasing the motto this way:

I’ve f**cked things because I neglected to make a decision.

Now, poor GDAL beginner deadpickle, trying to find out (it’s me the evil) why compiler complains about his not-that-bad-written code, wandered to find and ask C gurus @ comp.lang.c and got the problem explained by Malcolm who wrote:

The problem is that, when C was first developed, there was no const keyword. So strings literal, which are constant, had to be non-const for backwards compatibility. This means that lots of programmers get lazy and omit the const, even from functions which don’t modify their string arguments. (There are also some subtle problems with const which means that this isn’t always a case of pure laziness). So a sort of solution is to discard the const qualifiers. However this is perpetuating the problem in your own code.

The motto stays in contradiction to a well-known best practice of const correct sooner than later. It’s way easier and cheaper to remove const-correctness once it turns out it does not express properly the actual design and contract than to apply it to existing codebase. Sometimes, the latter is even not possible making things f**cked up twice, in existing code base and in client’s code.

At 4:30, I am going to be interviewed for FLOSS Weekly.
The chat is here:
http://irc.twit.tv/
The video is here:
http://live.twit.tv/
Should be going on some time around 4:30 EST.

It’s on now.

UPDATE: FLOSS Weekly 111: CMake archived audio podcast

A few words about GIS-Lab from their website:

GIS-Lab – informal non-commercial community of GIS/RS specialists, we grow ourselves and help grow others.

GIS-Lab exists since April 2002 as an independent online resource specializing in geographic information systems (GIS) and remote sensing (RS). At present, the site is primarily oriented towards Russian-speaking GIS community, however, we do our best to translate as many materials as possible into English.

The GIS-Lab is the very first blog in Russian language syndicated with the Planet OSGeo, what makes the planet yet more international geo-caffee.

I checked Well-Known-Binary output as returned by the SqlGeometry method STAsBinary(). Here is a small test program written in C#:

using System;
using System.Linq;
using Microsoft.SqlServer.Types;
namespace SqlGeometryEmpty
{
  class Test
  {
    static void Main(string[] args)
    {
      foreach (string type in
         Enum.GetNames(typeof(OpenGisGeometryType)))
      {
        string wkt = type.ToUpper() + " EMPTY";
        SqlGeometry geom = SqlGeometry.Parse(wkt);
        byte[] wkb = geom.STAsBinary().Buffer;
        string wkbhex = string.Join("",
          wkb.Select(
            b => b.ToString("X2")).ToArray());

        Console.WriteLine("{0}\n{1} ({2} bytes)\n",
          wkt, wkbhex, wkb.Length);
      }
    }
  }
}

The first observation is that WKB of EMPTY geometry for all types is returned as a a slightly different binary. All the binary forms are truncated to nine bytes. The first byte indicates endianness as expected. The second chunk of four bytes indicate geometry type. It is exactly as defined in OGC specifications. The third chunk of remaining four bytes are set to Zero and seem to play a role of size specifier: number of points in LINESTRING or number of rings in POLYGON, number of points in MULTIPOINT, and so on. This makes another observation that WKB for EMPTY is reported as a collection of primitive components.

The difference in binary of WKB of EMPTY geometry I mentioned is in that the actual type of input geometry is preserved, so there seems to be no implicit translation to geometry of some other type.

So far so good but not for too long. In fact, SqlGeometry implicitly casts POINT EMPTY to MULTIPOINT EMPTY geometry with the WKB of the following form (in hex):

010400000000000000

Here is complete output of the test program above:

POINT EMPTY
010400000000000000 (9 bytes)

LINESTRING EMPTY
010200000000000000 (9 bytes)

POLYGON EMPTY
010300000000000000 (9 bytes)

MULTIPOINT EMPTY
010400000000000000 (9 bytes)

MULTILINESTRING EMPTY
010500000000000000 (9 bytes)

MULTIPOLYGON EMPTY
010600000000000000 (9 bytes)

GEOMETRYCOLLECTION EMPTY
010700000000000000 (9 bytes)

A word about how PostGIS behaves. PostGIS reports GEOMETRYCOLLECTION EMPTY, regardless of actual type of input EMPTY geometry. It is in hex form:

010700000000000000

Generally, there is not many choices of how to report EMPTY geometry in clear and usable way and a form of collection with size equal to Zero seems to be the most appropriate choice. POINT EMPTY reported with type set to POINT (010100000000000000) would be ambiguous as feels like truncated or invalid form of POINT(0 0), especially in programming languages like C where native dynamic allocated arrays do not carry information about their size. IOW, geometry type is not enough information to process binary form of POINT EMPTY properly.

Reporting EMPTY geometries as a collection is a useful convention that seems to work well. PostGIS behaves about it in the very consistent manner reporting one type for all empties. SqlGeometry, so SQL Server, forces programmers to write a few more lines of code to handle all the possible cases. Yet another original exotic solution from Microsoft.

Consistent API is a bless!

Update: consistent specification of interface is even better.