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

Status of Comeau toolset for upcoming 1.41.0
by Mateusz Loskot 21 Nov '09

21 Nov '09

Hi, Recently, I've reported [1] issues [2] related to building with Comeau toolset. The upcoming release info [3] does not mention Comeau toolset. May I ask what's the status of support of Comeau? Is it safe to assume Boost 1.41.0 will be usable with Comeau C/C++ ? [1] http://lists.boost.org/Archives/boost/2009/10/157410.php [2] https://svn.boost.org/trac/boost/ticket/3548 https://svn.boost.org/trac/boost/ticket/3558 [3] http://beta.boost.org/users/news/version_1_41_0 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

4 5

Re: [boost] [Boost-users] [Review] GGL review starts today, November 5th
by Barend Gehrels 21 Nov '09

21 Nov '09

> If I had a library that only implemented quad-trees and then proposed > it as Boost.Generic Spatial Index, I would think the reviewers would > have something to say about that. > Please note that GGL is a "geometry library" implemented using "generic programming". Though we aim to a broad scope, we don't aim to "generic geometry" Barend p.s. (please make the To: of this thread: boost, and not boost-users)

2 2

Updating the Boost Review Process Was: [Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale
by Jose 21 Nov '09

21 Nov '09

I propose these 3 changes (starting with the word ADD: below) to the current review policy in http://www.boost.org/community/reviews.html I realize that there is no mention to the word "vote" in the review policy, just "review comments". See message below for rationale on why these may be good changes. ----------------------------------- INTRODUCTION ... The final "accept" or "reject" decision is made by the Review Manager, based on the review comments received from boost mailing list members. ADD: Consensus should be objectively measured with the votes and otherwise the right to accept solely by the review manager could be revoked. ... RESULTS At the conclusion of the comment period, the Review Manager will post a message to the mailing list saying if the library has been accepted or rejected. A rationale is also helpful, but its extent is up to the Review Manager. If there are suggestions, or conditions that must be met before final inclusion, they should be stated. ADD: In conflicting reviews or with little consensus the Review Manager should justify way the library was accepted or not accepted. NOTES FOR REVIEW MANAGERS ... ADD: The review manager must not have or have had business ties with the library author/organization. ... ---------- Forwarded message ---------- From: Jose <jmalv04(a)gmail.com> Date: Mon, Nov 16, 2009 at 12:09 PM Subject: Re: [boost] [Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale To: boost(a)lists.boost.org Hi, I am not expert in geometry but what matters is that boost continues to provide generic libraries (if possible !) like BGL, GIL, .. I think there is no blame on library authors which make a huge effort. What was broken is the review process, and some of the reasons why the review process was broken were: 1) The result of the review was 6 positive to 4 negative, when boost normally aims for consensus. This is the most objective point. Also, the issues the review manager was proposing to be fixed would not change the votes as the library was not appropiate even for 2D geo applications 2) The scope of GTL was changed before the review (see snippet 2 at the end) but the review docs still mention a wider app focus (see snippet 1 at the end). This confusion appeared when GTL was being reviewed. 3) The review manager didn't have time for the review (if you look at the apology at the beginning of the review email summary) 4) The GGL library proposal, which had been iterating the design with input from boost, in my opinion received an unfair treatment in the way the schedule was managed. 5) Boost failed to set the scope for a geometry library/ies and created tension with candidate library authors There are more points but I don't like long emails. I propose to change the current review process: http://www.boost.org/community/reviews.html ----------------- NOTES FOR REVIEW MANAGERS Decides if there is consensus to accept the library, and if there are any conditions attached. ----------------- AMENDMENT 1 that consensus should be objectively measured (with the votes) and otherwise the right to accept solely by the review manager could be revoked. Clearly there was no consensus in this library, and no clear discussion if one single library was possible (I understand your points that multiple libraries in this case may be preferable but still that is not incompatible with a complete design discussion) AMENDMENT 2 The review manager should have or have had no business ties with the library author/organization. Amendment 2 is not related to this review, but this would support the current transparency. I feel that in some cases there might be a vague prejudice in favor of big/important/known organizations to get their libraries accepted regards jose --------------------------------------------- Snippet from Boost.Polygon docs http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm "These so-called Boolean algorithms are of significant interest in GIS (Geospatial Information Systems), VLSI CAD as well al other fields of CAD, and many more application areas, and providing them is the primary focus of this library." 7/19/09 I am changing the name of my library from GTL (Geometry Template Library) to boost::polygon and narrowing the scope from "computational geometry" to "polygon manipulation". This scope precisely describes the current scope of what is implemented. It also clarifies the position of the library relative to similar proposals. ------------------------------------------------

17 64

Fixing warnings - progress
by Paul A. Bristow 21 Nov '09

21 Nov '09

I've updated https://svn.boost.org/trac/boost/wiki/WarningFixes on progress we are making (a little effort would go a long way to fixing the remaining warnings) to show what has been fixed, and where we need more information, and more work. Please post information to be added, or edit the page yourself - it is a wiki after all ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 2

Re: [boost] [Boost-users] [Review] GGL review starts today, November 5th
by Barend Gehrels 21 Nov '09

21 Nov '09

Hi Michael, Thanks for your review! I don't understand some of the problems you have had, so I'll explain or ask some things. > Some general thoughts: > > Integration with Boost.Units should be encouraged. I don't think > is_angle, etc should be in GGL. If I have a vector of quantities, > things should Just Work. > I think you mean is_radian, which is used internally to know if spherical coordinates are in degree's or in radian's. We didn't thought it a good idea, just for this one piece, to integrate with another boost library. Though for some coordinate systems it certainly would make sense (see also answer to Brandon's review) > As it is, Barend favors GIS, > Bruno favors gaming, and the resulting library is a mashup of GIS > terms and other arbitrary terminology and it excels in no one > particular area. > Thanks for your namespace suggestion in another thread. This will help to improve this. > > Yes. I spent a few hours trying to get it to with ESRI, a leader in > the GIS domain. Their API is completely COM based however, and it > proved extremely difficult to get working with GGL. I wasn't able to > successfully do this with Boost.Polygon either. > Yes, it would be very cool if this would work nicely, and it is meant to work. It is not clear to me if you get anything working, or nothing. However, I'll come back to you because it would be very useful if there is an example, showing integration between GGL and ESRI. > The Examples link at the bottom of the main page of documentation is > broken (last line), This was not a hyperlink (could be though, sorry) > and custom_point_example.cpp doesn't compile - > cs::cartesian needs to be ggl::cs::cartesian. > This surprises me. It is declared within a macro, so ggl namespace is not necessary there. I've not heard of this problem before, and it seems to compile fine normally for everyone (so I must now say: for most people). Are you sure? > It was not clear what includes I had to include to register my custom > point type. GEOMETRY_REGISTER_POINT_2D is defined in > ggl/geometries/register/point.hpp, but the following won't compile: > Normally, including <ggl/ggl.hpp> is enough, but indeed this should also compile, will be add the dependency. > It also doesn't appear that the custom point type can be in its own > namespace when using these registration macros. For instance, the > following doesn't compile: > > namespace foo { > struct test { > double x, y; > }; > } > GEOMETRY_REGISTER_POINT_2D(foo::test, double, ggl::cs::cartesian, x, y) > [...] I had to have "using namespace math" just to register my point correctly. > Yes, that was a known issue and should have been documented. We didn't search for the solution yet, it must be simple. > Using the haversine strategy caused compilation errors > because there was no overload of get_as_radian<>() for my point type. > > 1. It's not documented that the haversine strategy requires > get_as_radian, or at least I didn't see it. > Spherical coordinate systems use get_as_radian internaly (using is_radian), but it should never be necessary to overload it yourself. The normal procedure is registering your point as cs::spherical<degree> coordinate system. That would have been fine, and that was expected for the haversine function. You probably used cs::cartesian, and it didn't know if it was degree or radian. Anyway, I see your problem though, we will correct this and/or document this better. > I finally got haversine working with my point type by defining > get_as_radius as above, and the result was correct. I must say, it is a great workaround, nice that you got it working also like that. > This almost went smoothly, except that I had to specialize > strategy_tag, but didn't see any mention of this requirement in the > docs. Once I did that, my distance strategy worked and returned the > same value as haversine for values along the equator. > To be complete, the vincenty is also part of the gis extension, it was first not included, but later we wanted to show that 07 graph example, showing nicely the integration between BGL and GGL (there were not too many comments on this though). I understand that you implemented your own strategy, very cool. And indeed, you should specialize your strategy_tag, if (and only if) you want to use that one by default. Another way would have been that you specified the strategy as additional parameter. Great you got it all working like this! Of course, everything should work, but you did use some quite advanced features of GGL, and I like to see that you did succeed there. We will work on the documentation so these scenario's will cause less problems. Thanks again, Barend

1 0

Help needed in fixing warnings
by John Maddock 21 Nov '09

21 Nov '09

Dear all, I've started a wiki page here: https://svn.boost.org/trac/boost/wiki/WarningFixes for folks to collaborate on fixing warnings from Boost libraries. As noted the initial effort should be directed towards core libraries - those that get included and reused by other libraries. You can help by: * Running the tests for your favorite libraries (those not already listed, or with "unknown" status), and updating their "Status" field to reflect whether any work is needed. * Filing bug reports if it's not obvious how to silence the warnings. * Filing patches if the fixes are obvious. * Fixing the code if you're a library author! There's something for everyone there, whether you're a Boost newbie, or a hardened veteran, so I hope that many hands can make light work of this! Cheers, John.

9 23

[1.41.0] iostreams/device/mapped_file.hpp has no include guards
by troy d. straszheim 21 Nov '09

21 Nov '09

making a trac ticket... -t

2 2

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

21 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.

2 1

Shouldn't both logging proposals be reviewed in the same formal review?
by Andreas Huber 20 Nov '09

20 Nov '09

According to the schedule, John Torjo's Log2 library will be reviewed soon (currently 3rd in the queue). There's another logging proposal by Andrey Semashev (currently 13th in the queue). It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost. Therefore, wouldn't it make sense to review both libraries in one (longer) formal review? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

19 42

[Variant] [BGL] Variant<edge_descriptor, edge_descriptor> is not EqualityComparable
by Cosimo Calabrese 20 Nov '09

20 Nov '09

Hi to all, this discussion is linked to "Boost.Variant is not EqualityComparable". I've opened a new one because to involve the BGL argument. The problem is simply this. I've created a union graph adaptor, that provides a "union view" of two graphs; in that adaptor, the edge_descriptor is defined like this: typedef boost::variant< WR1<typename graph_traits<Graph1>::edge_descriptor>, WR2<typename graph_traits<Graph2>::edge_descriptor> > edge_descriptor; Now I would to use that graph to the Dijkstra's algorithm, that requires that the edge_descriptor models the EqualityComparable concept. But as we know, boost::variant doesn't support the inequality expression ( v1 != v2 ). I've tried to add it from my code (I would avoid to modify the boost lib), but it doesn't works. I'm using MSVS 2005 on WinXP, boost 1.38. I've tried to add the following line, as suggested by Stefan Strasser (thanks Stefan): using namespace std::rel_ops; to add the generic operator!=(), but the compiler doesn't find it, the compiler error is the same. Now I try to provide to you more details. If it isn't enough, I can provide the entire code. I've defined the graph adaptor like this: ////// union_graph.hpp ////// #include <boost/graph/graph_traits.hpp> #include <boost/graph/properties.hpp> #include <boost/graph/adjacency_iterator.hpp> #include <boost/graph/graph_utility.hpp> #include <boost/graph/exception.hpp> #include <boost/variant.hpp> namespace boost { template <typename T> class WR1 { /* ... */ }; template <typename T> class WR2 { /* ... */ }; template <typename Graph1, typename Graph2> class union_graph { public: typedef Graph1 graph_type1; typedef Graph2 graph_type2; // Constructor union_graph( Graph1& g1, Graph2& g2 ) : m_g1(g1), m_g2(g2) { /* ... */ } // Graph requirements typedef boost::variant< WR1<typename graph_traits<Graph1>::vertex_descriptor>, WR2<typename graph_traits<Graph2>::vertex_descriptor> > vertex_descriptor; /* ... */ // IncidenceGraph requirements typedef boost::variant< WR1<typename graph_traits<Graph1>::edge_descriptor>, WR2<typename boost::graph_traits<Graph2>::edge_descriptor> > edge_descriptor; /* ... */ }; // EqualityComparable concept, requested by IncidenceGraph concept template <typename Graph1, typename Graph2> inline bool operator!=( const typename boost::graph_traits< boost::union_graph<Graph1, Graph2> >::edge_descriptor& left, const typename boost::graph_traits< boost::union_graph<Graph1, Graph2> >::edge_descriptor& right ) { return !( left == right ); } and I've used it like this: ////// main.cpp ////// #include "union_graph.hpp" int main() { typedef adjacency_list<...> Graph1; typedef adjacency_list<...> Graph2; typedef union_graph<Graph1, Graph2> UG; Graph1 g1( 10 ); Graph1 g2( 10 ); UG ug( g1, g2 ); graph_traits<UG>::edge_descriptor e1; graph_traits<UG>::edge_descriptor e2; tie( e1, existence ) = edge( v1, v2, g ); tie( e2, existence ) = edge( v1, v2, g ); e1 != e2; } The first part of the template compiler error is: 1>D:\dev\CommesseAperte\Sviluppo\TELLUS36_Librerie\boost_1_38_0\boost/concept_check.hpp(233) : error C2678: binary '!=' : no operator found which takes a left-hand operand of type 'boost::variant<T0_,T1>' (or there is no acceptable conversion) 1> with 1> [ 1> T0_=boost::WR1<boost::detail::edge_desc_impl<boost::directed_tag,__w64 unsigned int>>, 1> T1=boost::WR2<boost::detail::edge_desc_impl<boost::directed_tag,__w64 unsigned int>> 1> ] Can someone help me? I wouldn't hack the lib, because I will do it to every new version of Boost... Thanks in advance, Cosimo Calabrese.

5 17