June 2014 - Boost - lists.preview.boost.org

New dependency report
by Peter Dimov 15 Jun '14

15 Jun '14

I've taken care of the mpl -> detail detail -> iterator utility -> iterator critical dependencies, which improved things a bit. The new report is at http://www.pdimov.com/tmp/report-6d1f271/module-overview.html http://www.pdimov.com/tmp/report-6d1f271/module-levels.html It includes reverse dependencies for each module and has been generated from the develop branch of the super-project.

13 115

[Modularization] Dependency diagrams
by Stephen Kelly 15 Jun '14

15 Jun '14

Hello, I have uploaded dependency diagrams for all boost libraries here: http://www.steveire.com/boost/deps-june-14/ The following incidental modules exist: incidentalModules["mpl"] = ("mpl", "type_traits", "typeof", "utility") incidentalModules["math"] = ("math", "lexical_cast") incidentalModules["spirit"] = ("spirit", "pool", "thread", "date_time", "serialization", "chrono", "interprocess") incidentalModules["graph"] = ("graph_", "disjoint_sets", "bimap", "property_map", "mpi", "graph_parallel") incidentalModules["scope_exit"] = ("scope_exit", "local_function") incidentalModules["range"] = ("range", "algorithm", "tr1", "random") The "incidental spirit" module and the "incidental range" modules are problematic. When the serialization->spirit range->algorithm edges are removed, they cease to exist as incidental modules, and the dependency graphs simplify: http://www.steveire.com/boost/after-edge-removal-june-14/ Compare: http://www.steveire.com/boost/deps-june-14/assign.png http://www.steveire.com/boost/after-edge-removal-june-14/assign.png http://www.steveire.com/boost/deps-june-14/range.png http://www.steveire.com/boost/after-edge-removal-june-14/range.png There are obviously more edges that can be investigated, but I recommend addressing serialization->spirit range->algorithm as a priority for now to remove those incidental modules. The "incidental mpl" module is not a priority problem, because anything which depends on the "incidental mpl" module mostly also depends on its dependencies. So, transitively speaking, it is mostly not a problem. It would be nice to resolve it a bit, but it does not need to be a priority. http://www.steveire.com/boost/deps-june-14/mpl.png The "incidental graph" module is not a priority problem because few other modules depend on any of it (only numeric_odeint). So, transitively speaking, it is mostly not a problem. It would still be nice to resolve it a bit to affect the modules inside the closure, but it does not need to be a priority. http://www.steveire.com/boost/graph-rdeps-june-14.png The "incidental scope_exit" module is being addressed afaiu, but it is also not a problem, transitively speaking. Nothing depends on either of them. Thanks, Steve.

2 1

[boost.test] Invoking test case from within another case
by Philip Bennefall 14 Jun '14

14 Jun '14

Hi all, I have built a performance measurement template function that can measure the time that a given piece of code takes to run, as well as provide some statistics such as standard deviation over x iterations etc. I am looking to integrate this into my existing boost.test setup, in a new suite called performance. This works fine if I write new test cases inside the performance test suite that invoke this function, but my goal is to also be able to run preexisting test cases in other suites to measure their performance. It'd be a bit hacky to have to include them again inside the new namespace. Is there a way to invoke a test in a specific test suite from inside another test case? Kind regards, Philip Bennefall

1 0

How do I download module Core?
by Andrzej Krzemienski 14 Jun '14

14 Jun '14

Hi, I can see that module Core is already available on branch Master. But when I try to pull the sources from GitHub (with 'git pull --rebase') it doesn't show up in my clone. Do I need to do anything to see it? Regards, &rzej

5 10

[modular] Re: [regression] Test results unavailable
by Rene Rivera 13 Jun '14

13 Jun '14

It's broken.. Don't know why though. Perhaps the recent code moves have made the testing tools not compile? On Fri, Jun 13, 2014 at 3:04 PM, Adam Wulkiewicz <adam.wulkiewicz(a)gmail.com> wrote: > Hi, > > I noticed that the results are unavailable. Was this planned or is > something broken? > > Regards, > Adam > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 5

[regression] Test results unavailable
by Adam Wulkiewicz 13 Jun '14

13 Jun '14

Hi, I noticed that the results are unavailable. Was this planned or is something broken? Regards, Adam

1 0

[random] new threefry random engine
by Thijs van den Berg 13 Jun '14

13 Jun '14

Hi all, I've completed a nice new random engine that I would like to propose for addition to boost/random. The engine is called "threefry" and it's based on the paper "Parallel random numbers: as easy as 1, 2, 3" by Salmon, John K. and Moraes, Mark A. and Dror, Ron O. and Shaw, David E. I've been using it myself a lot for the last couple of years, and now I've rewritten it so that it will fit in the boost random framework and adhere to the concepts. It has some really nice properties, in particular for large scale parallel computing: * High quality randomness (according to the BigCrush tests) with a cycle length of 2^258 * Fast (comparable to Mersenne Twister) & little memory usage (13x 64 bit integers) * O(1) discard and guarantees for non-overlapping sequences when the (up to 256 bit) seeds are unequal I've uploaded the code, description and tests to https://github.com/sitmo/threefry The actual engine is at https://github.com/sitmo/threefry/blob/master/random/include/boost/random/t… I would really appreciate any feedback about the idea for inclusion and of course comments about the quality of the code,tests,docs kind regards, Thijs Sitmo Consultancy B.V. Financial Modelling & Data Science + 31 6 24110061 thijs(a)sitmo.com P.O. Box 1059, 2600BB, Delft, The Netherlands

10 60

Errors Compiling in AIX 7.1 with gcc
by Axel Ismirlian 13 Jun '14

13 Jun '14

Hello, I am trying to compile boost on AIX 7.1 with gcc, but I am getting several errors. The configuration checks report that zlib support is disabled even though I do have that package installed. I also don't have icu support. Is there a package for that in AIX? I was not able to find one. Performing configuration checks - symlinks supported : yes - 32-bit : yes - arm : no - mips1 : no - power : yes - lockfree boost::atomic_flag : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : no - iconv (libc) : no - iconv (separate) : yes - icu : no - icu (lib64) : no - x86 : no - gcc visibility : no - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - zlib : no I also tried adding a user-config.jam in the boost/ (the same place as the project-config.jam) in order to add some flags to my gcc compilation and to use mpi, but my jam was soundly ignored. However, the most concerning of these errors is some apparent assembler error. gcc.compile.asm bin.v2/libs/context/build/gcc-4.8.1/release/link-static/threading-multi/asm/make_ ppc32_sysv_xcoff_gas.o Assembler: /tmp//cc0uhEhf.s: line 5: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 8: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 8: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 8: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 8: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 11: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 15: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 19: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 22: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 25: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 27: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 28: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 30: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 32: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 34: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 37: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 40: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 46: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 48: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 50: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 53: 1252-142 Syntax error. I'm not sure how to go about fixing that. When I go to my /tmp/ directory ccvhH2Fc.s is not an assembler file present. Right after this message another error appears. ...failed gcc.compile.asm bin.v2/libs/context/build/gcc-4.8.1/release/link-static/threading-multi /asm/jump_ppc32_sysv_xcoff_gas.o... gcc.compile.c++ bin.v2/libs/context/build/gcc-4.8.1/release/link-static/threading-multi/untested. o libs/context/src/untested.cpp:7:2: error: #error "! code for this platform is untested - please r emove this file from build/Jamfile.v2 and report the test-result on boost-track !" #error "! code for this platform is untested - please remove this file from build/Jamfile.v2 and report the test-result on boost-track !" What is the complete path for the Jamfile.v2 that this error refers to? Any advice the community can offer would be greatly appreciated. Sincerely, -Axel

2 1

[thread] Mass test failures on clang
by Andrey Semashev 13 Jun '14

13 Jun '14

Hi, I'm seeing mass test failures in Atomic and Log both in develop and master. E.g.: http://www.boost.org/development/tests/develop/developer/atomic.html http://www.boost.org/development/tests/master/developer/atomic.html The logs are not descriptive (as usual) but point to Thread compilation: http://www.boost.org/development/tests/develop/developer/output/teeks99-04b… Could this be resolved? The freeze deadline is nearing, so I'd like to see my test results at least once before it is reached.

4 12

Code review for bug no. 7396
by ullas srinivas 13 Jun '14

13 Jun '14

Hi, I have fixed bug no. 7396 Bug # 7396 :filesystem::path::remove_all(path, error_code) throws filesystem_error exception Description : Several methods in filesystem::path, including remove_all, have an overload in which an extra error_code& argument is taken. According to the docs, this is supposed to cause failure (other than failure to allocate storage) to be reported in the error_code rather than as a thrown filesystem_error exception. However, remove_all can still throw filesystem_error exceptions because it uses a directory_iterator internally but makes no attempt to catch exceptions thrown by it. For example, if a subdirectory is deleted by another thread or process just before remove_all tries to list its contents, directory_iterator_construct will throw a filesystem_error that propagates up to remove_all's caller. As a side note, I think path and directory_iterator are both excessively exception-happy. It makes them painful to use. Root Cause : The exceptions thrown by fs::directory_iterator were not handled in remove_all_aux function of operations.cpp file. Fix: The exceptions thrown by fs::directory_iterator are handled by catching the exception and proper ly assigning error values . Try-catch statement has been put inside remove_all_aux function of operations.cpp file. I kindly request you to please find the patch file attached and review the bug Regards Ullas

1 0