- Boost - lists.boost.org

[1.46.0] [units] test_output failing all release regression compilers
by Beman Dawes 18 Jan '11

18 Jan '11

http://beta.boost.org/development/tests/release/developer/summary.html is looking pretty good for most libraries, but units test_output is failing all release regression compilers. Can we get a fix for this before the beta next week? Thanks, --Beman

4 9

Showstoppers?
by Marshall Clow 18 Jan '11

18 Jan '11

Looking in the Trac, I see 43 bugs marked as "Showstoppers". Are any/all of them worth holding up the release of 1.46 for? [ If not, I suggest that they should not be marked as 'showstopper' ] https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re… -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

2 1

1.46 closed for major changes
by Vladimir Prus 18 Jan '11

18 Jan '11

Boosters, per our calendar, 1.46 is now closed for major changes. What constitutes a major change is up to your judgement, but please excercise care with commits. 1.46 will be closed for all changes next Monday. Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

2 1

Re: [boost] [Boost-commit] svn:boost r68201
by Bryce Lelbach 18 Jan '11

18 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 16 Jan 2011 23:52:02 -0500 (EST) steven(a)providere-consulting.com wrote: > Author: steven_watanabe > Date: 2011-01-16 23:51:54 EST (Sun, 16 Jan 2011) > New Revision: 68201 > URL: http://svn.boost.org/trac/boost/changeset/68201 > > Log: > Revert addition of BOOST_NIX, etc and everything tied to it. ([66696], > [66783], [66804], [66833], and [66834]) Removed: fenv.h is not a part of the C++ standard library; it is specified in ISO/IEC 9899, section 7.6 (the C99 standard). It's implementation is tied not only to the underlying C library in use, but also to a number of other factors, including but not limited to: - The operating system - The kernel - The compiler's method of implementing header search Attempting to detect the presence of the fenv.h header and the toolchains support for using said header cannot be achieved naively by defining a macro if the GNU, vacpp, sgi or stlport standard library implementation is found. The changes you have introduced will break Boost support for (at least) the following compilers and toolchains: - Sun, HP, Pathscale - Clang on linux or darwin using libc++ - Any compiler using the Apache/Roguewave standard library I am sincerely sorry to have stepped on toes here at Boost, especially yours, as you seem to be hellbent in purging Boost of my contributions, instead of helping to improve upon them. You told me last night in an email that you went back and reviewed every commit that I have ever made to Boost. I would appreciate it if you would let me know how much of my work you have in your crosshairs. Anyone here who knows me is aware that I am young and inexperienced at working on a large-scale open source project. I have been a little over-enthusastic and unintentionally inconsiderate, but I have done my best to fit in here and make contributions to Boost. I do not think that reverting my commits without consulting me first encourages the SVN policies that you and others assert that I have blatantly violated. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0z11gACgkQ9cB/V3/s9EyXJQCfesVXrNkhAeNoYCmgWODv0Z7m 6fMAni0Sb7gdtQWHyIj7EVFhrwqvBjCv =Sr5U -----END PGP SIGNATURE-----

5 7

Review Manager Assistant Role (reloaded)
by Joachim Faulhaber 18 Jan '11

18 Jan '11

Dear list, There have been discussions around the review process currently with some positive results and initiatives. There is a general dissatisfaction with the slow speed of processing libraries in the queue, the difficulties to find review managers and the accumulation of "stale" libraries of unclear status. Thanks to the activities of Volodya, Vicente and others this seems to improve currently. I appreciate this very much. Still I think, we should consider changing some of the rules of the review process to make it more efficient in the long run. A few points that are important to me: (1) Public statements on the Boost web page should be true. (Currently at least one is not.) (2) Only libraries that conform *all* requirements for boost libraries should be included into the review schedule. (3) The time a library stays in the review schedule should be as short as possible and it'll be limited to a maximum. (4) The throughput of libraries on the list shall be driven by the contributors activities. (5) The processing of a library contribution can be stopped by rejection (no-votes) and vetoes, but *not by inaction*. The principles that I regard to be most relevant are: (p1) Contribution must not be discouraged by mere inaction. (p2) Harness the motivation where it is: Development and library contribution. Don't expect it to be where it is not: Administration duties of seasoned boosters. I think that we can achieve point (1) to (5), if we shift more of the time consuming work of the Review Manager to the contributers by creating the Review Manager Assistant Role as proposed at BoosCon http://lists.boost.org/Archives/boost/2010/05/166423.php And every *first contributor* has to take on a Review Manager Assistant job once. Since there was reasonable support for those ideas, specifically by Dave Abrahams and Robert Stewart, I would like to come back on them, to see if there is still interest. Specifically I'd like to hear what the Review Wizards think. Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

[Serialization] can BOOST_ASSERT have method calls?
by Patrick Horgan 18 Jan '11

18 Jan '11

I noticed in serializations basic_iarchive that when you're not building for debug the next line here (317 in basic_iarchive.cpp) has a warning for unused variable new_cid. The BOOST_ASSERT is instantiated as ((void)0) so new_cid really isn't used. Could the register_type call be moved into the assert? class_id_type new_cid = register_type(bpis_ptr->get_basic_serializer()); int i = cid; cobject_id_vector[i].bpis_ptr = bpis_ptr; BOOST_ASSERT(new_cid == cid); Something like: BOOST_ASSERT(register_type(bpis_ptr->get_basic_serializer()) == cid); Then the new_cid variable wouldn't be needed and the call to register_type would disappear with the BOOST_ASSERT if you aren't building for debug. Or, does the call to register_type have an important side effect that is required? Patrick

3 3

[signals] failure to build with recent gcc
by Patrick Horgan 18 Jan '11

18 Jan '11

I get a number of the same failures when doing a clean build of boost trunk with a recent gcc (4.6.0). libs/signals/src/named_slot_map.cpp:105:23: instantiated from here /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_map.h:626:9: error: call of overloaded ‘erase(std::map<boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair>, boost::function2<bool, boost::signals::detail::stored_group, boost::signals::detail::stored_group> >::iterator&)’ is ambiguous /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_map.h:626:9: note: candidates are: /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:763:7: note: void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::erase(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::const_iterator) [with _Key = boost::signals::detail::stored_group, _Val = std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> >, _KeyOfValue = std::_Select1st<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, _Compare = boost::function2<bool, boost::signals::detail::stored_group, boost::signals::detail::stored_group>, _Alloc = std::allocator<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::const_iterator = std::_Rb_tree_const_iterator<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >] /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:1490:5: note: std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::size_type std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::erase(const _Key&) [with _Key = boost::signals::detail::stored_group, _Val = std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> >, _KeyOfValue = std::_Select1st<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, _Compare = boost::function2<bool, boost::signals::detail::stored_group, boost::signals::detail::stored_group>, _Alloc = std::allocator<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::size_type = unsigned int] Patrick

2 1

[Boost Graph Library] Having trouble constructing necessary parameters for the isomorphism algorithm
by Alexander Bock 18 Jan '11

18 Jan '11

Hi all, First of all, I new to the mailing list, so please excuse me for any beginner's mistakes I may make :) I am also new to the Boost Graph Library. I am having some trouble implementing the Boost Graph Library isomorphism algorithm under MSVC++ 2008 Express Edition. Since I am using MSVC++, I cannot use the named parameter method, as specified in the docs. I am not entirely sure, but I think my problem is the vertex invariants that I pass to the algorithm. I am using Boost 1.43. My graph and relevant typedefs look like this: typedef adjacency_list<listS, listS, undirectedS, VertexProperty, EdgeProperty, no_property, listS> UndirectedGraph; typedef graph_traits<UndirectedGraph>::vertex_descriptor VertexDescriptor; I am using bundled properties: struct VertexProperty { string id; int index; }; struct EdgeProperty { string id; int weight; }; Here's my code that tries to call the isomorphism algorithm: bool BoostGraph::Compare(BoostGraph& comparableGraph) { vector<VertexDescriptor> f(GetNoVertices()); property_map<UndirectedGraph, int VertexProperty::*>::type indexMap1 = get(&VertexProperty::index, uGraph); property_map<UndirectedGraph, int VertexProperty::*>::type indexMap2 = get(&VertexProperty::index, comparableGraph.GetGraph()); return isomorphism(uGraph, comparableGraph.GetGraph(), isomorphism_map(make_iterator_property_map(f.begin(), indexMap1, f[0])), ???, ???, vertex_invariant2.max(), indexMap1, indexMap2); } The two '???' are where I need to pass the vertex degree invariants, but I do not know how to construct them. I hope I have supplied sufficient information for you. Thanks in advance!

2 13

Review manager volunteer
by Edward Diener 18 Jan '11

18 Jan '11

I am willing to be a review manager to help expedite the review of libraries in the review schedule which do not have a review manager assigned to it. Looking at the review process web page it says that the review wizards, whom the page says are currently John Phillips and Ronald Garcia, maintain a list of review manager volunteers. I do not know if that means I should be e-mailing directly the review wizards, so I decided to post this here first instead. I have been a programmer for 33 years, am very good with C++, and have a pretty good understanding of the basic Boost libraries ( MPL, Type Traits, PP, Function Types etc. ) with which other programmers may be working in order to produce a library for Boost. I have also put two libraries in the sandbox and am working on a third which I will eventually upload, so I have gained some experience in producing a potential library for Boost. Whether that qualifies me for being a review manager others can decide. My heart will not be broken if it does not, but if I am accepted as a potential review manager I know I can do a good job. Looking at the documentation of the libraries currently in the queue which do not have a review manager as yet, I believe I am familiar enough with the ideas of some of the libraries to be a review manager for any of these: bitfield conversion join endian string_convert pimpl My own point of view, unlike what others have generally expressed, is that the review wizards should assign reviews to potential review managers, after e-mailing them to see if they would be available for a particular library, rather than the library implementer directly asking someone to review their library. I feel that way because I think there may be too much influence on the review manager to accept a reviewed library when the library implementer and the review manager are joined by the direct asking process. But perhaps I am wrong, especially as many libraries have no review manager and the review wizards do not seem to be assigning review managers to those libraries from some volunteer list which they have. I believe it is important to break the logjam which is the current review schedule without keeping library implementers waiting for a longer and longer period of time to get their libraries reviewed, much less added to a Boost distribution in the future if it is accepted. The lack of review managers seems to be one of the major reason for this jamup and I would like to alleviate it in my own way, especially as I would like to eventually get my own libraries reviewed in the near future when I request it.

3 3

[ratio] Moved to trunk
by vicente.botet 17 Jan '11

17 Jan '11

Hi, I have moved Boost.Ratio to trunk and I have managed with all the requested points. From: "Anthony Williams" > These changes should be addressed before the library appears in a > Boost release. > > * Some of the macros had names with RATIO_RATIO in. These should be > changed to just RATIO DONE > * The ratio_add, ratio_sub, ratio_multiply and ratio_divide templates > should derive from the resulting ratio type as well as providing the > nested ::type member, in order to closely emulate the template alias > facility from C++0x DONE. While dreiving solve most of the issues ::type is needed yet to match a template parameter. > * The typos in the documentation should be fixed, and the documentation > reviewed for correctness and clarity (though several of the reviewers > made positive comments on the quality of the documentation). DONE even if there are always some improvements. > * The library needs more tests under the Boost Software License. DONE, thanks to Howard and the LLVM community for changing its license and making it compatible with Boost. > * All references to names from the boost namespace should be qualified > with boost:: to avoid potential name clashes and ambiguity with names > from the global namespace. DONE > * Sections commented out with #if 0 should be removed DONE > * The extensions beyond the facilities required by the C++0x draft > should be able to be enabled or disabled through use of a > configuration macro. DONE, BOOST_RATIO_EXTENSIONS needs to be defined. > * References to the tests, examples and documentation from within the > code should be checked for correctness. > DONE I have tried to solve some of the usual portability issues and even if there are yet some issues on the regression report, I consider that the library is globaly ready. I have added some extensions that Joel requested during the review. The extensions are related to viewing ratio<> as a Rational Constant. Rational constants can be mixed with other MPL Integral Constants when using the MPL numeric metafunctions. Paul A. Bristow has reviewed the documentation and fixed most of the editorial isues. The pdf documentation is available here https://svn.boost.org/svn/boost/trunk/libs/ratio/doc/ratio.pdf. If the html file is needed I can commit it temporarilly. It would appreciate if others can take a look and check if everything is right before moving to release. Thanks, Vicente

1 0