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

[phoenix] 9111 and 9113
by Fletcher, John P 23 Jan '14

23 Jan '14

________________________________________ From: Boost [boost-bounces(a)lists.boost.org] on behalf of Mathias Gaunard [mathias.gaunard(a)ens-lyon.org] Sent: 21 January 2014 16:44 To: boost(a)lists.boost.org Subject: Re: [boost] [phoenix] New maintainer On 20/01/14 13:40, Fletcher, John P wrote: >> If you have any information on your problems with Phoenix, in particular any not already on the bug system, please let me know. >> > I filed bugs about warnings a while ago. (9111, 9113) > It shouldn't take much work to fix those and it would be great if I > could finally make my code compile without warnings. I have now pushed a fix for 9111 and some fixes for 9113 to the develop branch. The report on 9113 says there are others, so any other reports would be helpful. John _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

raw.github.com access from behind firewall
by Belcourt, Kenneth 22 Jan '14

22 Jan '14

Hi, When I try to run github hosted regression tests with run.py, access to raw.github.com times out even though it seems to be using the specified our proxy server. # Running regressions in /scratch/modular-boost... # Creating regression scripts at /scratch/modular-boost/tools_regression_src... # Dowloading regression scripts from https://raw.github.com/boostorg/boost/develop/tools/regression/src... --- http://wwwproxy.sandia.gov:80 What's interesting is that I'm able to clone from github.com just fine, as you can see here. -bash-4.1$ git clone https://github.com/boostorg/boost Initialized empty Git repository in /scratch/modular-boost/boost/.git/ remote: Counting objects: 180556, done. remote: Compressing objects: 100% (68339/68339), done. remote: Total 180556 (delta 111934), reused 180501 (delta 111879) Receiving objects: 100% (180556/180556), 68.21 MiB | 10.23 MiB/s, done. Resolving deltas: 100% (111934/111934), done. But we're not able to clone from raw. -bash-4.1$ git clone https://raw.github.com/boostorg/boost Initialized empty Git repository in /scratch/modular-boost/boost/.git/ error: The requested URL returned error: 403 while accessing https://raw.github.com/boostorg/boost/info/refs fatal: HTTP request failed which means this clone (https://raw.github.com/boostorg/boost/develop/tools/regression/src) will fail. Is this a known issue and / or is there a workaround for this? This is on RHE Linux with git 1.8.5.1. -- Noel Belcourt

3 9

[phoenix] bug 9111
by Fletcher, John P 22 Jan '14

22 Jan '14

From: Boost [boost-bounces(a)lists.boost.org] on behalf of Mathias Gaunard [mathias.gaunard(a)ens-lyon.org] Sent: 21 January 2014 16:44 To: boost(a)lists.boost.org Subject: (was Re: [boost] [phoenix] New maintainer > I filed bugs about warnings a while ago. (9111, 9113) > It shouldn't take much work to fix those and it would be great if I > could finally make my code compile without warnings. I have looked at the code for no 9111 and it looks like this: template <int M, typename RhsRT, typename RhsFP> bool operator==(function_ptr<M, RhsRT, RhsFP> const & rhs) const { return false; } For some reason that specialized case is always returning false, which is why rhs is unused. I need to look into why that is the case, or else do some dummy operation on rhs which will suppress the warning. John

2 2

[config] BOOST_NOINLINE on nvcc
by Mathias Gaunard 22 Jan '14

22 Jan '14

Hi, I noticed that I had some problems with some nvcc (NVIDIA CUDA) versions and BOOST_NOINLINE. The logic for defining BOOST_NOINLINE seems to be the same as that of BOOST_FORCEINLINE, which does work correctly, so it seems to be a nvcc bug that's not fully compatible with GCC despite claiming to be. What would be the correct way to fix that?

3 4

[git] boost + git flow
by Oliver Kowalke 22 Jan '14

22 Jan '14

does boost follows the git-flow schema, e.g. merging the changes from branch develop into master is not required by the library developer (this is done by the release manager)?! Oliver

5 4

[testing] Reports that lead nowhere?
by John Maddock 22 Jan '14

22 Jan '14

While we're updating and fixing testing issues, I notice the report generator is still creating content-free failures, for example this one: http://www.boost.org/development/tests/develop/developer/marshall-mac-regex… Ultimately leads nowhere :-( Thanks, John.

4 4

[regex] Need some help with msvc-11/12
by John Maddock 22 Jan '14

22 Jan '14

Can anyone with access to msvc-11 or 12 tell me what's causing this failure: http://www.boost.org/development/tests/develop/developer/output/DrWeb_vc12_… You will probably need to build and run under the debugger to find out I suspect... Many thanks in advance, John.

3 4

Support for Android
by Vicente J. Botet Escriba 22 Jan '14

22 Jan '14

Hi, I see that there are some trouble with Boost and Android: https://svn.boost.org/trac/boost/ticket/9082 http://www.boost.org/development/tests/develop/developer/output/apolukhin-A… Could someone state what is the Boost approach to support Android? Should the user build with NDK r8e? Does bjam supports a specific android platform? Best, Vicente

4 11

[wave] preprocessor directives in output
by Eric Niebler 22 Jan '14

22 Jan '14

I'm looking at automating the regeneration of Fusion's preprocess headers with the wave tool. Currently, it's impossible because of stuff like this (from container\vector\vector.hpp): #if !defined(BOOST_NO_CXX11_RVALUE_REFERENCES) vector(vector&& rhs) : vec(std::forward<vector_n>(rhs.vec)) {} #endif When the wave driver is run, either BOOST_NO_CXX11_RVALUE_REFERENCES is defined, in which case the block of code gets left out, or else it isn't, in which case the block of code is left in. Both are wrong. What should happen is that the #if and #else directives should be present in wave's output. I can keep wave from expanding certain named macros with the -N switch, but there doesn't seem to be a way to selectively keep wave from evaluating #if/#else directives. Or is there? Any help appreciated. Eric

8 18

[variant] Breaking change introduced by variadic support
by Agustín K-ballo Bergé 22 Jan '14

22 Jan '14

The recent changes to introduce variadic support to `variant` introduce breaking changes in the documented macros. When variadic support is detected, `BOOST_VARIANT_LIMIT_TYPES` is not defined and `BOOST_VARIANT_ENUM_[SHIFTED_]PARAMS` uses variadic templates instead of enumerating parameters. This is a breaking change in the documented interface, and one that requires all but the simplest use cases to be rewritten. For instance, this breaks _Boost.Spirit_ support of `variant` (https://svn.boost.org/trac/boost/ticket/9238), requiring two different implementations to be provided. Is this the preferred path to take? I would suggest instead to keep the macros as documented at all times, and let the user handle the variadic case manually. This would allow users to support both variadic and non-variadic `variant`s up to a certain limit with a single code case (without breaking the documented interface), and result in cleaner code for those cases that only target compilers with variadic support. There's no point in using a macro if it won't work for both cases. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

3 8