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!
Archive for the ‘boost’ Category
Boost Geometry on FOSS4G 2010?
Thursday, April 15th, 2010Boost.Geometry on BoostCon’10
Friday, April 9th, 2010
Boost.Geometry talk is scheduled for BoostCon’10 conference. Thanks to Barend Gehrels, Boost.Geometry team will be represented on the conference.
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.
Open Source, Decoupled and Accelerated
Wednesday, March 17th, 2010All right, I confess, I’ve lied a bit in the topic. I’m not going to discuss any of the Free and Open Source Software philosophies here. What I’m going to do is to smuggle an interesting discussion that I believe it may be interesting to other Open Source Software hackers, especially projects from the C/C++ camp of the OSGeo Foundation. I would also say that subject of this discussion is quite idiomatic to the universe of FOSS production. It is about a software project. A project that has grown and it has grown in many dimensions, also in parallel dimensions.
“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.
Boost.Geometry blog
Sunday, March 14th, 2010It’s been a month since Barend Gehrels launched blog dedicated to development of Boost.Geometry library which is also known of its former name as Generic Geometry Library or shortly GGL.
Here I go we a bit delayed announcement: http://barendgehrels.blogspot.com
Boost.Geometry and macros made by Apple
Wednesday, March 10th, 2010I have no pleasure continuing my macros are evil tales but the life of C++ programmer eagerly wants to writes add another chapter to the story. Today, it’s time to rant on Apple and its XCode.
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
Boost Geometry list eNabbled
Saturday, February 13th, 2010For those who are interested in the subject and prefer Web-based discussion forums, I added the Boost Geometry (aka GGL) mailing list to the Nabble as Boost Geometry forum.
Update: Thanks to Hugo from Nabble for importing all archives of the ggl mailing list.
Preparing Quickbook for Boost.Geometry
Sunday, February 7th, 2010I’ve just started writing Boost.Geometry (aka GGL) documentation in Quickbook. It is a lightweight format and parser being developed by Boost used to prepare technical documentation for software, mainly for for Boost C++ Libraries. Quickbook files (.qbk) are used as input for BoostDoc which in turn is an extension of DocBook.
Quickbook is a textual format, it feels quite similar to AsciiDoc or some sort of Wiki dialect but dedicated for documenting C++ programming. It is extremely easy to grasp while drinking a single short coffee.
Anyway, it seems it is going to be a quite a book after all elements of Boost.Geometry are documented. One of the challenge I’ve found is to collect all bits necessary to document C++ concepts defined by Boost.Geometry. Unfortunately, Doxygen is not an ideal tool for this purpose, so current version of the documentation lacks of some sections of concepts description. So, I have to dig the source code to find out formal definitions and details of valid expressions and semantics.
Another challenge related to concepts is to find best way to structure their documentation. I started to browse documentation of existing Boost libraries looking for examples and what I found is that there is no best example. Various libraries document concepts in very different way.
A concept is a set of requirements consisting of valid expressions, associated types, invariants, and complexity guarantees
– David Abrahams, Generic Programming Techniques
For example, neatly Boost.Fusion documents concepts with Quickbook, though some elements seem to be omitted. Boost.Graph doesn’t document with Quickbook, looks good, but some details are missing to me, for instance, titles in headers of tables saying what is what is return type and pre-/post-condition for valid expressions, etc. Documentation of Boost.IOStreams concepts sound well. On the other hand, Boost.GIL is an example of why Doxygen should not be used to document concepts of a C++ library.
It looks to me the old good Standard Template Library Programmer’s Guide at SGI is still a best and most complete example of how C++ concepts should be documented.
Given these experiences, I started to think of a way to improve the way concepts are documented within Boost. I believe it would be a good idea to have predefined block for concept in Quickbook. Something along these lines:
[concepttype [Point Concept]
[this is a concept for 0-dimensional geometry]
[notation
[term 1] [description 1]
]
[refinement [concept 1] [concept 2]]
[associated
[type 1] [description 1]
]
[expressions
[name 1 [expr 1]
[type requirement 1] [return type 1]
]
[semantics
[name 1 [expr 1]
[precondition 1] [semantic 1] [postcondition 1]
]
[complexity [...]]
[invariants
[invariant 1] [description 1]
]
[models [model 1] [model 2]]
[notes
[ note 1] [ note 1]
]
[seealso ...]
]
I posted my proposal to boost-docs list explaining the motivation in details. It’s an interesting experience of a C++ documentation craftsman, anyway. (BTW, Daniel James just announced Quickbook port to Spirit 2.)
