- Boost - lists.boost.org

Re: [boost] [xint] Third release is ready, requesting preliminary review
by Jürgen Hunold 05 May '10

05 May '10

On Tuesday, 4. May 2010 17:32:58 you wrote: > On 05/04/2010 05:51 AM, Jürgen Hunold wrote: > > And it make things easiser if you only have on "red" entry in the summary > > page and can just see which test file to look at. > > And smaller test cases are just current Boost standard. > > That works, then. Thanks for satisfying my curiosity. You're welcome. > > And I think the patch > > > > +#ifdef BOOST_XINT_SINGLE_TEST_PROGRAM > > + #define BOOST_TEST_DYN_LINK > > +#else > > + #define BOOST_TEST_MAIN > > +#endif > > > > is wrong. BOOST_TEST_DYN_LINK should always be defined on the command > > line when linking against a shared Boost.Test library. So, no source > > code #define is necessary. > > But removing the BOOST_TEST_MAIN from all but one of the files, when > using a single test program, is. Yes, BOOST_TEST_MAIN is needed. #if !defined(BOOST_XINT_SINGLE_TEST_PROGRAM) #define BOOST_TEST_MAIN #endif is the "correct" solution > I'm fairly new to Boost.Test, but the documentation gave me the > impression that you had to make a decision on whether to use dynamic > linking or not when you wrote the code, because static and dynamic > linking need slightly different setups. That would suggest that you > can't easily switch between them, wouldn't it? Well, I use the same code for static ansd shared linking :-)) You are using AUTO_TEST_CASEs, so there is no problem. All the needed magic is hidden in BOOST_TEST_MAIN in combination with BOOST_TEST_DYN_LINK. Using "manual registration" can be tricky. > > And this issues > > " > > test_main.cpp:95:1: warning: "BOOST_TEST_DYN_LINK" redefined > > <command-line>: warning: this is the location of the previous definition" > > > > when compiling a shared library with all Boost.Build magic enabled. > > Eh? The library code doesn't use Boost.Test, only the testing code does. > And even the testing code only includes that #define when > BOOST_XINT_SINGLE_TEST_PROGRAM is defined, which it should never be > except on my development machine, or that of someone else doing > modifications to the library. That would be me ;-) I've added the single test program locally to get the errors messages. Adding "BOOST_TEST_DYN_LINK" in source code is potentially dangerous. It should really be a commandline-option. It should be possible to set in Code::Blocks. > > By the way: > > You have deleted test/Jamroot. Should there be a "test/Jamfile" instead ? > > Yes, there should. Did it not make it into Subversion? Checking... it > appears that it's there, so I'm not sure what to tell you. Maybe check > it out manually? No, it is definetely missing. > > build/Jamfile.v2 still contains "nothrow_random.cpp" which was deleted in > > 61752 as well. > > Sorry, I didn't remember to update that. I would have caught it before a > final release though, I have an entire checklist of things to do for that. Good. > > And I think you may also check in files for other build systems, too. > > Some libraries have Makefiles as well as visual studio solutions. > > I didn't think anyone would care about my Code::Blocks or Visual Studio > projects. If there's some interest in them, I'll add them in the next > repository update. Not really. I've never used Code::Blocks ;-)) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * juergen.hunold(a)gmx.de ! -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[xint] Boost.Move vs Copy-on-Write timings
by Chad Nelson 05 May '10

05 May '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've done some further testing, eliminating the Boost.Thread locking on the random number generator as a factor, as promised earlier today. Here are the raw timings: (Debug build) Baseline: 29.4, 36.0, 32.8 (32.73) GCC move: 32.0, 35.3, 31.2 (32.83) Emulated Move: 28.4, 33.8, 28.4 (30.20) Copy-on-write: 27.3, 25.0, 26.9 (26.40) (Release build) Baseline: 10.5, 12.5, 10.6 (11.20) GCC move: 11.3, 13.0, 10.4 (11.57) Emulated move: 10.0, 10.8, 9.7 (10.17) Copy-on-write: 8.5, 8.4, 9.4 ( 8.77) Times are measured in seconds, using two sets of ten 2048-bit integers. The tests consisted of adding each of those pairs of numbers together 10,000 times, multiplying them 10,000 times, and doing a "mulmod" operation on them (with a third randomly-generated 2048-bit modulus argument) 1,000 times. Each test was run three times, under as close to identical situations as I could manage, with the raw results (rounded to the nearest tenth of a second) in the first three columns; the fourth column is the average of the three. The compiler used was GCC 4.4.3, under Ubuntu Linux 10.04. The release build used -O2 optimization; the debug build used none. Otherwise, the settings were left at their defaults, except where noted below. The baseline configuration had neither copy-on-write nor any kind of move semantics enabled. The "emulated move" rows used the baseline configuration plus Boost.Move in C++03 emulation mode, with no copy-on-write; the "GCC move" rows indicate the exact same configuration, except that I used "-std=c++0x" as well (so presumably Boost.Move would switch to compiler-supplied move semantics). The copy-on-write rows used the baseline configuration, but enabled my copy-on-write system. Using the calculation... (baseline_time - time) / baseline_time ... copy-on-write provided a 19.3% and 21.7% speed increase over the baseline settings. Boost.Move emulation provided 7.7% and 9.2%. GCC-provided move semantics were, surprisingly, the worst performers, coming in at 0.3% and 3.3% *worse* than the baseline performance. I'm assuming that that code hasn't been optimized yet, and that it will eventually be a lot faster. Conclusions: * The copy-on-write system is faster than Boost.Move emulation by a respectable amount, and an even greater one than my earlier tests indicated. * The non-thread-safe version is *not* twice the speed of the thread-safe one, as I erroneously indicated before. Much of the difference must have come from the random number locking. It's still markedly faster, as it uses copy-on-write and the thread-safe version can only use Boost.Move, but only by about 12%. Am I missing any statistics? Does anyone want the test code to reproduce this and look for errors in my test setup? It's only a small modification from the code in the sandbox and vault, plus the test function. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvd5ZwACgkQp9x9jeZ9/wTnnQCfYt1MrUNFGnYKNJImYKuuryDf HfYAoIrXeBgsT25cCwI/oiIAShSyvyh0 =nZxq -----END PGP SIGNATURE-----

7 36

[GSoC] Helping out Phoenix v3
by Joel Falcou 04 May '10

04 May '10

Joel and I pondered about getting a student from GSoC to help us complete the phoenix v3 port to proto. I currently have a few prototypes and ideas to extend it further but a few more hands are most welcome. Considering the schedule, I'll be compeltely free for mentoring this prospective student. Now, is it realistic and on topic for GSoC ?

9 33

boost atomic question
by Janek Kozicki 04 May '10

04 May '10

Hello Helge, What would it take to get this code to work? std::vector<boost::atomic<Something> > v; v.resize(100); best regards -- Janek Kozicki http://janek.kozicki.pl/ |

6 12

Re: [boost] [xint] Third release is ready, requesting preliminary review
by Jürgen Hunold 04 May '10

04 May '10

Hi Chad, Am Dienstag, 4. Mai 2010, um 01:26:42 schrieben Sie: > On 05/03/2010 08:37 AM, Juergen Hunold wrote: > > Well, I'm concentrating on Boost.Build issues. The rest looks nice. > > Please find some improvements to you current setup attached. [...] > > I'm confused... I thought you'd done something different. It seems I should submit smaller pachtes, my fault. > Why did you > split up the test program into multiple programs? What benefit does that > offer over a single executable? Well, as long as you run the tests locally, this might be better. But as soon as your lib is part of the regular regression tests, you have to deal with *lots* of possible errors. This could be: - timeout on slow machines due to too long execution time - compile and/or link errors And it make things easiser if you only have on "red" entry in the summary page and can just see which test file to look at. And smaller test cases are just current Boost standard. And I think the patch +#ifdef BOOST_XINT_SINGLE_TEST_PROGRAM + #define BOOST_TEST_DYN_LINK +#else + #define BOOST_TEST_MAIN +#endif is wrong. BOOST_TEST_DYN_LINK should always be defined on the command line when linking against a shared Boost.Test library. So, no source code #define is necessary. The code above breaks when doing "bjam link=static" with "in function main:/rmc/hunold/packages/boost/boost/test/unit_test.hpp:59: error: undefined reference to 'boost::unit_test::unit_test_main(bool (*)(), int, char**)'" because Boost.Test expects "main" to be linked into the static library. And this issues " test_main.cpp:95:1: warning: "BOOST_TEST_DYN_LINK" redefined <command-line>: warning: this is the location of the previous definition" when compiling a shared library with all Boost.Build magic enabled. By the way: You have deleted test/Jamroot. Should there be a "test/Jamfile" instead ? build/Jamfile.v2 still contains "nothrow_random.cpp" which was deleted in 61752 as well. And I think you may also check in files for other build systems, too. Some libraries have Makefiles as well as visual studio solutions. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * juergen.hunold(a)gmx.de ! -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[xint] Boost.Move vs Copy-on-Write timings, remeasured
by Chad Nelson 04 May '10

04 May '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks to a bug that I was blind to, and that Jeffrey Hellrung gently pointed out (for which I give him public thanks), the earlier timings weren't accurate. I've corrected the problem and remeasured the times. You can find the earlier timings, along with the details of the testing, here: <http://permalink.gmane.org/gmane.comp.lib.boost.devel/203539>. Here are the updated timings (for release builds only, I didn't see a point in doing debug builds this time): Baseline: 8.6, 8.8, 8.8 (8.73) GCC move: 8.6, 8.6, 8.8 (8.67) Emulated move: 8.8, 8.5, 8.6 (8.63) Copy-on-write: 6.5, 6.7, 6.9 (6.70) Comparing to the originals, it looks like the change benefited all four, but I guarantee that it couldn't have affected the copy-on-write score. The only way I can explain the overall reduction is that my (virtual) development machine was running slower in the old tests. The change in relative scores is more interesting. The baseline, GCC move, and emulated move scores are now within 1% of each other, strongly suggesting that the compiler's Return Value Optimization is making the inclusion of Boost.Move nearly irrelevant. Emulated move semantics still beat out the compiler-supplied ones, but the difference is so small that that could well be within the margin of error. What is surprising and somewhat baffling to me is that even though the copy-on-write code wasn't affected by the change, that version is *still* better, and by an even (slightly) larger percentage than before (23.2%, as opposed to 21.7% in the previous test). I can only come up with two possible explanations for that: either there's some other piece of code in there that's preventing move semantics from working to their full potential, or copy-on-write is benefiting something other than return values, and by a ridiculously large amount. In either case, I don't know what could be responsible, but I'll keep looking for it. The updated code is now in the sandbox, for those who might want to test it themselves. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvgNHEACgkQp9x9jeZ9/wRAOACeMf9Lvu2Zn/uduwRAVYIH11o9 swgAoKsmap30FR4MywZ1uy+ON2+gjfy7 =VoRk -----END PGP SIGNATURE-----

1 0

Re: [boost] [iterator] Help needed understanding output_iterator requirements
by Thomas Klimpel 04 May '10

04 May '10

Dear authors of Boost.Iterator, As described in <http://lists.boost.org/Archives/boost/2010/03/163133.php>, Boost.MultiArray is currently unusable with the recently released MSVC 10. This is also confirmed by many failures in the regression tests: <http://www.boost.org/development/tests/release/developer/multi_array.html>. These failures are caused by a specific behavior of iterator_facade from Boost.Iterator, introduced by Jeremy Siek with the explanation "changed iterator_facade_default_category to stop lying about output_iterator_tag": <https://svn.boost.org/trac/boost/changeset/21683>. I'm not the right person to judge (or understand) how serious the original code was a lying, but the attached patch that conditionally reintroduces the original behavior as a workaround for MSVC 10 fixes all compile failures of the regression tests of Boost.MultiArray for me (MSVC 10 does compile time checking of iterator categories when _HAS_ITERATOR_DEBUGGING is defined). However, the "resize" regression test then fails with a runtime error (assertion failure) instead of a compile error: testing.capture-output ..\..\..\bin.v2\libs\multi_array\test\resize.test\msvc-10.0\debug\threading-multi\resize.run ====== BEGIN OUTPUT ====== Assertion failed: index_bases[n] <= start && start < index_bases[n]+index(extents[n]), file C:\nobackup\boost_trunk\boost/multi_array/base.hpp, line 446 C:\nobackup\boost_trunk\boost/test/minimal.hpp(123): exception "R6010 - abort() has been called " caught in function: 'int __cdecl main(int,char *[])' **** Testing aborted. **** 1 error detected EXIT STATUS: 201 ====== END OUTPUT ====== I have no idea whether this failure is related to the reintroduced lying or not. All I know is that there have been recent request to find "some kind of proper workaround or fix" for these issues: <http://lists.boost.org/Archives/boost/2010/04/165548.php>. But from my point of view, the only responsibility I may have with respect to these issues is to notify the authors of the affected libraries, which I have done now. Regards, Thomas

2 3

[GSoC] Bonding period
by Andrew Sutton 04 May '10

04 May '10

Hi All, If your proposal was accepted for GSoC 2010, then you will need to read this email thoroughly since it outlines the basic instructions for getting started with Boost development and your Summer Work. There are a couple of things you'll have to do (detailed instructions follow). 1. Introduce yourself to your mentor 2. Request SVN sandbox access from the Boost owners 3. Get started with Boost 4. Read about bjam and Quickbook 5. Write Code = Detailed instructions = == Introducing Yourself == Send an email to your mentor from the account that you want to receive Boost GSoC-related communications from. We're collecting your contact information in case we need to get in touch. If you have other secondary email address', please forward those also. There may be some organizational overhead to interacting with your mentor. We are still determining the best way to manage some aspects of this process. == Requesting SVN Access == Email the boost owner mailing list and request SVN *sandbox* write access for your GSoC project. Be sure to state that you are a student working on a GSoC 2010 project. Detailed instructions are given here [1] under "Getting a Trac SVN Userid". Your work will ultimately be hosted in this URL [2]. * Note to owners: if you want to validate students you can email me or I can grant you access to the GSoC webapp. == Getting Started == Read this [3] carefully, and follow the instructions. If you want to build Boost's trunk, follow the instructions here [4]. == Bjam and Quickbook == Bjam is the build tool used to compile Boost libraries, test suites, examples, and applications. For information on writing Bjam project files, read the manual, here [5]. Quickbook is the preferred* tool used to document the Boost libraries. It is a frontend to the BoostBook XML schema, which is an extension of the DocBook schema. The documentation toolchain is used to build online and PDF documentation for the Boost libraries. Documentation for writing Quickbook files can be found here [6]. * I could be wrong, but it is popular and also quite nice. == Writing Code == I would suggest trying to build (and document) some small example programs using the Boost development environment before diving in to your project. For example, port some of your programming assignments to Boost -- just don't commit them to the SVN repository :) This will help familiarize you with the Boost infrastructure. Also, read the Boost Guidelines and Requirements [7] before starting your project. These determine the layout of your directory structuring, how to name your files, and basic styles used throughout the Boost C++ Libraries. Additional information on techniques for generic programming can also be found here [8]. These techniques are used throughout many Boost libraries and are definitely worth reading about and understanding. I think that's about it for now. If I missed something, hopefully one of the other contributors will be able to point it out :) Welcome to Boost, and good luck on your summer projects! Andrew Sutton andrew.n.sutton(a)gmail.com [1] https://svn.boost.org/trac/boost/#GettingaTracSVNUserid [2] http://svn.boost.org/svn/boost/sandbox/SOC/2010/ [3] http://www.boost.org/doc/libs/1_42_0/more/getting_started/index.html [4] https://svn.boost.org/trac/boost/wiki/BoostSubversion [5] http://www.boost.org/doc/tools/build/doc/html/index.html [6] http://www.boost.org/doc/libs/1_42_0/doc/html/quickbook.html [7] http://www.boost.org/development/requirements.html [8] http://www.boost.org/community/generic_programming.html

7 16

[1.43.0] Release freeze
by Beman Dawes 04 May '10

04 May '10

AFAIK, we are ready to generate the 1.43.0 release candidates. For the current state of the release branch, see http://beta.boost.org/development/tests/release/developer/summary.html Please make no further changes to branches/release. I plan to generate release candidates later today. --Beman PS: There are still a number of VC++ 10 failures, but they will have to wait until after the release. I think we need a bug fixing sprint fairly soon to address those and other accumulated issues.

1 0

Re: [boost] [repost][multiarray] Bug with boost::detail::multi_array::array_iterator on MSVC 2010RC?
by Thomas Klimpel 04 May '10

04 May '10

Jesse Perla wrote: > I have attached my test files. Any ideas or patches would be appreciated I could reproduce the problem with MSVC 2010beta2. I noticed that only the debug version fails to build. So I added the line #define _HAS_ITERATOR_DEBUGGING 0 and everything compiled fine. So the simplest solution is to add ADD_DEFINITIONS(-D_HAS_ITERATOR_DEBUGGING=0) to your CMakeLists.txt, which many people recommend in any case, because they claim that the debug version under MSVC would otherwise violate the "runtime complexity specifications" of the corresponding containers and iterators. (I don't know whether this is really true, but I really think that this workaround is not unreasonable.) But of course, you want to know whether this is a bug in boost::multi_array or a bug in MSVC 2010beta2. Before we come to that, another "workaround" would be to change multi_array/iterator.hpp:56 for , boost::random_access_traversal_tag to , std::random_access_iterator_tag This will most probably work, but would lying to the standard library, because the reference reference type of the corresponding iterator is not value_type& (but a proxy): http://lists.boost.org/boost-users/2006/11/23565.php What effectively happens it that the iterator gets the category "input_iterator", but std::copy wants to have an "output_iterator". I think I understand why the iterator doesn't satisfies the requirement of a "forward_iterator", but it's unclear to me why it didn't qualify as an "output_iterator". There is an "input_output_iterator_tag" in "boost/iterator/detail/facade_iterator_category.hpp", so it would have been possible for the iterator to be both "input_iterator" and "output_iterator". However, it seems to me that "input_output_iterator_tag" is never used in the Boost.Iterator library. I would have to read more about "output_iterator" to understand whether Boost.Iterator is correct here. With my current understanding of "output_iterator", I would say it's a bug in "boost/iterator/detail/facade_iterator_category.hpp". Perhaps somebody with more knowledge about "output_iterator" and Boost.Iterator can explain to me why an iterator using the "boost::random_access_traversal_tag" for the "CategoryOrTraversal" template parameter of "iterator_facade" will never get the category "output_iterator" (or "input_output_iterator_tag"). Regards, Thomas

4 6