June 2015 - Boost - lists.boost.org

[build] Error building bjam on cygwin
by Emil Dotchevski 03 Jun '15

03 Jun '15

I'm trying to build bjam from Boost 1.56.0 under cygwin. Running ./build.bat mingw errs with: gcc -DNT -o bootstrap\jam0.exe command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c filent.c:46:20: fatal error: direct.h: No such file or directory #include <direct.h> ^ compilation terminated More errors follow. What am I doing wrong? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

[thread] Problem with thread test 'failed to write output file'
by Edward Diener 03 Jun '15

03 Jun '15

Attempting to run the 'thread' tests locally I get: failed to write output file '..\..\..\bin.v2\libs\thread\test\upg_lock_cons_move_ctor_sh_lock_untl_p_lib.test\msvc-12.0\debug\threading-multi\sync\mutual_exclusion\locks\upgrade_lock\cons\move_ctor_shared_lock_until_pass.obj.rsp'! This is with the --abbreviated-path option. If I try using --hash or not using either on the b2 command line I still get the same result of 'failed to write output file ... etc,' probably because the output file spec is still too long. This happens on Windows thread tests with msvc-12.0 but not with gcc-4.9.2. Any ideas how I can get this to run successfully ?

1 1

[admin] General Boost email?
by Rene Rivera 02 Jun '15

02 Jun '15

I've been experimenting with the various cloud based CI systems out there in an effort to make it easy to have all Boost libraries CI tested. As part of that I'm trying to set up an organization account in Appveyor and I'm stuck.. As I need a global org email to register. Hence I would like to request that we set up an "owners(a)boost.org" email that we can use for such circumstances (that just forwards to the git boostorg owners). Does that sound OK? Whom would set up such an email? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[test] possible bug in 1.47.0
by Damian Vicino 02 Jun '15

02 Jun '15

Hi, I’m working in the safe_float library and while working on it I defined a partial specialisation of numeric_limits for safe_float. I wanted the safe_float<T> to mimic the T numeric_limits in most of the values and just change a few, but nothing complex, one liners only. Then, I created a test for validating those methods/attributes mimicking the internal T are equal to those on T, as follows: //types to be tested using test_types=boost::mpl::list< float, double, long double >; using namespace boost::safe_float; BOOST_AUTO_TEST_CASE_TEMPLATE( safe_float_numeric_limits_basic_fp_types, FPT, test_types){ BOOST_CHECK_EQUAL(std::numeric_limits<safe_float<FPT>>::is_specialized, std::numeric_limits<FPT>::is_specialized); } The test does not even compile: Undefined symbols for architecture x86_64: "std::__1::numeric_limits<boost::safe_float::safe_float<double, boost::safe_float::policy::check_addition_overflow, boost::safe_float::policy::on_fail_throw, boost::safe_float::policy::cast_none> >::is_specialized", referenced from: safe_float_numeric_limits_suite::safe_float_numeric_limits_basic_fp_types<double>::test_method() in numeric_limits_test.o After looking at the numeric_limits specialisation for a while, I tried changing the test as follows: if (std::numeric_limits<safe_float<FPT>>::is_specialized == std::numeric_limits<FPT>::is_specialized){ BOOST_CHECK(true); } else { BOOST_CHECK(false); } And as follows: BOOST_CHECK(std::numeric_limits<safe_float<FPT>>::is_specialized == std::numeric_limits<FPT>::is_specialized); Both alternatives work. Is there something wrong with BOOST_CHECK_EQUAL? I’m using version 1.47.0 Best regards, Damian

2 1

Boost.Test v3 is here
by Gennadiy Rozental 02 Jun '15

02 Jun '15

Boost.Test team is proud to present new version of Boost.Test library. This milestone release among many other thing includes: * Completely updated (and hopefully improved) documentation * New universal testing tool BOOST_TEST * Support for decorators * Support for data driven test cases * and much more (you can see changelog here: http://raffienficiaud.github.io/test/boost_test/change_log.html This release would not be possible without Raffi Enficiaud, who joined the team and jump started documentation rework and Andrzej Krzemieński's major contribution to the new documentation. We invite everyone to review and comment on new documentation (http://raffienficiaud.github.io/test/index.html) We will be happy to accept your pull requests with improvements and notes in the mailing list. Unless we find any major showstopper we plan to merge to the master branch in 2-3 weeks time. We do not anticipate backward compatibility issues, but please report any you observe and we'll try to address them in a timely manner. Once again, please review the new documentation and feel free to comment here or by sending us pull requests. Regards, Gennadiy Rozental

8 12

Running regression tests locally
by Andrzej Krzemienski 01 Jun '15

01 Jun '15

Hi Everyone, I need an advice here. When I look at the test matrix online, I can easily see how many tests failed. In contrast, when I run the tests locally (call b2 in folder 'test') I get a bunch of output, but I cannot easily figure out if and how many tests have failed. Is there a way to do it? Or to build a summary of some sort? Regards, &rzej

2 1

[b2] Need help with b2
by Andrzej Krzemienski 01 Jun '15

01 Jun '15

Hi everyone, Today after doing a `git pull --rebase` on modular Boost, b2 stopped working for me. I keep getting the following error. Can someone help me figure out what this is? Regards, &rzej C:/source/modular-boost/tools/build/src/build\feature.jam:139: in feature.feature from module feature error: unknown attributes: hidden error: in feature declaration: error: feature "deduced-address-model" : "32" "64" : "propagated" "optional" "composite" "hidden" C:/source/modular-boost\boostcpp.jam:570: in load from module boostcpp C:/source/modular-boost/tools/build/src/kernel\modules.jam:289: in modules.import from module modules C:/source/modular-boost/tools/build/src/build\project.jam:1024: in import from module Jamfile<C:\source\modular-boost> ..\..\..\Jamroot:124: in modules.load from module Jamfile<C:\source\modular-boost> C:/source/modular-boost/tools/build/src/build\project.jam:311: in load-jamfile from module project C:/source/modular-boost/tools/build/src/build\project.jam:64: in load from module project C:/source/modular-boost/tools/build/src/build\project.jam:113: in load-parent from module project C:/source/modular-boost/tools/build/src/build\project.jam:449: in initialize from module project C:/source/modular-boost/tools/build/src/build\project.jam:301: in load-jamfile from module project C:/source/modular-boost/tools/build/src/build\project.jam:64: in load from module project C:/source/modular-boost/tools/build/src/build\project.jam:113: in load-parent from module project C:/source/modular-boost/tools/build/src/build\project.jam:449: in initialize from module project C:/source/modular-boost/tools/build/src/build\project.jam:301: in load-jamfile from module project C:/source/modular-boost/tools/build/src/build\project.jam:64: in load from module project C:/source/modular-boost/tools/build/src/build\project.jam:145: in project.find from module project C:/source/modular-boost/tools/build/src\build-system.jam:535: in load from module build-system C:\source\modular-boost\tools\build\src/kernel\modules.jam:289: in import from module modules C:\source\modular-boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build from module C:\source\modular-boost\boost-build.jam:17: in module scope from module

2 2

Correct Mutext Destroy Behaviour, Pthreads and Boost
by Robert Bell 01 Jun '15

01 Jun '15

If an object is implemented to support reference counting, and has an internal raw pthread mutex, the open group is pretty clear in the pthread_mutex_destroy doc on what different implementations must ensure (http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_dest…) Note the following statement at the bottom: "A mutex can be destroyed immediately after it is unlocked. For example, consider the following code:" obj_done(struct obj *op) { pthread_mutex_lock(&op->om); if (--op->refcnt == 0) { pthread_mutex_unlock(&op->om); (A) pthread_mutex_destroy(&op->om); (B) free(op); } else (C) pthread_mutex_unlock(&op->om); } In this case obj is reference counted and obj_done() is called whenever a reference to the object is dropped. Implementations are required to allow an object to be destroyed and freed and potentially unmapped (for example, lines A and B) immediately after the object is unlocked (line C)." On moving some of my underlying libraries to Boost, I took a look at Boost's Mutex object. The implementation of the Mutex object's destructor call does: ~mutex() { int const res = posix::pthread_mutex_destroy(&m); boost::ignore_unused(res); BOOST_ASSERT(!res); } My question centres on whether Boost's implementation violates the open group's requirement. The calls to posix::pthread_mutex_destroy (Boost's wrapper), usually perform a straight-through call to ::pthread_mutex_destroy, but it occurs inside the destructor, and so does this call occur "immediately after" an unlock by the group's definition? In straight pthreads, if I want to make sure I can rely on various implementations of the standard, I can simply do exactly what the open group says, unlock, and the next line destroy. But in the case of Boost, is it safe to do something like: mutex->unlock(); delete mutex_; One thing I did note of interest is that Apple's implementation seems to lock the mutex from within the destroy call, which is curious: int pthread_mutex_destroy(pthread_mutex_t *mutex) { int res; LOCK(mutex->lock); if (mutex->sig == _PTHREAD_MUTEX_SIG) { if (mutex->owner == (pthread_t)NULL && mutex->busy == (pthread_cond_t *)NULL) { mutex->sig = _PTHREAD_NO_SIG; res = ESUCCESS; } else res = EBUSY; } else res = EINVAL; UNLOCK(mutex->lock); return (res); } There seems, generally, to be a good deal of confusion surrounding when it is safe to destroy the resources associated with a mutex, and most people offer widely inaccurate comments based largely on opinion. My question points to whether code adjacency is a requirement of correct behaviour in some implementations, and if not, why not? If I have missed an obvious explanation somewhere, my apologies. I read through the different patterns of Boost threading listed in the documentation, but was not convinced the question was addressed. Thanks in advance…

4 5

Resources available for testing on 64-bit MSVC
by pfultz2 01 Jun '15

01 Jun '15

Hello, Recently, I have been working on adding MSVC support for the Fit library, and I have been fairly successful. Using the VMs at modern.ie, I was to able to get all the tests to pass on 32-bit Visual Studio 2015 RC. Unfortunately, a few tests fail on the 64-bit MSVC, and I have been unable to find a VM I can use to debug the problem. All the VMs at modern.ie are 32-bit, it seems. Does anyone know of resources available to test and debug libraries with 64-bit MSVC? Thanks, Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Resources-available-for-testing-on-64-bi… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[next gen future-promise] What to call the monadic return type?
by Niall Douglas 01 Jun '15

01 Jun '15

Dear list, As AFIO looks likely to be finally getting a community review soon, I've made a start on a final non-allocating constexpr-collapsing next generation future-promise such that the AFIO you review is "API final". You may remember my experimentations on those from: http://boost.2283326.n4.nabble.com/Non-allocating-future-promise-td466 8339.html. Essentially the win is that future-promise generates no code at all on recent C++ 11 compilers unless it has to [1], and when it does it generates an optimally minimal set with no memory allocation unless T does so. This should make these future-promises several orders of magnitude faster than the current ones in the C++ standard and solve their scalability problems for use with things like ASIO. They also have major wins for resumable functions which currently always construct a promise every resumable function entry - these next gen future-promises should completely vanish if the resumable function never suspends, saving a few hundred cycles each call. Anyway, my earlier experiments were all very promising, but they all had one big problem: the effect on compile time. My final design is therefore ridiculously simple: a future<T> can return only these options: * A T. * An error_code (i.e. non-type erased error, optimally lightweight) * An exception_ptr (i.e. type erased exception type, allocates memory, you should avoid this if you want performance) In other words, it's a fixed function monad where the expected return is T, and the unexpected return can be either exception_ptr or error_code. The next gen future provides Haskell type monadic operations similar to Boost.Thread + Boost.Expected, and thanks to the constexpr collapse this: future<int> test() { future<int> f(5); return f; } test().get(); ... turns into a "mov $5, %eax", so future<T> is now also a lightweight monadic return transport capable of being directly constructed. In case you might want to know why a monadic return transport might be so useful as to be a whole new design idiom for C++ 11, try reading https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:S tronglyconsiderusingconstexprsemanticwrappertransporttypestoreturnstat esfromfunctions. However, future<T> doesn't seem named very "monadic", so I am inclined to turn future<T> into a subclass of a type better named. Options are: * result<T> * maybe<T> Or anything else you guys can think of? future<T> is then a very simple subclass of the monadic implementation type, and is simply some type sugar for promise<T> to use to construct a future<T>. Let the bike shedding begin! And my thanks in advance. Niall [1]: Compiler optimiser bugs notwithstanding. Currently only very recent GCCs get this pattern right. clang isn't bad and spills a dozen or so completely unnecessary opcodes, and I'll follow up with Chandler with some bug reports to get clang fixed. Poor old MSVC spits out about 3000 lines of assembler, it can't do constexpr folding at all yet. -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

16 122