Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers
On Wed, Oct 26, 2011 at 3:41 PM, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
Does it build on VC11? Olaf
On Wed, Oct 26, 2011 at 5:53 PM, Stephan T. Lavavej <stl@exchange.microsoft.com> wrote:
[Olaf van der Spek]
Does it build on VC11?
It successfully built with my current build of VC11 x86 (newer than the Developer Preview, with STL hacking not yet checked in - always good to know that I won't break Boost).
Thanks for the report! Much appreciated! --Beman
On Wed, Oct 26, 2011 at 3:41 PM, Beman Dawes <bdawes@acm.org> wrote:
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
1>c:\vc\include\boost\move\move.hpp(28): warning C4005: '_SCL_SECURE_NO_WARNINGS' : macro redefinition 1> command-line arguments : see previous definition of '_SCL_SECURE_NO_WARNINGS' Olaf
On Wed, Oct 26, 2011 at 6:49 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Wed, Oct 26, 2011 at 3:41 PM, Beman Dawes <bdawes@acm.org> wrote:
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
1>c:\vc\include\boost\move\move.hpp(28): warning C4005: '_SCL_SECURE_NO_WARNINGS' : macro redefinition 1> command-line arguments : see previous definition of '_SCL_SECURE_NO_WARNINGS'
In another project: 1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\iterator(530): error C3859: virtual memory range for PCH exceeded; please recompile with a command line option of '-Zm110' or greater 1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\iterator(530): fatal error C1076: compiler limit : internal heap limit reached; use /Zm to specify a higher limit 1> Should this be expected with 1.48? -- Olaf
On Wed, Oct 26, 2011 at 07:26:27PM +0200, Olaf van der Spek wrote:
In another project: 1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\iterator(530): error C3859: virtual memory range for PCH exceeded; please recompile with a command line option of '-Zm110' or greater 1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\iterator(530): fatal error C1076: compiler limit : internal heap limit reached; use /Zm to specify a higher limit 1>
Is this from building Boost itself? If so, which library? If it's in your code that uses Boost, it's perfectly natural. When you build precompiled header files, there's a nice solid chunk of memory allocated for the compiler to stow away intermediary state in, which it then serializes to the PCH file, for loading into future compiler processes that use the precompiled header to bootstrap themselves. The problem is that this memory needs to be allocated up-front. All this message means is exactly what it says - the default amount is not sufficient and you need to change it in the build settings for the source file that builds your PCH, adding /Zm123 to the advanced compiler settings field there, or globally for your project. The reason you get this now and not before is because you've not used enough Boost libraries, and that the ones you do use have had their compile-time memory usage increased somewhat. -- Lars Viklund | zao@acc.umu.se
On Wed, Oct 26, 2011 at 7:57 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Wed, Oct 26, 2011 at 07:26:27PM +0200, Olaf van der Spek wrote:
In another project: 1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\iterator(530): error C3859: virtual memory range for PCH exceeded; please recompile with a command line option of '-Zm110' or greater 1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\iterator(530): fatal error C1076: compiler limit : internal heap limit reached; use /Zm to specify a higher limit 1>
Is this from building Boost itself? If so, which library?
If it's in your code that uses Boost, it's perfectly natural. When you build precompiled header files, there's a nice solid chunk of memory allocated for the compiler to stow away intermediary state in, which it then serializes to the PCH file, for loading into future compiler processes that use the precompiled header to bootstrap themselves.
It's my own project. It's the first time ever I see this warning and it didn't happen with 1.47.
The problem is that this memory needs to be allocated up-front. All this message means is exactly what it says - the default amount is not sufficient and you need to change it in the build settings for the source file that builds your PCH, adding /Zm123 to the advanced compiler settings field there, or globally for your project.
The reason you get this now and not before is because you've not used enough Boost libraries, and that the ones you do use have had their compile-time memory usage increased somewhat.
Hmm, right. Maybe it's time for MS to increase the default. :p -- Olaf
[Lars Viklund]
The problem is that this memory needs to be allocated up-front. All this message means is exactly what it says - the default amount is not sufficient and you need to change it in the build settings for the source file that builds your PCH, adding /Zm123 to the advanced compiler settings field there, or globally for your project.
[Olaf van der Spek]
Hmm, right. Maybe it's time for MS to increase the default. :p
The default is 75 MB on x86 (and 750 MB on x64), which is a fair amount of memory. Including all STL headers in VC10 SP1 consumed only 29.3 MB when I last measured it. This has been increased to 83 MB in VC11 as of right now. STL
On Thu, Oct 27, 2011 at 12:02 AM, Stephan T. Lavavej <stl@exchange.microsoft.com> wrote:
[Olaf van der Spek]
Hmm, right. Maybe it's time for MS to increase the default. :p
The default is 75 MB on x86 (and 750 MB on x64), which is a fair amount of memory. Including all STL headers in VC10 SP1 consumed only 29.3 MB when I last measured it.
Hmm, I'm on x64 but I'm compiling x86 code. What compiler does that use?
This has been increased to 83 MB in VC11 as of right now.
Why 11? -- Olaf
[Olaf van der Spek]
Hmm, I'm on x64 but I'm compiling x86 code. What compiler does that use?
The x86-native compiler. VC10 also has an x86=>x64 cross-compiler, and an x64-native compiler (this is the one that reserves tons of address space for its PCH, because it can). Additionally, VC10 had x86=>IA-64 cross, and VC11 has x86=>ARM cross. (If all of our compilers were x64-hosted, then PCH size problems would vanish in a puff of smoke.) [STL]
This has been increased to 83 MB in VC11 as of right now.
[Olaf van der Spek]
Why 11?
As the compiler changes their data structures, they change the PCH size default accordingly. STL
On Thu, Oct 27, 2011 at 12:40 AM, Stephan T. Lavavej <stl@exchange.microsoft.com> wrote:
[Olaf van der Spek]
Hmm, I'm on x64 but I'm compiling x86 code. What compiler does that use?
The x86-native compiler. VC10 also has an x86=>x64 cross-compiler, and an x64-native compiler (this is the one that reserves tons of address space for its PCH, because it can). Additionally, VC10 had x86=>IA-64 cross, and VC11 has x86=>ARM cross.
(If all of our compilers were x64-hosted, then PCH size problems would vanish in a puff of smoke.)
[STL]
This has been increased to 83 MB in VC11 as of right now.
[Olaf van der Spek]
Why 11?
As the compiler changes their data structures, they change the PCH size default accordingly.
So for the end-user the effect is 0? What's the disadvantage of reserving much more space for the PCH? -- Olaf
STL> This has been increased to 83 MB in VC11 as of right now. Olaf> Why 11? STL> As the compiler changes their data structures, they change the PCH size default accordingly. Olaf> So for the end-user the effect is 0? In most cases, yes. Olaf> What's the disadvantage of reserving much more space for the PCH? I'm not a compiler dev, but I believe that asking for more memory is more likely to fail - the PCH wants a contiguous block of virtual address space at a certain location. x86 doesn't have that much virtual address space to begin with (and the compiler is already playing a tricky game by asking for the PCH before any other DLLs are loaded). STL
On Thu, Oct 27, 2011 at 1:05 AM, Stephan T. Lavavej <stl@exchange.microsoft.com> wrote:
Olaf> What's the disadvantage of reserving much more space for the PCH?
I'm not a compiler dev, but I believe that asking for more memory is more likely to fail - the PCH wants a contiguous block of virtual address space at a certain location. x86 doesn't have that much virtual address space to begin with (and the compiler is already playing a tricky game by asking for the PCH before any other DLLs are loaded).
4 gb if it's large address aware and on x64, 2 gb otherwise. A fixed location shouldn't be too hard either. Olaf
On Wed, Oct 26, 2011 at 10:02:08PM +0000, Stephan T. Lavavej wrote:
[Lars Viklund]
The problem is that this memory needs to be allocated up-front. All this message means is exactly what it says - the default amount is not sufficient and you need to change it in the build settings for the source file that builds your PCH, adding /Zm123 to the advanced compiler settings field there, or globally for your project.
[Olaf van der Spek]
Hmm, right. Maybe it's time for MS to increase the default. :p
The default is 75 MB on x86 (and 750 MB on x64), which is a fair amount of memory. Including all STL headers in VC10 SP1 consumed only 29.3 MB when I last measured it.
This has been increased to 83 MB in VC11 as of right now.
In one of the projects I'm working on, /Zm is at a comfortable 350 MB. This of course is mostly due to putting any stable third party library used in the PCH, which while nice from a compile-time cost perspective, makes IntelliSense keel over and die. -- Lars Viklund | zao@acc.umu.se
Hello! In the version 1.48.0beta1 there was a bug which leads to impossibility to use at least boost.asio and boost.unordered. Bugreport: https://svn.boost.org/trac/boost/ticket/6062 And, please, fix a bug of Intel C++ and MSVC2010: https://svn.boost.org/trac/boost/ticket/5984 2011/10/26 Beman Dawes <bdawes@acm.org>
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
Thanks,
--The release managers
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- С уважением, Владислав Щапов ICQ: 223-695-654
On Wed, Oct 26, 2011 at 1:04 PM, Владислав Щапов <phprus@gmail.com> wrote:
Hello!
In the version 1.48.0beta1 there was a bug which leads to impossibility to use at least boost.asio and boost.unordered. Bugreport: https://svn.boost.org/trac/boost/ticket/6062
Looks like Daniel is on top of that one.
And, please, fix a bug of Intel C++ and MSVC2010: https://svn.boost.org/trac/boost/ticket/5984
That's in Marcin Kalicinski's lap. Neither of these are showstoppers for the beta. Thanks for the reports! --Beman
Beman Dawes <bdawes <at> acm.org> writes:
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
No failures or errors when building with MSVC10 SP1, for both 32-bit and 64-bit builds. However, if it's noteworthy, Wave is giving 'size_t truncated to int' warnings for 64-bit builds. Adam
Beman Dawes <bdawes <at> acm.org> writes:
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
No failures or errors when building with MSVC10 SP1, for both 32-bit and 64-bit builds. However, if it's noteworthy, Wave is giving 'size_t truncated to int' warnings for 64-bit builds.
Care to send me the logs (offline)? Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
Le 26/10/11 15:41, Beman Dawes a écrit :
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
This helps ensure the candidates build OK before we push them out to SourceForge.
Hi, Build Ok in Mac OS gcc 4.1.2. There are some build errors on MAC-OS clang in libraries Locale and Math. clang-darwin.compile.c++ bin.v2/libs/locale/build/clang-darwin-3.0x/release/threading-multi/posix/codecvt.o libs/locale/src/posix/codecvt.cpp:137:30: error: non-constant-expression cannot be narrowed from type 'unsigned char' to 'char' in initializer list char inseq[3] = {seq0 , begin[1], 0}; ^~~~ libs/locale/src/posix/codecvt.cpp:137:30: note: override this message by inserting an explicit cast char inseq[3] = {seq0 , begin[1], 0}; ^~~~ stat)c_cast<char>( 1 error generated. "/Users/viboes/clang/llvmCore-3.0-rc1.install/bin/clang++" -x c++ -std=c++0x -O3 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_LOCALE_DYN_LINK=1 -DBOOST_LOCALE_NO_WINAPI_BACKEND=1 -DBOOST_LOCALE_WITH_ICONV=1 -DBOOST_THREAD_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/locale/build/clang-darwin-3.0x/release/threading-multi/posix/codecvt.o" "libs/locale/src/posix/codecvt.cpp" ...failed clang-darwin.compile.c++ bin.v2/libs/locale/build/clang-darwin-3.0x/release/threading-multi/posix/codecvt.o... ...skipped <pbin.v2/libs/locale/build/clang-darwin-3.0x/release/threading-multi>libboost_locale.dylib for lack of <pbin.v2/libs/locale/build/clang-darwin-3.0x/release/threading-multi>posix/codecvt.o... ...skipped <pstage/lib>libboost_locale.dylib for lack of <pbin.v2/libs/locale/build/clang-darwin-3.0x/release/threading-multi>libboost_locale.dylib... clang-darwin.compile.c++ bin.v2/libs/math/build/clang-darwin-3.0x/release/threading-multi/cyl_bessel_i.o In file included from libs/math/build/../src/tr1/cyl_bessel_i.cpp:11: In file included from ./boost/math/special_functions/bessel.hpp:20: ./boost/math/special_functions/detail/bessel_ik.hpp:320:16: error: call to function 'bessel_i_small_z_series' that is neither visible in the template definition nor found by argument-dependent lookup Iv = bessel_i_small_z_series(v, x, pol); ^ ./boost/math/special_functions/bessel.hpp:276:4: note: in instantiation of function template specialization 'boost::math::detail::bessel_ik<long double, boost::math::policies::policy<domain_error<errno_on_error>, pole_error<errno_on_error>, overflow_error<errno_on_error>, evaluation_error<errno_on_error>, rounding_error<errno_on_error>, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> >' requested here bessel_ik(v, x, &I, &K, need_i, pol); ^ ./boost/math/special_functions/bessel.hpp:464:65: note: in instantiation of function template specialization 'boost::math::detail::cyl_bessel_i_imp<long double, boost::math::policies::policy<domain_error<errno_on_error>, pole_error<errno_on_error>, overflow_error<errno_on_error>, evaluation_error<errno_on_error>, rounding_error<errno_on_error>, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> >' requested here return policies::checked_narrowing_cast<result_type, Policy>(detail::cyl_bessel_i_imp<value_type>(v, static_cast<value_type>(x), pol), "boost::math::cyl_bessel_i<%1%>(%1%,%1%)"); ^ libs/math/src/tr1/c_policy.hpp:129:1: note: in instantiation of function template specialization 'boost::math::cyl_bessel_i<double, double, boost::math::policies::policy<domain_error<errno_on_error>, pole_error<errno_on_error>, overflow_error<errno_on_error>, evaluation_error<errno_on_error>, rounding_error<errno_on_error>, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> >' requested here BOOST_MATH_DECLARE_SPECIAL_FUNCTIONS(c_policy) ^ ./boost/math/special_functions/math_fwd.hpp:992:38: note: expanded from: cyl_bessel_i(T1 v, T2 x) { return boost::math::cyl_bessel_i(v, x, Policy()); }\ ^ libs/math/build/../src/tr1/cyl_bessel_i.cpp:16:11: note: in instantiation of function template specialization 'c_policies::cyl_bessel_i<double, double>' requested here return c_policies::cyl_bessel_i BOOST_PREVENT_MACRO_SUBSTITUTION(nu, x); ^ ./boost/math/special_functions/bessel.hpp:195:10: note: 'bessel_i_small_z_series' should be declared prior to the call site or in an associated namespace of one of its arguments inline T bessel_i_small_z_series(T v, T x, const Policy& pol) ^ 1 error generated. "/Users/viboes/clang/llvmCore-3.0-rc1.install/bin/clang++" -x c++ -std=c++0x -O3 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_MATH_TR1_DYN_LINK=1 -DNDEBUG -I"." -I"libs/math/src/tr1" -c -o "bin.v2/libs/math/build/clang-darwin-3.0x/release/threading-multi/cyl_bessel_i.o" "libs/math/build/../src/tr1/cyl_bessel_i.cpp" ...failed clang-darwin.compile.c++ bin.v2/libs/math/build/clang-darwin-3.0x/release/threading-multi/cyl_bessel_i.o... ... The same error appears several times then
There are some build errors on MAC-OS clang in libraries Locale and Math.
clang-darwin.compile.c++ bin.v2/libs/locale/build/clang-darwin-3.0x/release/threading-multi/posix/codecvt.o libs/locale/src/posix/codecvt.cpp:137:30: error: non-constant-expression cannot be narrowed from type 'unsigned char' to 'char' in initializer list char inseq[3] = {seq0 , begin[1], 0}; ^~~~ libs/locale/src/posix/codecvt.cpp:137:30: note: override this message by inserting an explicit cast char inseq[3] = {seq0 , begin[1], 0}; ^~~~ stat)c_cast<char>( 1 error generated.
I don't see this problem with clang-2.8. Why clang-3 does not allow code like (I don't have clang-3 to check)? int main() { unsigned char uc = 10; char c[2] = { uc , 1 }; } Is this really error, why the compiler does not cast?
... The same error appears several times then
Is this the same error all over? Can you send me the list of such locations or a patch so I'll be able to commit it to trunk and ask permissions to merge to release branch. Artyom
On Thu, Oct 27, 2011 at 3:52 AM, Artyom Beilis <artyomtnk@yahoo.com> wrote:
There are some build errors on MAC-OS clang in libraries Locale and Math.
clang-darwin.compile.c++ bin.v2/libs/locale/build/clang-darwin-3.0x/release/threading-multi/posix/codecvt.o libs/locale/src/posix/codecvt.cpp:137:30: error: non-constant-expression cannot be narrowed from type 'unsigned char' to 'char' in initializer list char inseq[3] = {seq0 , begin[1], 0}; ^~~~ libs/locale/src/posix/codecvt.cpp:137:30: note: override this message by inserting an explicit cast char inseq[3] = {seq0 , begin[1], 0}; ^~~~ stat)c_cast<char>( 1 error generated.
I don't see this problem with clang-2.8.
Why clang-3 does not allow code like (I don't have clang-3 to check)?
int main() { unsigned char uc = 10; char c[2] = { uc , 1 }; }
Is this really error, why the compiler does not cast?
... The same error appears several times then
Is this the same error all over?
Can you send me the list of such locations or a patch so I'll be able to commit it to trunk and ask permissions to merge to release branch.
Artyom
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
It's because of initializer lists, are you compiling in c++11 mode? -- Ahmed Charles
Artyom Beilis wrote:
There are some build errors on MAC-OS clang in libraries Locale and Math.
clang-darwin.compile.c++ bin.v2/libs/locale/build/clang-darwin-3.0x/release/threading-multi/posix/codecvt.o libs/locale/src/posix/codecvt.cpp:137:30: error: non-constant-expression cannot be narrowed from type 'unsigned char' to 'char' in initializer list char inseq[3] = {seq0 , begin[1], 0}; ^~~~ libs/locale/src/posix/codecvt.cpp:137:30: note: override this message by inserting an explicit cast char inseq[3] = {seq0 , begin[1], 0}; ^~~~ stat)c_cast<char>( 1 error generated.
I don't see this problem with clang-2.8.
Why clang-3 does not allow code like (I don't have clang-3 to check)?
int main() { unsigned char uc = 10; char c[2] = { uc , 1 }; }
Is this really error, why the compiler does not cast?
I don't know. The same error appears with clang-2.9 c++03 or c++11 mode.
... The same error appears several times then
Is this the same error all over?
The locale error occurred just once. It was the Math error that appeared several times. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/1-48-0-Beta-1-release-candidates-availabl... Sent from the Boost - Dev mailing list archive at Nabble.com.
Ok I'll take a look on it ASAP. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ --- On Thu, 10/27/11, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
From: Vicente Botet <vicente.botet@wanadoo.fr> Subject: Re: [boost] [1.48.0] Beta 1 release candidates available To: boost@lists.boost.org Date: Thursday, October 27, 2011, 10:18 PM
Artyom Beilis wrote:
There are some build errors on MAC-OS clang in
libraries Locale and Math.
clang-darwin.compile.c++
bin.v2/libs/locale/build/clang-darwin-3.0x/release/threading-multi/posix/codecvt.o
libs/locale/src/posix/codecvt.cpp:137:30: error: non-constant-expression cannot be narrowed from type 'unsigned char' to 'char' in initializer list char inseq[3] = {seq0 , begin[1], 0};
^~~~
libs/locale/src/posix/codecvt.cpp:137:30: note: override this message by inserting an explicit cast char inseq[3] = {seq0 , begin[1], 0};
^~~~
stat)c_cast<char>( 1 error generated.
I don't see this problem with clang-2.8.
Why clang-3 does not allow code like (I don't have clang-3 to check)?
int main() { unsigned char uc = 10; char c[2] = { uc , 1 }; }
Is this really error, why the compiler does not cast?
I don't know. The same error appears with clang-2.9 c++03 or c++11 mode.
... The same error appears several times then
Is this the same error all over?
The locale error occurred just once. It was the Math error that appeared several times.
Best, Vicente
On Wed, Oct 26, 2011 at 9:22 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 26/10/11 15:41, Beman Dawes a écrit :
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
This helps ensure the candidates build OK before we push them out to SourceForge.
Hi,
Build Ok in Mac OS gcc 4.1.2.
There are some build errors on MAC-OS clang in libraries Locale and Math.
These aren't showstoppers for the beta, although it would be nice to resolve them before the actual 1.48.0 release. Thanks for the reports, --Beman
On 26 October 2011 14:41, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
I've upload the documentation to the beta site. (Unfinished) release notes are here: http://beta.boost.org/users/history/version_1_48_0.html They're normally linked to from the beta home page, but not at the moment because I'm half way through changing things. There are a couple of broken links where the link is hard-coded to a particular version. I'll look into fixing that later, but for now you can edit the url yourself; replace /1_48_0/ with /1_48_0_beta1/ and it should work.
On Thu, Oct 27, 2011 at 3:50 AM, Daniel James <dnljms@gmail.com> wrote:
On 26 October 2011 14:41, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
I've upload the documentation to the beta site.
(Unfinished) release notes are here:
http://beta.boost.org/users/history/version_1_48_0.html
They're normally linked to from the beta home page, but not at the moment because I'm half way through changing things. There are a couple of broken links where the link is hard-coded to a particular version. I'll look into fixing that later, but for now you can edit the url yourself; replace /1_48_0/ with /1_48_0_beta1/ and it should work.
I noticed the release notes fail to mention anything about Iterator, specifically https://svn.boost.org/trac/boost/ticket/5697 which I filed and provided patches for 3 months ago (with the help of Dave). I don't know if this patch was ever applied, but it'd be great it if it was...! - Jeff
on Thu Oct 27 2011, "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung-AT-gmail.com> wrote:
On Thu, Oct 27, 2011 at 3:50 AM, Daniel James <dnljms@gmail.com> wrote:
On 26 October 2011 14:41, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
I've upload the documentation to the beta site.
(Unfinished) release notes are here:
http://beta.boost.org/users/history/version_1_48_0.html
They're normally linked to from the beta home page, but not at the moment because I'm half way through changing things. There are a couple of broken links where the link is hard-coded to a particular version. I'll look into fixing that later, but for now you can edit the url yourself; replace /1_48_0/ with /1_48_0_beta1/ and it should work.
I noticed the release notes fail to mention anything about Iterator, specifically
https://svn.boost.org/trac/boost/ticket/5697
which I filed and provided patches for 3 months ago (with the help of Dave). I don't know if this patch was ever applied, but it'd be great it if it was...!
I don't think so. Jeff, neither of my co-authors have done any maintenance on this library since it was accepted, and I personally have clearly run out of time. Would you like to consider taking over as maintainer? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Tested on Ubuntu Linux 11.04 Builds OK with gcc-4.4 Failures with clang-2.9 in math library. Just one of the errors: In file included from ./boost/math/special_functions/bessel.hpp:20: ./boost/math/special_functions/detail/bessel_ik.hpp:320:16: error: use of undeclared identifier 'bessel_i_small_z_series' Iv = bessel_i_small_z_series(v, x, pol); ^ In file included from <built-in>:140: In file included from <command line>:5: In file included from /home/antoshkka/Downloads/boost_1_48_0_beta1/libs/math/build/../src/tr1/pch.hpp:9: In file included from ./boost/math/special_functions.hpp:18: ./boost/math/special_functions/bessel.hpp:276:4: note: in instantiation of function template specialization 'boost::math::detail::bessel_ik<long double, boost::math::policies::policy<domain_error<errno_on_error>, pole_error<errno_on_error>, overflow_error<errno_on_error>, evaluation_error<errno_on_error>, rounding_error<errno_on_error>, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> >' requested here bessel_ik(v, x, &I, &K, need_i, pol); ^ ./boost/math/special_functions/bessel.hpp:464:65: note: in instantiation of function template specialization 'boost::math::detail::cyl_bessel_i_imp<long double, boost::math::policies::policy<domain_error<errno_on_error>, pole_error<errno_on_error>, overflow_error<errno_on_error>, evaluation_error<errno_on_error>, rounding_error<errno_on_error>, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> >' requested here return policies::checked_narrowing_cast<result_type, Policy>(detail::cyl_bessel_i_imp<value_type>(v, static_cast<value_type>(x), pol), "boost::math::cyl_bessel_i<%1%>(%1%,%1%)"); ^ In file included from libs/math/build/../src/tr1/cyl_bessel_i.cpp:12: /home/antoshkka/Downloads/boost_1_48_0_beta1/libs/math/build/../src/tr1/c_policy.hpp:129:1: note: in instantiation of function template specialization 'boost::math::cyl_bessel_i<double, double, boost::math::policies::policy<domain_error<errno_on_error>, pole_error<errno_on_error>, overflow_error<errno_on_error>, evaluation_error<errno_on_error>, rounding_error<errno_on_error>, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> >' requested here BOOST_MATH_DECLARE_SPECIAL_FUNCTIONS(c_policy) ^ In file included from <built-in>:140: In file included from <command line>:5: In file included from /home/antoshkka/Downloads/boost_1_48_0_beta1/libs/math/build/../src/tr1/pch.hpp:9: In file included from ./boost/math/special_functions.hpp:15: In file included from ./boost/math/special_functions/acosh.hpp:22: ./boost/math/special_functions/math_fwd.hpp:992:38: note: instantiated from: cyl_bessel_i(T1 v, T2 x) { return boost::math::cyl_bessel_i(v, x, Policy()); }\ ^ libs/math/build/../src/tr1/cyl_bessel_i.cpp:16:11: note: in instantiation of function template specialization 'c_policies::cyl_bessel_i<double, double>' requested here return c_policies::cyl_bessel_i BOOST_PREVENT_MACRO_SUBSTITUTION(nu, x); ^ 1 error generated. More errors in attachment. Best regards, Antony Polukhin
On Fri, Oct 28, 2011 at 4:37 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Oct 27 2011, "Jeffrey Lee Hellrung, Jr." < jeffrey.hellrung-AT-gmail.com> wrote:
On Thu, Oct 27, 2011 at 3:50 AM, Daniel James <dnljms@gmail.com> wrote:
On 26 October 2011 14:41, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
I've upload the documentation to the beta site.
(Unfinished) release notes are here:
http://beta.boost.org/users/history/version_1_48_0.html
They're normally linked to from the beta home page, but not at the moment because I'm half way through changing things. There are a couple of broken links where the link is hard-coded to a particular version. I'll look into fixing that later, but for now you can edit the url yourself; replace /1_48_0/ with /1_48_0_beta1/ and it should work.
I noticed the release notes fail to mention anything about Iterator, specifically
https://svn.boost.org/trac/boost/ticket/5697
which I filed and provided patches for 3 months ago (with the help of Dave). I don't know if this patch was ever applied, but it'd be great it if it was...!
I don't think so. Jeff, neither of my co-authors have done any maintenance on this library since it was accepted, and I personally have clearly run out of time. Would you like to consider taking over as maintainer?
Hmmm...sure, assuming the rest of the community approves and can tolerate an initial "hand-holding" period. Can you point me to any online resources that can me ease me into the whats and hows of maintaining a Boost library? - Jeff
Jeffrey Lee Hellrung, Jr. wrote:
On Fri, Oct 28, 2011 at 4:37 PM, Dave Abrahams <dave@boostpro.com> wrote:
I don't think so. Jeff, neither of my co-authors have done any maintenance on this library since it was accepted, and I personally have clearly run out of time. Would you like to consider taking over as maintainer?
Hmmm...sure, assuming the rest of the community approves and can tolerate an initial "hand-holding" period.
I'm sure that the Boost community will be happy if you become a new maintainer :) Regards, Michel
On Wed, Nov 2, 2011 at 4:16 AM, Michel Morin <mimomorin@gmail.com> wrote:
Jeffrey Lee Hellrung, Jr. wrote:
On Fri, Oct 28, 2011 at 4:37 PM, Dave Abrahams <dave@boostpro.com> wrote:
I don't think so. Jeff, neither of my co-authors have done any maintenance on this library since it was accepted, and I personally have clearly run out of time. Would you like to consider taking over as maintainer?
Hmmm...sure, assuming the rest of the community approves and can tolerate an initial "hand-holding" period.
I'm sure that the Boost community will be happy if you become a new maintainer :)
[A recent post from Dave reminded me of this...] Okay, let's try being more proactive here :) What do I need to do to become the maintainer for Boost.Iterator? I know one thing: As far as I know, I don't have SVN write access to trunk. And I'm somewhat sketchy on the details of the boost development process, but it sounds something like "apply changes to trunk branch, wait for tests to cycle, check test results, and if all looks good, apply changes to release branch". Any details anyone is willing to provide (either via list or via personal email) regarding the development process will be much appreciated. (I'm familiar with SVN as far as add/commit/update is concerned, but not much more.) - Jeff
I'm sure that the Boost community will be happy if you become a new maintainer :)
[A recent post from Dave reminded me of this...]
Okay, let's try being more proactive here :)
What do I need to do to become the maintainer for Boost.Iterator?
I know one thing: As far as I know, I don't have SVN write access to trunk. And I'm somewhat sketchy on the details of the boost development process, but it sounds something like "apply changes to trunk branch, wait for tests to cycle, check test results, and if all looks good, apply changes to release branch". Any details anyone is willing to provide (either via list or via personal email) regarding the development process will be much appreciated. (I'm familiar with SVN as far as add/commit/update is concerned, but not much more.)
If Dave is happy with you taking over, then I can organize SVN privileges for you, Dave? John.
on Fri Dec 16 2011, John Maddock <boost.regex-AT-virgin.net> wrote:
I'm sure that the Boost community will be happy if you become a new
maintainer :)
[A recent post from Dave reminded me of this...]
Okay, let's try being more proactive here :)
What do I need to do to become the maintainer for Boost.Iterator?
I know one thing: As far as I know, I don't have SVN write access to trunk. And I'm somewhat sketchy on the details of the boost development process, but it sounds something like "apply changes to trunk branch, wait for tests to cycle, check test results, and if all looks good, apply changes to release branch". Any details anyone is willing to provide (either via list or via personal email) regarding the development process will be much appreciated. (I'm familiar with SVN as far as add/commit/update is concerned, but not much more.)
If Dave is happy with you taking over, then I can organize SVN privileges for you, Dave?
I'd be very happy with that. Having any maintainer at all is bound to be better than having me with no time to do anything. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Fri, Dec 16, 2011 at 4:38 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Fri Dec 16 2011, John Maddock <boost.regex-AT-virgin.net> wrote:
I'm sure that the Boost community will be happy if you become a new
maintainer :)
[A recent post from Dave reminded me of this...]
Okay, let's try being more proactive here :)
What do I need to do to become the maintainer for Boost.Iterator?
I know one thing: As far as I know, I don't have SVN write access to trunk. And I'm somewhat sketchy on the details of the boost development process, but it sounds something like "apply changes to trunk branch, wait for tests to cycle, check test results, and if all looks good, apply changes to release branch". Any details anyone is willing to provide (either via list or via personal email) regarding the development process will be much appreciated. (I'm familiar with SVN as far as add/commit/update is concerned, but not much more.)
If Dave is happy with you taking over, then I can organize SVN privileges for you, Dave?
I'd be very happy with that. Having any maintainer at all is bound to be better than having me with no time to do anything.
Okay, so, John, what do you need me to do now? - Jeff
Okay, so, John, what do you need me to do now?
Keep nagging me until I do something about it ;-) There's an email invitation on it's way that will give you full developer access - if you can sign up using something like your real name so we can tell whose making what changes that would help too. And finally... let me have your user-id and I'll assign you as iterator lib the maintainer on Trac, if you can then edit libs/maintainers.txt in SVN that would be great. Welcome aboard! John.
On 26.10.2011 15:41, Beman Dawes wrote:
Please report both success and failure, and anything else that is noteworthy.
Hi, the links to the move library (e.g. from the library overview page libs/libraries.htm) seem to be broken, they point to libs/move/index.html, which doesn't exist. Wolfgang
On 27 October 2011 13:50, Wolfgang Fertsak <wolfgang.fertsak@allianz.at> wrote:
On 26.10.2011 15:41, Beman Dawes wrote:
Please report both success and failure, and anything else that is noteworthy.
Hi, the links to the move library (e.g. from the library overview page libs/libraries.htm) seem to be broken, they point to libs/move/index.html, which doesn't exist.
Yes, I've noticed that. I'll fix it in trunk later. The link on the release notes works.
On 26.10.2011 15:41, Beman Dawes wrote:
Please report both success and failure, and anything else that is noteworthy.
In the introduction section of the container library (doc/html/container.html): "flat_map, flat_set, flat_multiset and flat_multiset: drop-in replacements..." - flat_multiset is mentioned twice and flat_multimap isn't mentioned at all. - the 4 underlying links all point to doc/html/boost/container/flat_map.html instead of flat_set =>flat_set.html, flat_multiset => flat_multiset.html etc. Wolfgang
On Wed, 26 Oct 2011 15:41:51 +0200, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
I'm surprised that the fix for https://svn.boost.org/trac/boost/ticket/5944 is not in the beta release. I had asked Sebastian to close this ticket, and he did that before October 10 (which was the deadline for major code changes). The fix is in trunk since October 4 (see https://svn.boost.org/trac/boost/changeset/74691). As the fix was checked in in time and as it's a one line change (OK, two with the #include) I even had contacted Sebastian for, I would appreciate if the beta release is updated. Is it possible that other changes in trunk (checked in before October 10) are missing in this beta release, too? Boris
On 10/27/2011 6:57 PM, Boris Schaeling wrote:
On Wed, 26 Oct 2011 15:41:51 +0200, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
I'm surprised that the fix for https://svn.boost.org/trac/boost/ticket/5944 is not in the beta release. I had asked Sebastian to close this ticket, and he did that before October 10 (which was the deadline for major code changes). The fix is in trunk since October 4 (see https://svn.boost.org/trac/boost/changeset/74691). As the fix was checked in in time and as it's a one line change (OK, two with the #include) I even had contacted Sebastian for, I would appreciate if the beta release is updated.
Is it possible that other changes in trunk (checked in before October 10) are missing in this beta release, too?
Of course it's possible.. Since someone has to do the merging to release. It's not enough to make the changes in trunk. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Thu, Oct 27, 2011 at 8:49 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On 10/27/2011 6:57 PM, Boris Schaeling wrote:
...
I'm surprised that the fix for https://svn.boost.org/trac/boost/ticket/5944 is not in the beta release. I had asked Sebastian to close this ticket, and he did that before October 10 (which was the deadline for major code changes). The fix is in trunk since October 4 (see https://svn.boost.org/trac/boost/changeset/74691). As the fix was checked in in time and as it's a one line change (OK, two with the #include) I even had contacted Sebastian for, I would appreciate if the beta release is updated.
Is it possible that other changes in trunk (checked in before October 10) are missing in this beta release, too?
Of course it's possible.. Since someone has to do the merging to release. It's not enough to make the changes in trunk.
And the "someone" who has to do the merge to release is normally the library maintainer. Since the library maintainer may not be reading this thread, Boris might want to post a new message, with a subject line that begins [property_tree], to increase the likelihood that the problem gets addressed before final release. --Beman
On Fri, 28 Oct 2011 14:04:44 +0200, Beman Dawes <bdawes@acm.org> wrote:
On Thu, Oct 27, 2011 at 8:49 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On 10/27/2011 6:57 PM, Boris Schaeling wrote:
...
I'm surprised that the fix for https://svn.boost.org/trac/boost/ticket/5944 is not in the beta release. I had asked Sebastian to close this ticket, and he did that before October 10 (which was the deadline for major code changes). The fix is in trunk since October 4 (see https://svn.boost.org/trac/boost/changeset/74691). As the fix was checked in in time and as it's a one line change (OK, two with the #include) I even had contacted Sebastian for, I would appreciate if the beta release is updated.
Is it possible that other changes in trunk (checked in before October 10) are missing in this beta release, too?
Of course it's possible.. Since someone has to do the merging to release. It's not enough to make the changes in trunk.
And the "someone" who has to do the merge to release is normally the library maintainer.
Since the library maintainer may not be reading this thread, Boris might want to post a new message, with a subject line that begins [property_tree], to increase the likelihood that the problem gets addressed before final release.
I sent an email to Sebastian. Boris
On Fri, 28 Oct 2011 17:52:33 +0200, Boris Schaeling <boris@highscore.de> wrote:
On Fri, 28 Oct 2011 14:04:44 +0200, Beman Dawes <bdawes@acm.org> wrote:
On Thu, Oct 27, 2011 at 8:49 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On 10/27/2011 6:57 PM, Boris Schaeling wrote:
...
I'm surprised that the fix for https://svn.boost.org/trac/boost/ticket/5944 is not in the beta release. I had asked Sebastian to close this ticket, and he did that before October 10 (which was the deadline for major code changes). The fix is in trunk since October 4 (see https://svn.boost.org/trac/boost/changeset/74691). As the fix was checked in in time and as it's a one line change (OK, two with the #include) I even had contacted Sebastian for, I would appreciate if the beta release is updated.
Is it possible that other changes in trunk (checked in before October 10) are missing in this beta release, too?
Of course it's possible.. Since someone has to do the merging to release. It's not enough to make the changes in trunk.
And the "someone" who has to do the merge to release is normally the library maintainer.
Since the library maintainer may not be reading this thread, Boris might want to post a new message, with a subject line that begins [property_tree], to increase the likelihood that the problem gets addressed before final release.
I sent an email to Sebastian.
Sebastian told me that he has no time to do the merge. That's perfectly fine of course. Looking at the log history I see though that Boost.PropertyTree hasn't been merged since 28 March: None of the changes (four) in trunk after this date were ever shipped. I'm not sure what to do about it as after all Sebastian is the maintainer of Boost.PropertyTree. But it's understandably not satisfying to propose improvements or fix bugs if they are not shipped any time soon. Is there any guideline how often trunk has to be merged to release? Or are there any tools to find out how far release is behind trunk for a Boost library (and to emit a warning for example)? Boris
Beman Dawes wrote:
Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
Mac 10.6 Xcode 3.2.6 gcc 4.2: In compiling our application, upgrading from boost_1_44_0 I get conflicts with MacTypes.h define of nil when compiling cons_fwd.hpp from fusion. Any thoughts? Jeff
participants (21)
-
Adam Merz -
Ahmed Charles -
Antony Polukhin -
Artyom Beilis -
Beman Dawes -
Boris Schaeling -
Daniel James -
Dave Abrahams -
Hartmut Kaiser -
Jeff Flinn -
Jeffrey Lee Hellrung, Jr. -
John Maddock -
Lars Viklund -
Michel Morin -
Olaf van der Spek -
Rene Rivera -
Stephan T. Lavavej -
Vicente Botet -
Vicente J. Botet Escriba
-
Wolfgang Fertsak -
Владислав Щапов