October 2008 - Boost - lists.boost.org

[test] linking does not return
by k-oli＠gmx.de 27 Oct '08

27 Oct '08

Hello, I've some test files but the link-step does not return (waits forever). gcc.link ../../../bin.v2/libs/tp/test/test_bounded_queue_fifo.test/gcc-4.3.1/debug/link-static/threading-multi/test_bounded_queue_fifo The Jam file: import testing ; project : requirements <library>../../test/build//boost_unit_test_framework <library>../../thread/build//boost_thread <library>../../system/build//boost_system <link>static <threading>multi ; rule tp-test ( source ) { return [ run $(source).cpp ] ; } test-suite thread_pool : [ tp-test test_bounded_queue_fifo ] [ tp-test test_bounded_queue_lifo ] [ tp-test test_bounded_queue_priority ] [ tp-test test_bounded_queue_smart ] [ tp-test test_unbounded_queue_fifo ] [ tp-test test_unbounded_queue_lifo ] [ tp-test test_unbounded_queue_priority ] [ tp-test test_unbounded_queue_smart ] ; Platform LINUX (Debian/Lenny). regards, Oliver

3 3

Preview 3 of the Geometry Library
by Barend Gehrels 27 Oct '08

27 Oct '08

Dear list, Herewith the URL to the third preview of our Geometry Library, including documentation and examples. The first two previews were sent to this list in January and in March. Since then, Bruno Lalande, already a Boost contributor, joined and we together reworked the library and its concepts. Lines (sequences of points) are now generic, handled using iterator pairs. Concepts have been worked out and integrated everywhere in the code. A Google Summer of Code project, handling Spatial Indexing, is based on the geometries of this library. Many discussions and comments were related to the concepts and, more specific, to the Point concept. This is the most basic thing of a geometry library and has to be as generic as possible. We think we implemented it like that into the library. The library can handle all point types including legacy point types, point types provided by the library, user defined point types, Cartesian points, native arrays, points with spherical coordinates. The library provides point_xy for Cartesian systems and point_ll for lat long systems, but the library user is thus not confined to those types. Using a strategy mechanism, the library should be able to handle every point type, and lines made of those types. The distance / simplify algorithms clearly show this design. The library is not completed, it is still a preview. It is used in real life projects but will still be enhanced and extended. The point type is now generic and lines (sequences of points) are generic. However, boxes, circles and polygons still have to be reviewed and their concepts can be worked out further. Some algorithms will be reprocessed to use strategies and handle any point type. The URL with documentation is here: http://geometrylibrary.geodan.nl. The library is Open Source and uses the Boost License. However, being a preview and not yet a real submission, the SVN is not at boost but still hosted at Geodan. If you are interested you can get SVN access. There were since March two other geometry library references sent to the list. This really shows the need for a Geometry Library into the boost collection. We welcome any discussion, comment or contribution and we are open for any type of cooperation, merge or join. Barend Gehrels

13 49

[zip_iterator] Understanding why.
by Robert Jones 27 Oct '08

27 Oct '08

Zip iterator implements the functionality I need to advance associated iterators through different ranges, but it seems strangly awkward to use, which is odd for Boost. so I'm wondering if I've misunderstood the design paradigms. Given two ranges (say vectors), I'd like to be able to generate an iterable composite, anditerate through that, something like vector<int> v1; vector<int> v2; typedef zip_composite<int, int> Z; Z zip( v1, v2 ); for ( Z::iterator i=zip.begin( ); i !=zip.end( ); ++i ) { // ... blah, blah, blah } Is this impossible or undesirable to implement for reasons I've not realized? Thanks, Rob.

4 3

[1.37.0] Release branch post-beta merges
by Beman Dawes 27 Oct '08

27 Oct '08

The release branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See http://svn.boost.org/trac/boost/wiki/ReleasePractices/PostBetaMerges The final release is currently planned for Sunday, November 2nd. It would be helpful if all merges were complete a couple of days before that to allow plenty of time for tests to cycle and other pre-release preparation. Thanks, --The release managers

1 0

[release management] Draft policy for changes between beta and release
by Beman Dawes 27 Oct '08

27 Oct '08

In another post, John Maddock asked what sort of QA problems should be fixed between the beta and final releases, and what the criteria and procedures are. Here is a quick draft of a possible policy: * Showstoppers. Criteria: Bugs or other problems so serious that the release is seriously compromised if not fixed. Procedure: After discussion on the developers list, release managers will specify how the problem is to be attacked, and what effect it will have on schedule. * Documentation and other minor fixes not affecting code. Criteria: Changes not requiring regression testing and unlikely to impact other libraries. Procedure: Merges to branches/release are OK, after fix applied to trunk, and do not require a release manager's permission. * Minor code fixes. Criteria: Changes believed to have limited risk and that have already been made to trunk and are stable on trunk regression testing. Procedure: Merges to branches/release after fix stable on trunk tests do not require a release manager's permission. * Questionable code fixes. Criteria: Any code changes not meeting the "Minor code fix" criteria, such as a change with a lot of possible ripple effect on other libraries. Procedure: Ask release managers for permission. * Tools changes and fixes. Code changes to bjam, Boost.Build, Boost.Test, the doc build process, and other tools are discouraged late in release cycles in general and between beta and release in particular. Ask release managers for permission if you really think the change is warranted for this release. * New features, breaking changes, major reworks, new libraries. These are not suitable for merging between beta and release. Wait until the next release. Comments? --Beman

5 8

[1.37] status/Jamfile.v2
by Nicola Musatti 27 Oct '08

27 Oct '08

Hallo, I believe the Jamfile.v2 in the status directory should be merged to the release branch. The one that's there looks older than the directory reorganization that was performed a while ago, and it doesn't include the tests for several libraries. Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/

9 17

[mpl] Error in map docs (or bug)
by John Bytheway 27 Oct '08

27 Oct '08

I think I've found an error in the MPL docs (In trunk and 1.35, and presumably everything in between). The documentation for mpl::map state that "count<m,k>::type" yields "The number of elements with the key k in m", where in fact what it returns is the number of elements *equal* to k in m. This is consistent with the documentation of mpl::count. I suspect this is an error in the docs rather than a bug, since there is also mpl::has_key, which serves the purpose count claims to be serving (but isn't). Consider this code: #include <boost/mpl/has_key.hpp> #include <boost/mpl/count.hpp> #include <boost/mpl/assert.hpp> #include <boost/mpl/set.hpp> #include <boost/mpl/map.hpp> #include <boost/mpl/insert.hpp> using namespace boost::mpl; typedef set< int >::type my_set; typedef map< boost::mpl::pair<int, int> >::type my_map; BOOST_MPL_ASSERT((has_key<my_set, int >::type)); BOOST_MPL_ASSERT((count<my_set, int >::type)); BOOST_MPL_ASSERT((has_key<my_map, int >::type)); BOOST_MPL_ASSERT((count<my_map, int >::type)); BOOST_MPL_ASSERT((count<my_map, pair<int,int> >::type)); The fourth assertion fails. If the map docs were accurate then it would be the fifth assertion that failed. The same error is in the Associative Sequence docs, and perhaps other places. John Bytheway

1 0

Directory monitor for Windows (Boost.Asio extension)
by Boris 26 Oct '08

26 Oct '08

I had created a file monitor in March as a reference implementation of how to develop a Boost.Asio extension. While it was pretty incomplete at that time it has become a grown-up and fully tested directory monitor which supports both synchronous and asynchronous I/O. It currently works on Windows only as it is based on Microsoft's I/O Completion Ports (for those who need a directory monitor on Linux see http://article.gmane.org/gmane.comp.lib.boost.asio.user/2699) The directory monitor can be downloaded here: http://www.highscore.de/boost/dir_monitor.zip The zip archive contains various tests which can be used for a quick start. As the directory monitor is pretty small it shouldn't take much longer than 10 minutes to use it in your own projects. Boris

1 0

[test] Patch for gcc warning suppression.
by John Maddock 25 Oct '08

25 Oct '08

I'm getting a bunch of warnings from floating_point_comparison.hpp with gcc, the attached patch fixes these, if these are OK, I can commit from here. That just leaves: c:\data\boost\boost\trunk/boost/test/floating_point_comparison.hpp:246: warning: 'boost::test_tools::<unnamed>::check_is_small' defined but not used Is there any way to get rid of that as well? Thanks, John.

3 3

Welcome to the Boost Developers Archive on Google Groups!
by Eric Niebler 25 Oct '08

25 Oct '08

I've subscribed Google Groups to the boost developers list, so that people who would like to follow the group that way (and get an RSS feed to the list) can do so. http://groups.google.com/group/boost-developers-archive It can't import old messages, but new messages should show up there and be search-able. I hope. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2