November 2009 - Boost-announce - lists.preview.boost.org

GGL Review Results
by Hartmut Kaiser 28 Nov '09

28 Nov '09

Hi all, The review of the Generic Geometry Library is over now. We have had vibrant discussions with regards to the library itself. In addition those stirred up a lot of controversial discussion about the Boosts review process. In this review results I will concentrate on the library at hands. 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. Based on this result and the discussions the Generic geometry Library has been formally accepted into Boost. It is worth highlighting that most of the reviewers emphasized the excellent quality of the library design. Here are some quotes: - "The design is very clear. I think it can serve as a standard example of how to cover a big non trivial problem domain using meta-programming, partial specialization and tag dispatch to make it uniformly accessible by a set of generic algorithms." - "The design looks clear enough so that I was able to understand about what was being done. Adding concept checking is a good idea. It also surely is a modern generic design." - "I am quite pleased with the use of tag-dispatching and strategies. I was happy to see this approach taken and by looking at the documentation and source code it seems sound. I believe this approach offers the greatest latitude for a generic library." At the same time the 2 NO votes reflect a couple of shortcomings which still need to be addressed before final inclusion into SVN. Here is a list of contingencies noted by the reviewers: - Robustness: algorithmic robustness and arithmetic stability have been discussed widely. The consensus of the reviewers is that all algorithms need to be robust and that the user should be able to make sure all calculations are arithmetically stable. GGL addresses arithmetic stability by allowing to instantiate all algorithms with arbitrary number types. But it turns out not the entire library has been converted to use this scheme yet. Any design issues that would prevent strong robustness guarantees (without drastic refactoring) in the future should be identified and fixed prior to release. The documentation needs to reflect the actual guarantees and complexities of every algorithm. - Concepts: more refinement needs to be done for the existing concepts. At least 2 users claimed to not have been able to adapt their data structures to the existing scheme. The library aims for defining the concepts and interfaces for future geometry related work in Boost, so these use cases need to be addressed. Users mentioned the missing concept inheritance. This might be a good way to address the current problems of concepts being too fine grained and too difficult to use. What needs to be done at minimum is to enhance the flexibility of the concept mechanism enabling to adapt user provided data structures more easily. The concepts need to be sound even in the light of extensions. - Boolean operations: while the library provides a set of Boolean operations those seem to be not complete and/or robust in terms of clockwise/counterclockwise geometries, closed/open polygons. Robust Boolean operations are a strong requirement, so this should be fixed as reported by at least one reviewer. - Documentation: the documentation of the library is not complete and needs additional effort. Using Doxygen alone as a documentation tool has its (known) shortcomings when it comes to generic libraries. The authors already mentioned to plan to switch to QuickBook after review allowing to have better control over the generated docs. - Testing: several reviewers mentioned the need for a thorough testing framework allowing the verification of the correctness of the algorithms in a wide range of use cases. Different test strategies need to be employed, such as high volume and random tests, known border case tests, tests using different numeric precision types, etc. Minor (non-contingency) issues: - Names of used concepts: currently the library is using mainly terms as established by the OpenGIS Consortium (OGC). This is misleading for users coming from different (non-GIS) domains. It has been suggested to introduce different namespaces for the different geometry domains (GIS, graphics, 3D, etc.) allowing to use the expected terminology established in that particular domain. - Name of the library: the name 'GGL - Generic Geometry Library' is misleading as it is not a generic geometry library but a library using generic programming techniques related to geometry. It has been suggested to use the name Boost.Geometry instead. This is not a requirement imposed by the review results, but I would like to suggest to the authors to consider renaming. - Integration with Boost.Units has been suggested. The library does not need to be completetly integrated with Boost.Units, although it appears to be reasonable to deal with types as exposed by Boost.Units especially for distance and area calculations. - Spatial data structures (such as spatial trees) have been mentioned to be crucial for a geometry related library. While the library can't implement all possible data structures in this field it can (and should) define concepts and interfaces allowing future extensions while maintaining interoperability. - In addition to that the reviewers made a lot of remarks related to different smaller inconsistencies part of which already have been addressed during the review. Barend has a full list of the remaining ones and promised to address all of them. Last but not least I would like to encourage cooperation between the authors of this library and the author of Boost.Polygon as both libraries have their strength' worth combining. In an ideal world and at some point I would like to see both libraries to be merged. But this is obviously not something to expect really soon. At this point I would like to thank all who participated in the review and, certainly, the authors for submitting this excellent library to Boost. Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

1 0

2nd Call for Participation - BoostCon 2010
by Hartmut Kaiser 24 Nov '09

24 Nov '09

Please distribute! -------------------------------- 4th Annual Boost Conference 2010 -------------------------------- Aspen CO, USA, May 4-10, 2010, www.boostcon.com 2nd Call for participation ---------------------- We invite you to submit session proposals to the 4th Annual Boost Conference: BoostCon 2010 (Aspen CO, USA, May 10-14, 2010). Traditionally the main face-to-face event for all things Boost (www.boost.org) BoostCon 2010 will present leading speakers from the whole C++ community. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and the new C++ Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at two constituencies: Boost end-users and hard-core Boost library and tool developers. The program fosters interaction and engagement within and across those two groups, with an emphasis on hands-on, participatory sessions. Session topics -------------- Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it will change life for users and library writers * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. Session formats --------------- Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops Workshops provide an active arena for advancements in Boost- relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. Submitting a proposal --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). Submission details ------------------ All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon10. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon website and will be available to attendees. For general information on the BoostCon 2010 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon10(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. Important dates --------------- Proposal submissions due: Dec 10th, 2009. Proposals decisions sent (tentative program available): Jan 15th, 2010. Fully scheduled program available: Feb 5th, 2010. Session materials due: Apr 15th, 2010. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

[Review] GGL Review ends today, November 22nd
by Hartmut Kaiser 22 Nov '09

22 Nov '09

Hi all, The review of the Generic Geometry Library officially ends today, November 22nd. Please send in your reviews if you have not done so yet. If you need more time for your review, please get in contact directly with me to work out some individual schedule. Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

1 0

[1.41.0] PDF Build of documentation available.
by John Maddock 20 Nov '09

20 Nov '09

A PDF build of the documentation for Boost-1.41 (for those libraries that support it) is now available from the usual sourceforge download site: https://sourceforge.net/projects/boost/files/ in the boost-docs/1.41.0 folder. Direct URL's are: https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_… (23Mb) https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_… (22.5Mb) https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_… (22.2Mb) https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_… (21Mb) Enjoy! John.

1 0

Boost release 1.41.0 available
by Beman Dawes 18 Nov '09

18 Nov '09

Boost release 1.41.0 is now available. This release contains one new library and numerous bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_41_0 The release can also be downloaded directly from SourceForge. See http://sourceforge.net/projects/boost/files/ To install this release on your system, see http://www.boost.org/doc/libs/1_41_0/more/getting_started/index.html Thanks, --The Boost release team

1 0

[Review] GGL review extended until November 22nd
by Hartmut Kaiser 15 Nov '09

15 Nov '09

Hi all, The discussions around GGL are just start ramping up and we received only 2 (voting) reviews so far. Additionally, several people have been asking me off-list to extend the review period as they otherwise wouldn't be able to write a review in time. For these reasons the review period for the GGL library will be extended for another week. The review period will now end November 22nd. For everybody considering to vote: this would be a good time to write a review! Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

1 0

[boost] [Review Results] Boost.Polygon library accepted into boost
by Fernando Cacciola 05 Nov '09

05 Nov '09

Dear Boosters, [first of all allow me to apology for not doing this before. My small consulting bussines suddenly grew out of proportion and now is way over my head, keeping me working/managing 16 hours a day] I am pleased to announce that the Boost.Polygon library from Lucanus Simonson has been accepted into boost provided some of the most critical concerns, detailed below, are addressed first. First of all I would like to thank Lucanus and Intel Corporation for making this work available to all C++ developers around the world. I would also like to thank all the reviewers that participated (in no particular order nor degree of participation) Thomas Klimpel Frank Mori Hess Barend Gehrels Andreas Fabri Jeffrey Hellrung Tim Keitt Markus Werle Paul A. Bristow Robert Stewart Mathias Gaunard Michael Fawcett Steven Watanabe Joachim Faulhaber John Bytheway Sebastian Redl Mika Heiskanen John Phillips Kai Benndorf Hartmut Kaiser Arash Partow Maurizio Vitale Brandon Kohn David Abrahams Gordon Woodhull Daniel James John Maddock Tom Brinkman Bo Persson Mateusz Loskot Christian Henning Jean-Sebastien Stoezel The library had 6 yes votes and 4 no votes. Those who voted no made the following major complains and remarks (they are numbered as I will refer to them back later): Barend Gehrels: (1) According to his benchmarks, intersection algorithms are unnecesarily slow as if something where fundamentally wrong in the design and/or implementation. AFAICT the implication has not been proved or disproved so far, hence I consider it a red herring and cannot take it as a reason for rejecting the library, but it is important to look at it in detail. (2) As a major complain, the library is unusable in those domains where floating point support is a requirement (like GIS). (3) The library should contain some basic polygon geometry algorithms such as convex hull and centriod Phil Endecott: (4) There is no concept checking in the code so it is difficult to adapt. (5) There where too many warnings and build errors (but Luke fixed these) (6a) The documentation needs a better overview of operations supported by the concetps. (6b) It also needs the details on the algorithms complexities. (6c) It also misses the numerical requirements for the coordinate type. (6d) And tutorials. (7) Some operators are ambiguous and it would be better to keep just one of each "flavor". (8) The polygon_data template class is parameterized by a coordiante type rather than a point type. This makes it useless for integration with existing geometric data types Michael Fawcett: (5), (6a), (6d) (9) T9he API should provide versions using output iterators in addition to output container references. (10) Theoreticall the library would be usable with a user defined coordinate type (metting certain requirements now undocumented), for example a fixed point data type, but some details in the internal design and implementation prevents this. (11) As a major complain, the library is unusable in those domains where floating point support is a requirement (like GIS). Hartmut Kaiser: (11), (1) Fernando Cacciola: (12) The name of the library should change to better indicate that is restricted to Integral coordinates and two-dimensions. (13) The documentation must contain a "credits" section acknowledging all the people that participated in the review. For the library to be effectively accepted, points (5),(6a-d),(10), (12) and (13) should properly addressed ((5) is already done AFAICT) It would be quite significant if point (1) where looked into. Once again I thank Lucanus, Intel Corporation and all the reviwers. Best regards -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[Review] GGL review starts today, November 5th
by Hartmut Kaiser 05 Nov '09

05 Nov '09

Hi all, The formal review of the Generic Geometry Library (GGL) starts today, November 5, 2009 and will finish November 15, 2009. GGL is being developed by Barend Gehrels, Bruno Lalande and Mateusz Loskot, with substantial input from this Boost mailing list. ------------------------------------------------ About the library: GGL defines concepts for geometries and implements some algorithms on such geometries. GGL is header-only, and can be applied in all software where geometry plays a small or a larger role. Users of the library can use just only one function, such as distance: int a[2] = {1,1}; int b[2] = {2,3}; double d = ggl::distance(a, b); Library users can also use the library in combination with std::vector, boost::tuple's and boost::ranges, such as: std::vector<boost::tuple<double, double, double> > line; line.push_back(boost::make_tuple(1, 2, 3)); line.push_back(boost::make_tuple(4, 5, 6)); line.push_back(boost::make_tuple(7, 8, 9)); double length = ggl::length(line); GGL can also be used in combination with custom or legacy geometries, adapting them to the library specializing traits classes or using registration macro's. Formally, GGL contains a dimension-agnostic, coordinate-system-agnostic and scalable kernel, based on concepts, meta-functions and tag-dispatching. On top of that kernel, algorithms are built: area, length, perimeter, centroid, convex hull, intersection (clipping), within (point in polygon), distance, envelope (bounding box), simplify, transform, convert, and more. The library is also designed to support high precision arithmetic numbers, such as GMP. The GGL might be used in all domains where geometry plays a role: mapping and GIS, gaming, computer graphics and widgets, robotics, astronomy... The core is designed to be as generic as possible and support those domains. However, for now the development has been mostly GIS-oriented. The GGL team proposes an extension model, very similar to what is used by GIL. The proposal as it is in the Boost Sandbox included three extensions: - SVG because it is used in the samples and to generate the documentation - WKT because it is used in the tests - The geographic coordinate system because it is used in some of the examples, also showing how other coordinate systems can be implemented There are more extensions, not included now, a.o.: - Spatial index - Map projections The proposed GGL has seen four previews, many discussions and many changes in design and implementation, based on those discussions. Previews were published on this list January '08, March'08, October'08 and February'09. GGL can be found in the sandbox https://svn.boost.org/svn/boost/sandbox/ggl/formal_review, including source code, examples, unit tests and documentation. Documentation can also be found online: http://geometrylibrary.geodan.nl/formal_review ------------------------------------------------------- Everybody on this list is invited to participate in this formal review. I hope to see your review of this library, including your vote, and I welcome your participation in the discussions on the Boost mailing list. Please always state in your review, whether you think the library should be accepted as a Boost library. Additionally, please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager ------------------- Meet me at BoostCon http://boostcon.com

1 0