- Boost - lists.boost.org

Boost.Pool - Are you using this library, please can we have your input?
by Paul A. Bristow 18 Jan '11

18 Jan '11

Boost.Pool is the subject of a 'make-over' by Boost.Guild. (This is some of a test-bed for a process of revision of older, perhaps orphaned, libraries using the relative safety of the sandbox). In order to permit any modification, the original (hand-written?) html documentation has been converted to Quickbook (and somewhat revised) at http://svn.boost.org/svn/boost/sandbox/guild/pool/libs/pool/doc/ You can build the html docs using the jamfile.v2 in the normal way, but you will probably find it more convenient to go direct to the pdf version http://svn.boost.org/svn/boost/sandbox/guild/pool/libs/pool/doc/pool.pdf This is fairly fully hyperlinked, and includes a reference section using Doxygen. Doxygen comments have been added to the header files (from the original html docs). (If you are a Doxygen fan, there is also a Doxyfile for generating Doxygen-style docs in the /doc/Doxygen/ folder). We are now considering some better tests, and perhaps some enhancements to the code. We'd like input from users about: 1 Things missing or wrong from the docs. More up to date references? 2 Things missing (or don't work well) from Pool. 3 New things that you would like (this is not a promise!). 4 Examples of your use. Perhaps you built some during your development that could be used? 5 Better tests. Thanks. Paul PS Don't panic - the release version will not be changed without a mini-review. --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

3 2

[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