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 ‘ggl’ 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.
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 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.)
When Boost.Geometry release?
Sunday, February 7th, 2010The Boost 1.42 was released a week ago, however this release does not include Boost.Geometry (aka GGL) which was accepted 2 months ago. It is nothing uncommon, though many people have been asking obvious question, why Boost.Geometry is not there and when it will be there.
Boost.Geometry is accepted but with a sticky note attached with a list of issues that need to be solved before the library can be included in official Boost release. It means there is still plenty of work necessary to be done and as soon as they are done and confirmed, we’re in.
Hartmut Kaiser, the review manager, included compete and detailed list of all the issues that need to be addressed in the GGL review results report. Shortly, the contingencies are:
- Robustness: complete review of all elements of the library to assure it allows to instantiate all algorithms with arbitrary number types. By design, it is possible to specialise types and algorithms of Boost.Geometry with GMP or CLN, so it computes with arbitrary-precision arithmetic. This feature is possible thanks to numeric_adaptor developed by Bruno and Barend. Also, details of computational complexity per algorithms shall be updated.
- Concepts: during the review, a few problems have been revealed with adapting custom geometries for Boost.Geometry. The concepts are a moral backbone of the library, so they need to be sound making the adaptation process simpler as that’s what the whole idea of concepts in C++ is for.
- Boolean operations: robustness and coping with different coordinate orders of polygons should be improved.
- Documentation: currently only Doxygen-based documentation is available. This system does not work well for Boost, so migration to Quickbook system is to be done.
- Testing: simply, a collection of basic unit tests is not enough and verification of the correctness of the algorithms in a wide range of use cases is necessary along with high volume and random tests.
There are also a few minor issues specified as non-contingencies, however.
It is quite a list and plenty of work that needs to be done and Barend replied on the list:
We’re working on the library, I don’t hope it will take us that long, but 1.42 was not feasable at all. I hope 1.43 but even that is already coming soon.
Tasks dispatched. Fingers crossed.
Generic Geometry Library accepted to Boost
Saturday, November 28th, 2009 Today, Hartmut Kaiser, manager of the review of the Generic Geometry Library, announced the official results of the review.
Here we go:
Formally this review ended with 12 YES and 2 NO votes. This result reflects the overall discussion and the general consensus of this library being worth to be included into Boost.
It means that formally the Generic Geometry Library has been approved to become a part of Boost C++ Libraries collection. Happy day!
Hartmut also writes:
It is worth highlighting that most of the reviewers emphasized the excellent quality of the library design.
I would like to send out my own kudos to Barend Gehrels and Bruno Lalande, the very core team, who started the project, designed and implemented the high-quality library and eventually released it as Open Source Software.
