- Boost - lists.preview.boost.org

[numeric] Lack headers for ARM CPU
by christine bouzant 28 Oct '13

28 Oct '13

Hello all, I would need to include the header boost/numeric/interval/hw_rounding.hpp but i see that the ARM CPU is not taken in account. Is someone would have a non official header version for the ARM cpu case ? Thank you! Cheers, Christine

1 0

boost::polygon type genericity
by T. Raykoff 28 Oct '13

28 Oct '13

boost::polygon has a nice facility for generic numeric types for coordinate values via coordinate_traits, etc. But there are a number of places in the library code where a hard-coded type, usually a double, is used instead of referring to the appropriate type in this trait struct. Should this be considered a bug in b::p? Background: I'd like to use a custom class as a type which manages the scaling of real-world decimal coordinates to the integral values that b::p likes to use. I understand the whole thing about snap-rounding to an integral grid and all that, so need to scale up the real-world decimal values to an appropriate grid size. But it makes sense to carry this paradigm through to all of the typedef's in coordinate_traits and high_precision_type, but this is where things break with the hard-coded double's. T -- View this message in context: http://boost.2283326.n4.nabble.com/boost-polygon-type-genericity-tp4651484.… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 10

[1.55] Late release Notes?
by John Maddock 27 Oct '13

27 Oct '13

In order to save my blushes(!), can the following line please be added to the Math lib release notes: * Add improvement to non-central chi squared distribution quantile due to Thomas Luu. Apologies to Thomas for forgetting him! John.

4 5

[git] [conversion] Schedule and remaining showstoppers?
by Beman Dawes 27 Oct '13

27 Oct '13

It seems to me the best time for the svn to modular git changeover is right after a Boost release. That will give us the maximum time window to get the new house in order before the subsequent release. So should we convert right after 1.55 ships? I'm well aware that there is a long list of conversion related tasks that we haven't completed. But the svn -> git conversion process itself is so complex that only Dave and Daniel can make modifications. They have done a staggering amount of work already and are nearing exhaustion. Once the conversion is done, there are many of us that understand git well enough to help with problems. For example, https://github.com/ryppl/Boost2Git/issues/5, "Mimic gitfow", is a showstopper in that what is now "master" should be "develop" and the true "master" (i.e. releases) branch needs to be synthesized. But while it would be great if the Boost2Git process could handle that, it could probably also be do by a post-conversion step performed by git and other command line tools that many of us could help with. Messy, but I'm not willing to take a further delay waiting for perfection. Which of the issues in https://github.com/ryppl/Boost2Git/issues?state=openare true show stoppers? Are there any true showstoppers missing from that list? --Beman

12 45

[git] conversion stalled
by Jürgen Hunold 27 Oct '13

27 Oct '13

Hi! It seems the conversion script is stalled on commit 515f5649bbfb25e2ac89958d700ff2a67fddc030 Date: Fri Sep 13 14:48:17 2013 +0000 There have been some Boost.Build commits in the meantime, can someone please re-enable the conversion again? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

7 15

[winapi] Default target Windows version
by Andrey Semashev 26 Oct '13

26 Oct '13

Hi, First, a little intro. As part of ongoing work on Boost.Sync we've created quite a few headers with WinAPI declarations that are often needed in Boost libraries. The headers are in boost/detail/winapi and can be used by any library that wishes to avoid including windows.h. The headers declare some symbols that depend on the target Windows version. For example, GetTickCount64 only appeared in Windows Vista. The user can define BOOST_USE_WINAPI_VERSION macro before including any Boost headers to indicate the target WinAPI version Boost should use. If the macro is not defined, the headers attempt to deduce the target Windows version from the _WIN32_WINNT and WINVER macros, if they are defined by the user. Lastly, if everything fails, the headers fall back to a default, which is currently Windows XP. I wanted to ask the community if it is appropriate to raise the default to Windows Vista. The rationale for this is that Vista introduced a lot of useful APIs (in thread synchronization, in particular) and XP is losing its popularity and soon will be completely unsupported by Microsoft. Also, I'm not sure what is the current state of affair, but Microsoft already tried to drop pre-Vista targets in MSVC. Note that I'm not suggesting to drop support for pre-Vista Windows. The user will still be able to enable previous versions of WinAPI in one of the mentioned above ways. Lastly, I'd like to encourage Boost developers to use this protocol for defining WinAPI version used by libraries. It would be ideal if by defining BOOST_USE_WINAPI_VERSION the user would be able to control WinAPI version used by all Boost libraries, not just Boost.Sync and Boost.Chrono (the current users of these headers). If you want to add support for this protocol to your library, simply include boost/detail/winapi/config.hpp. This will result in BOOST_USE_WINAPI_VERSION being defined so that it can be checked by the library. Other headers boost/detail/winapi make use of this macro, you can see them as an example.

9 36

Re: [boost] [voronoi]medial axis
by Michael Simbirsky 26 Oct '13

26 Oct '13

Thanks, Andrii, Louis, Like Louis, I try to use Boost.Polygon Voronoi diagram for medial axis computation. Since Voronoi diagram is stored as DCEL, it is not difficult to represent it as a combination of two dual graphs. The "primal" bidirected graph has Voronoi vertices as its vertices and (finite) halfedges as edges. The "dual" graph has Voronoi cells as its vertices; half-edges "connect" adjacent cells. This graph is also bi-directed. I think this understanding of DCEL is rather common; I believe CGAL applies similar approach to provide Boost Graph adapters for its DCEL arrangements. For my purposes I am writing the adapters on my own. Iterator parts are straight-forward. For efficiency it is also useful to convert some internals into "property maps". For example, color map is already provided, one has only to wrap it into boost::property_map with correct access functions. Similarly, the fact that vertices are packed into continuous storage gives us an efficient "vertex to integer" bimap, an important ingredient for many search algorithms from Boost Graph library. As the next step I hope to implement your discussion on vertices connected to infinity, vertices in holes etc.using Boost.Graph. Andrii, I would be glad to share this code with you and Boost.Polygon users. Thanks, -Michael

2 3

[release] Permission to merge after regression cycle
by Vicente J. Botet Escriba 26 Oct '13

26 Oct '13

Hi, I have been fixing some bugs on Boost.Chrono #9274 <https://svn.boost.org/trac/boost/ticket/9274> lost of precission on system_clock input <https://svn.boost.org/trac/boost/ticket/9274> #9276 <https://svn.boost.org/trac/boost/ticket/9276> output from a system_clock::time_point get a time_point that is one day later than expected <https://svn.boost.org/trac/boost/ticket/9276> #9265 <https://svn.boost.org/trac/boost/ticket/9265> time_point_output_h test crashes regression test <https://svn.boost.org/trac/boost/ticket/9265> #8328 <https://svn.boost.org/trac/boost/ticket/8328> chrono crashes visual studio 2012 regression tests <https://svn.boost.org/trac/boost/ticket/8328> The concerned change sets are 19:00 Changeset /[86410]/ by viboes <https://svn.boost.org/trac/boost/changeset/86410> Thread: Try to fix system_clock::time_point output on windows. 18:01 Changeset /[86384]/ by viboes <https://svn.boost.org/trac/boost/changeset/86384> Chrono: try to avoid the crash with msvc 11 on chrono_io. 17:36 Changeset /[86383]/ by viboes <https://svn.boost.org/trac/boost/changeset/86383> Chrono: set precission to 9 so that there is no lost with the hisgest ... 14:27 Changeset /[86376]/ by viboes <https://svn.boost.org/trac/boost/changeset/86376> Chrono: fix two important issues with Boost.Chrono IO v2 on windows * ... 14:54 Changeset /[86357]/ by viboes <https://svn.boost.org/trac/boost/changeset/86357> Chrono: don't run test_good_utc_fmt_system_clock on windows as this is ... I would like to merge these changeset to release. Is it time to do it before releasing boost 1.55? Best, Vicente Patch: svn diff boost/chrono/detail/inlined/win/chrono.hpp boost/chrono/io/time_point_io.hpp libs/chrono/test/io/time_point_output.cpp libs/chrono/example/io_ex1.cpp Index: boost/chrono/detail/inlined/win/chrono.hpp =================================================================== --- boost/chrono/detail/inlined/win/chrono.hpp (revision 86326) +++ boost/chrono/detail/inlined/win/chrono.hpp (working copy) @@ -109,8 +109,11 @@ { ec.clear(); } - return time_point(duration( - (static_cast<__int64>( ft.dwHighDateTime ) << 32) | ft.dwLowDateTime)); + return system_clock::time_point( + system_clock::duration( + ((static_cast<__int64>( ft.dwHighDateTime ) << 32) | ft.dwLowDateTime) + -116444736000000000LL + )); } #endif Index: boost/chrono/io/time_point_io.hpp =================================================================== --- boost/chrono/io/time_point_io.hpp (revision 86326) +++ boost/chrono/io/time_point_io.hpp (working copy) @@ -28,6 +28,7 @@ #include <boost/chrono/clock_string.hpp> #include <boost/chrono/round.hpp> #include <boost/chrono/detail/scan_keyword.hpp> +#include <boost/static_assert.hpp> #include <boost/detail/no_exceptions_support.hpp> #include <cstring> #include <locale> @@ -46,9 +47,11 @@ { namespace chrono { + typedef double fractional_seconds; namespace detail { + template <class CharT, class InputIterator = std::istreambuf_iterator<CharT> > struct time_get { @@ -758,6 +761,7 @@ { 0,31,59,90,120,151,181,212,243,273,304,334}, { 0,31,60,91,121,152,182,213,244,274,305,335} }; + return days[is_leap(year)][month-1] + day - 1; } @@ -779,7 +783,7 @@ month++; int day = t->tm_mday; int day_of_year = days_from_1jan(year,month,day); - int days_since_epoch = days_from_1970(year) + day_of_year; + int days_since_epoch = days_from_1970(year) + day_of_year ; time_t seconds_in_day = 3600 * 24; time_t result = seconds_in_day * days_since_epoch + 3600 * t->tm_hour + 60 * t->tm_min + t->tm_sec; @@ -801,11 +805,36 @@ return y * 365 + y / 4 - y / 100 + y / 400; } + // Returns year/month/day triple in civil calendar + // Preconditions: z is number of days since 1970-01-01 and is in the range: + // [numeric_limits<Int>::min(), numeric_limits<Int>::max()-719468]. + template <class Int> + //constexpr + void + inline civil_from_days(Int z, Int& y, unsigned& m, unsigned& d) BOOST_NOEXCEPT + { + BOOST_STATIC_ASSERT_MSG(std::numeric_limits<unsigned>::digits >= 18, + "This algorithm has not been ported to a 16 bit unsigned integer"); + BOOST_STATIC_ASSERT_MSG(std::numeric_limits<Int>::digits >= 20, + "This algorithm has not been ported to a 16 bit signed integer"); + z += 719468; + const Int era = (z >= 0 ? z : z - 146096) / 146097; + const unsigned doe = static_cast<unsigned>(z - era * 146097); // [0, 146096] + const unsigned yoe = (doe - doe/1460 + doe/36524 - doe/146096) / 365; // [0, 399] + y = static_cast<Int>(yoe) + era * 400; + const unsigned doy = doe - (365*yoe + yoe/4 - yoe/100); // [0, 365] + const unsigned mp = (5*doy + 2)/153; // [0, 11] + d = doy - (153*mp+2)/5 + 1; // [1, 31] + m = mp + (mp < 10 ? 3 : -9); // [1, 12] + y += (m <= 2); + --m; + } inline std::tm * internal_gmtime(std::time_t const* t, std::tm *tm) { if (t==0) return 0; if (tm==0) return 0; +#if 0 static const unsigned char day_of_year_month[2][366] = { @@ -820,6 +849,7 @@ { -1, 30, 58, 89, 119, 150, 180, 211, 242, 272, 303, 333, 364 }, { -1, 30, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365 } }; +#endif const time_t seconds_in_day = 3600 * 24; int32_t days_since_epoch = static_cast<int32_t>(*t / seconds_in_day); @@ -829,6 +859,7 @@ hms = seconds_in_day+hms; } +#if 0 int32_t x = days_since_epoch; int32_t y = static_cast<int32_t> (static_cast<long long> (x + 2) * 400 / 146097); @@ -843,16 +874,23 @@ //y -= 32767 + 2; y += 70; tm->tm_year=y; - const bool leap = is_leap(y); + const int32_t leap = is_leap(y); tm->tm_mon = day_of_year_month[leap][doy]-1; - tm->tm_mday = doy - days_in_year_before[leap][day_of_year_month[leap][doy] - 1]; + tm->tm_mday = doy - days_in_year_before[leap][tm->tm_mon] ; +#else + int32_t y; + unsigned m, d; + civil_from_days(days_since_epoch, y, m, d); + tm->tm_year=y-1900; tm->tm_mon=m; tm->tm_mday=d; +#endif - tm->tm_hour = hms / 3600; const int ms = hms % 3600; tm->tm_min = ms / 60; tm->tm_sec = ms % 60; + tm->tm_isdst = -1; + (void)mktime(tm); return tm; } @@ -907,6 +945,9 @@ tm = *tmp; #else if (gmtime_r(&t, &tm) == 0) failed = true; + tm.tm_isdst = -1; + (void)mktime(&tm); + #endif } @@ -922,7 +963,7 @@ failed = tpf.put(os, os, os.fill(), &tm, pb, pe).failed(); if (!failed) { - duration<double> d = tp - system_clock::from_time_t(t) + seconds(tm.tm_sec); + duration<fractional_seconds> d = tp - system_clock::from_time_t(t) + seconds(tm.tm_sec); if (d.count() < 10) os << CharT('0'); //if (! os.good()) { // throw "exception"; @@ -932,6 +973,7 @@ //if (! os.good()) { //throw "exception"; //} + os.precision(9); os << d.count(); //if (! os.good()) { //throw "exception"; @@ -1058,12 +1100,8 @@ const std::time_get<CharT>& tg = std::use_facet<std::time_get<CharT> >(loc); const std::ctype<CharT>& ct = std::use_facet<std::ctype<CharT> >(loc); tm tm; // {0} - tm.tm_year=0; - tm.tm_mon=0; - tm.tm_mday=0; - tm.tm_hour=0; - tm.tm_min=0; - tm.tm_sec=0; + std::memset(&tm, 0, sizeof(std::tm)); + typedef std::istreambuf_iterator<CharT, Traits> It; if (pb == pe) { @@ -1079,9 +1117,13 @@ tg.get(is, 0, is, err, &tm, pb, pe); #endif if (err & std::ios_base::failbit) goto exit; - double sec; + fractional_seconds sec; CharT c = CharT(); + std::ios::fmtflags flgs = is.flags(); + is.setf(std::ios::fixed, std::ios::floatfield); + is.precision(9); is >> sec; + is.flags(flgs); if (is.fail()) { err |= std::ios_base::failbit; @@ -1099,13 +1141,14 @@ if (err & std::ios_base::failbit) goto exit; time_t t; + #if BOOST_CHRONO_INTERNAL_TIMEGM t = detail::internal_timegm(&tm); #else t = timegm(&tm); #endif tp = time_point_cast<Duration>( - system_clock::from_time_t(t) - min + round<microseconds> (duration<double> (sec)) + system_clock::from_time_t(t) - min + round<system_clock::duration> (duration<fractional_seconds> (sec)) ); } else Index: libs/chrono/test/io/time_point_output.cpp =================================================================== --- libs/chrono/test/io/time_point_output.cpp (revision 86326) +++ libs/chrono/test/io/time_point_output.cpp (working copy) @@ -148,68 +148,102 @@ using namespace boost::chrono; using namespace boost; - test_good_system_clock("1970-01-01 02:00:00.000000 +0000", hours(2), duration_style::prefix); - test_good_system_clock("1970-01-01 02:00:00.000000 +0000", hours(2), duration_style::symbol); + test_good_system_clock("1970-01-01 02:00:00.000000000 +0000", hours(2), duration_style::prefix); + test_good_system_clock("1970-01-01 02:00:00.000000000 +0000", hours(2), duration_style::symbol); - test_good_prefix_system_clock("1970-01-01 02:00:00.000000 +0000", hours(2)); - test_good_prefix_system_clock("1970-01-01 00:02:00.000000 +0000", minutes(2)); - test_good_prefix_system_clock("1970-01-01 00:00:02.000000 +0000", seconds(2)); - test_good_prefix_system_clock("1970-01-01 00:00:01.000000 +0000", seconds(1)); - test_good_prefix_system_clock("1969-12-31 23:59:59.000000 +0000", seconds(-1)); - test_good_prefix_system_clock("1970-01-01 00:00:00.000000 +0000", seconds(0)); - test_good_prefix_system_clock("1970-01-01 00:00:00.002000 +0000", milliseconds(2)); - test_good_prefix_system_clock("1970-01-01 00:00:00.000002 +0000", microseconds(2)); - test_good_prefix_system_clock("1970-01-01 00:00:00.000000 +0000", nanoseconds(2)); - test_good_prefix_system_clock("1970-01-01 00:00:00.200000 +0000", duration<boost::int_least64_t, deci> (2)); - test_good_prefix_system_clock("1970-01-01 00:00:00.066667 +0000", duration<boost::int_least64_t, ratio<1, 30> > (2)); + test_good_prefix_system_clock("1970-01-01 02:00:00.000000000 +0000", hours(2)); + test_good_prefix_system_clock("1970-01-01 00:02:00.000000000 +0000", minutes(2)); + test_good_prefix_system_clock("1970-01-01 00:00:02.000000000 +0000", seconds(2)); + test_good_prefix_system_clock("1970-01-01 00:00:01.000000000 +0000", seconds(1)); + test_good_prefix_system_clock("1969-12-31 23:59:59.000000000 +0000", seconds(-1)); + test_good_prefix_system_clock("1970-01-01 00:00:00.000000000 +0000", seconds(0)); + test_good_prefix_system_clock("1970-01-01 00:00:00.002000000 +0000", milliseconds(2)); + test_good_prefix_system_clock("1970-01-01 00:00:00.000002000 +0000", microseconds(2)); + test_good_prefix_system_clock("1970-01-01 00:00:00.000000002 +0000", nanoseconds(2)); + test_good_prefix_system_clock("1970-01-01 00:00:00.200000000 +0000", duration<boost::int_least64_t, deci> (2)); + test_good_prefix_system_clock("1970-01-01 00:00:00.066666667 +0000", duration<boost::int_least64_t, ratio<1, 30> > (2)); - test_good_symbol_system_clock("1970-01-01 02:00:00.000000 +0000", hours(2)); - test_good_symbol_system_clock("1970-01-01 00:02:00.000000 +0000", minutes(2)); - test_good_symbol_system_clock("1970-01-01 00:00:02.000000 +0000", seconds(2)); - test_good_symbol_system_clock("1970-01-01 00:00:00.002000 +0000", milliseconds(2)); - test_good_symbol_system_clock("1970-01-01 00:00:00.000000 +0000", nanoseconds(2)); - test_good_symbol_system_clock("1970-01-01 00:00:00.200000 +0000", duration<boost::int_least64_t, deci> (2)); - test_good_symbol_system_clock("1970-01-01 00:00:00.066667 +0000", duration<boost::int_least64_t, ratio<1, 30> > (2)); + test_good_symbol_system_clock("1970-01-01 02:00:00.000000000 +0000", hours(2)); + test_good_symbol_system_clock("1970-01-01 00:02:00.000000000 +0000", minutes(2)); + test_good_symbol_system_clock("1970-01-01 00:00:02.000000000 +0000", seconds(2)); + test_good_symbol_system_clock("1970-01-01 00:00:00.002000000 +0000", milliseconds(2)); + test_good_symbol_system_clock("1970-01-01 00:00:00.000000002 +0000", nanoseconds(2)); + test_good_symbol_system_clock("1970-01-01 00:00:00.200000000 +0000", duration<boost::int_least64_t, deci> (2)); + test_good_symbol_system_clock("1970-01-01 00:00:00.066666667 +0000", duration<boost::int_least64_t, ratio<1, 30> > (2)); test_good_utc_fmt_system_clock("1970-01-01 02:00:00", "%Y-%m-%d %H:%M:%S", hours(2)); test_good_utc_fmt_system_clock("1970-01-01 02", "%Y-%m-%d %H", hours(2)); - +#if ! defined(BOOST_CHRONO_WINDOWS_API) test_good_utc_fmt_system_clock ("1970-01-01 02:00:00", "%Y-%m-%d %T", hours(2)); test_good_utc_fmt_system_clock ("1970-01-01 02:00", "%Y-%m-%d %R", hours(2)); test_good_utc_fmt_system_clock ("% 1970-01-01 02:00", "%% %Y-%m-%d %R", hours(2)); test_good_utc_fmt_system_clock ("1970-01-01 02:00 Thursday January", "%Y-%m-%d %R %A %B", hours(2)); - +#endif } + +#endif +#if BOOST_CHRONO_VERSION == 2 void test_gmtime(std::time_t t) { std::cout << "t " << t << std::endl; + puts(ctime(&t)); std::tm tm; + std::memset(&tm, 0, sizeof(std::tm)); if (boost::chrono::detail::internal_gmtime(&t, &tm)) { - std::cout << "year " << tm.tm_year << std::endl; - std::cout << "month " << tm.tm_mon << std::endl; - std::cout << "day " << tm.tm_mday << std::endl; - std::cout << "hour " << tm.tm_hour << std::endl; - std::cout << "min " << tm.tm_min << std::endl; - std::cout << "sec " << tm.tm_sec << std::endl; + tm.tm_isdst = -1; + (void)mktime(&tm); + std::tm tm2; + std::memset(&tm2, 0, sizeof(std::tm)); + if (gmtime_r(&t, &tm2)) + { + tm2.tm_isdst = -1; + (void)mktime(&tm2); + + BOOST_TEST_EQ( tm.tm_year , tm2.tm_year ); + BOOST_TEST_EQ( tm.tm_mon , tm2.tm_mon ); + BOOST_TEST_EQ( tm.tm_mday , tm2.tm_mday ); + BOOST_TEST_EQ( tm.tm_hour , tm2.tm_hour); + BOOST_TEST_EQ( tm.tm_min , tm2.tm_min ); + BOOST_TEST_EQ( tm.tm_sec , tm2.tm_sec ); + BOOST_TEST_EQ( tm.tm_wday , tm2.tm_wday ); + BOOST_TEST_EQ( tm.tm_yday , tm2.tm_yday ); + BOOST_TEST_EQ( tm.tm_isdst , tm2.tm_isdst ); + } } + } #endif + int main() { -// test_gmtime( 0 ); -// test_gmtime( -1 ); -// test_gmtime( +1 ); -// test_gmtime( 0 - (3600 * 24) ); -// test_gmtime( -1 - (3600 * 24) ); -// test_gmtime( +1 - (3600 * 24) ); -// test_gmtime( 0 + (3600 * 24) ); -// test_gmtime( -1 + (3600 * 24) ); -// test_gmtime( +1 + (3600 * 24) ); +#if BOOST_CHRONO_VERSION == 2 + test_gmtime( 0 ); + test_gmtime( -1 ); + test_gmtime( +1 ); + test_gmtime( 0 - (3600 * 24) ); + test_gmtime( -1 - (3600 * 24) ); + test_gmtime( +1 - (3600 * 24) ); + test_gmtime( 0 + (3600 * 24) ); + test_gmtime( -1 + (3600 * 24) ); + test_gmtime( +1 + (3600 * 24) ); + test_gmtime( 0 + 365*(3600 * 24) ); + test_gmtime( 0 + 10LL*365*(3600 * 24) ); + test_gmtime( 0 + 15LL*365*(3600 * 24) ); + test_gmtime( 0 + 17LL*365*(3600 * 24) ); + test_gmtime( 0 + 18LL*365*(3600 * 24) ); + test_gmtime( 0 + 19LL*365*(3600 * 24) ); + test_gmtime( 0 + 19LL*365*(3600 * 24)+ (3600 * 24)); + test_gmtime( 0 + 19LL*365*(3600 * 24)+ 3*(3600 * 24)); + test_gmtime( 0 + 19LL*365*(3600 * 24)+ 4*(3600 * 24)); + test_gmtime( 0 + 20LL*365*(3600 * 24) ); + test_gmtime( 0 + 40LL*365*(3600 * 24) ); +#endif + std::cout << "high_resolution_clock=" << std::endl; check_all<boost::chrono::high_resolution_clock> (); #ifdef BOOST_CHRONO_HAS_CLOCK_STEADY @@ -239,6 +273,13 @@ check_all<boost::chrono::process_cpu_clock> (); #endif +#if BOOST_CHRONO_VERSION == 2 + boost::chrono::system_clock::time_point tp = boost::chrono::system_clock::now(); + std::cout << tp << std::endl; + time_t t = boost::chrono::system_clock::to_time_t(tp); + test_gmtime( t ); +#endif + return boost::report_errors(); } Index: libs/chrono/example/io_ex1.cpp =================================================================== --- libs/chrono/example/io_ex1.cpp (revision 86326) +++ libs/chrono/example/io_ex1.cpp (working copy) @@ -53,10 +53,13 @@ << ClockTick(3) + nanoseconds(10) << '\n'; cout << "\nsystem_clock::now() = " << system_clock::now() << '\n'; +#if defined _MSC_VER && _MSC_VER == 1700 +#else #if BOOST_CHRONO_VERSION==2 cout << "\nsystem_clock::now() = " << time_fmt(chrono::timezone::local) << system_clock::now() << '\n'; cout << "\nsystem_clock::now() = " << time_fmt(chrono::timezone::local,"%Y/%m/%d") << system_clock::now() << '\n'; #endif +#endif #ifdef BOOST_CHRONO_HAS_CLOCK_STEADY cout << "steady_clock::now() = " << steady_clock::now() << '\n';

3 4

[type traits] Removal of files broke regression tests
by Beman Dawes 26 Oct '13

26 Oct '13

r68300 removed boost/type_traits/broken_compiler_spec.hpp and boost/type_traits/transform_traits_spec.hpp. Removing the first broke regression tests for iterator, python, and serialization. Removing the second doesn't appear to have done any harm. John Maddock did the r68300 commit. I'm assuming it was in response to Steve Kelly's r86250, "Remove use of obsolete BOOST_TT_BROKEN_COMPILER_SPEC", so the fix may be to remove the #includes that are causing all the errors rather than restoring the file. --Beman

2 1

[fusion] flatten/flatten_view Proposal
by TONGARI J 25 Oct '13

25 Oct '13

Hi there, I've created the ticket, doc&test included https://svn.boost.org/trac/boost/ticket/9294 'flatten' is an algorithm which returns a view that allows you to go through the leaf elems sequentially. For example: flatten(make_vector(1, make_vector(2, 3))) == make_vector(1, 2, 3) This is developed when I use Fusion to work with SQL for simple data mapping. In addition to 'flatten', 'support/ref' is also provided in this patch for working with mutable sequence, which I had talked with Joel sometime ago. BTW, I think the ticket below is OK to close (the patch seem applied): https://svn.boost.org/trac/boost/ticket/8270 Thanks,

2 7

[config] A few headers moved from detail into config module
by Daniel James 25 Oct '13

25 Oct '13

Hi, In case you missed it on the other thread, a few headers have been moved to the config module from detail: boost/version.hpp boost/limits.hpp boost/detail/workaround.hpp Hopefully that isn't a controversial move, but if any of these are a problem, it's just a case of reverting the appropriate changeset in Boost2Git. You can see them at: https://github.com/ryppl/Boost2Git/commits/master Daniel

1 0

[Numeric] Lack Numeric/interval headers for ARM CPU
by christine bouzant 25 Oct '13

25 Oct '13

Hello all, I would need to include the header boost/numeric/interval/hw_rounding.hpp but i see that the ARM CPU is not taken in account. Is someone would have a non official header version for the ARM cpu case ? Thank you! Cheers, Christine

1 0

storing intrusive_ptr in atomic?!
by Oliver Kowalke 25 Oct '13

25 Oct '13

Hello, do you confirm that it is valid to store a intrusive_ptr inside an atomic?! struct X { std::size_t use_count; X() : use_count( 0) {} friend inline void intrusive_ptr_add_ref( X * p) BOOST_NOEXCEPT { ++p->use_count; } friend inline void intrusive_ptr_release( X * p) { if ( 0 == --p->use_count) delete p; } }; X::ptr_t x1( new X() ); X::ptr_t x2( new X() ); boost::atomic< X::ptr_t > av1( x1); BOOST_ASSERT( av1.compare_exchange_strong( x1, x2) ); BOOST_ASSERT( av1.load() != x1); BOOST_ASSERT( av1.load() == x2); A type T used in generic template atomic<T> is required to be trivial copy-able, e.g. I think it is trivial copy-able (std::memcpy) only the use_count will not incremented. The memory layout of intrusive_ptr is a raw-pointer so trivial copy-able should be correct. What do you think? Oliver

4 26

[git] creation of .gitignores
by Jürgen Hunold 25 Oct '13

25 Oct '13

Hi, the converted repository is missing .gitignores. svn provides the ignores patterns in the "svn:ignore" property. The question is: Can those patterns be extracted by the conversion script or shall manually create .gitignores in current svn (patch attached). The third option is to add them after the conversion. Adding (and modifying) the .gitignores during the conversion has the advantage of having .gitignores throughout the whole history instead of only "now". Any comments? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

3 2

[git help] Documenting common modular boost workflows
by Beman Dawes 25 Oct '13

25 Oct '13

I think we need to document simple suggested modular boost workflows. Each workflow could start with the assumption that the steps described in https://svn.boost.org/trac/boost/wiki/TryModBoost have been completed. Workflows might include: 1) Switch to the "develop" branch, fix a minor problem, test, commit, switch back to "master". 2) Same as (1) but also push to remote. 3) Same as (2) but also merge develop to master. 4) Same as (3) but end by submitting a pull request to the boost super-project. I don't mind writing the actual wiki pages, but am a little hobbled by being a TortoiseGit rather than command line git user, and by never having worked with sub-modules. So what would recommended git commands look like for one or more of the above workflows? Thanks, --Beman

12 30

[utility][enable_if] Documentation issue
by Agustín K-ballo Bergé 25 Oct '13

25 Oct '13

The documentation for `enable_if` has a duplicated anchor for sections 3.1 and 3.2, making it impossible to link to section 3.2 directly. See http://www.boost.org/libs/utility/enable_if.html#htoc7 This issue is still present in trunk. Could this be fixed? I could provide a patch but I do not see a .qbk file for it, should the html be modified directly? Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

2 2

[Type_Traits] [remove_bounds]: Wrong workaround for IBM C++ compiler is applied in remove_bounds.hpp
by Kilian Kilger 24 Oct '13

24 Oct '13

Hi, in remove_bounds.hpp, a wrong workaround for the IBM C++ compiler is applied. This workaround is only valid for IBM C++ on AIX, but wrong for IBM C++ on z/OS. The z/OS compiler has no bug and thus no workaround must be applied (else we get wrong results). So instead of testing against __IBMCPP__ one should also test against __MVS__. This last macro is only defined for IBM C++ on z/OS. I wanted to open a ticket on trac, but this system did always identify my posting as spam. Best regards, Kilian.

4 11

[1.55 beta][serialization] VS2013 boost/archive/iterators/transform_width.hpp(151) : error C2039: 'min'
by Jeff Flinn 24 Oct '13

24 Oct '13

This is ticket #9279/#8750. Just checking that this gets into the release. Is that the case? Thanks, Jeff

1 0

[functors] proposal
by Piotr Wygocki 24 Oct '13

24 Oct '13

Hi, I've developed a small set of functors and functor adaptors. Although this code is very simple it might be very useful for some subset of the community. Do you think it might become a part of the boost library? If not I'm still very interested in any feedback. I think it's not big enough to be a separate library. To my knowledge of boost it fits in the utility lib. The code can be found here: https://github.com/wygos/functors List of utilities: SkipFunctor takes any number of arguments; does completely nothing ReturnSomethingFunctor<T,t> takes any number of arguments; returns t; IdentityFunctor takes one parameter and returns it. ReturnFalseFunctor takes any number of arguments; returns false; ReturnTrueFunctor takes any number of arguments; returns true; ReturnZeroFunctor takes any number of arguments; returns 0; AssertFunctor takes any number of arguments; asserts; ArrayToFunctor<Array> Stores an object which provides operator[]. Provides operator()(). A set of non-template comparison functors (only operator() is templated): * Greater * Less * GreaterEqual * LessEqual * EqualTo * NotEqualTo FunctorToComparator<Functor, Compare> This comparator takes a functor "f" and a comparator "c". For elements (x,y) it returns c(f(x), f(y)) c is Less by default FunctorToOutputIterator<Functor> The output iterator stores a functor and each time the operator= is called the given functor is called Logical operators as functors: * Not * Or * And * Xor LiftBinaryOperatorFunctor<Operator, FunctorLeft, FunctorRight> Functor stores a binary operator "o" and two functors "f" and "g". For given arguments args returns o(f(args), g(args)). Boolean functor adapters. Each of them stores a boolean functor and performs an appropriate logical operation in the operator(). * NotFunctor<Functor> * OrFunctor<FunctorLeft, FunctorRight> * AndFunctor<FunctorLeft, FunctorRight> * XorFunctor<FunctorLeft, FunctorRight> Regards, Piotr

5 12

[boost-testing] something broke my tester(lazypiranha)
by Michael Mathews 24 Oct '13

24 Oct '13

Hi Folks, starting with last nights run my tester has been failing with : File "/home/michael/boost_testing/tools_regression_src/regression.py", line 329, in command_test self.command_test_boost_build() File "/home/michael/boost_testing/tools_regression_src/regression.py", line 369, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/home/michael/boost_testing/results/boost/bin.v2/libs/any/test/any_test.test' Is there an easy an easy way for me to determine the missing test? thanks michael

1 0

NT2 and Boost.SIMD beta 2 available
by Joel Falcou 23 Oct '13

23 Oct '13

This following releases updates NT2 and Boost.SIMD libraries.10 months had past and 176 Issues have been closed since last beta release and more than 2000 commits have been issued. Boost.SIMD is heading toward API stability. We want to tackle ons ome more compile time issues before going for an actual Boost Review. Special thanks to Tim Blenchmann and Domagoj Saric for their help and suggestions throughout this development. The release Changelog is here : https://github.com/MetaScale/nt2/releases The files can be download from : http://nt2.metascale.org/downloads/ The Documentation (in progress) is here : http://nt2.metascale.org/doc/html/index.html

4 4

[1.55][Math] Are we still open to patches?
by John Maddock 23 Oct '13

23 Oct '13

Are we still open for patches for 1.55? If so I'd like to merge the patch for the issue raised here: http://boost.2283326.n4.nabble.com/Boost-1-54-0-boost-math-sph-bessel-n-x-c… now that the tests on Trunk have cycled. Thanks, John.

2 1

[website] Redirection to latest documentation
by Laurent Dupuy 23 Oct '13

23 Oct '13

Hello all, Would it be possible for the webmaster(s) to add a redirection (a symbolic link or whatever) to the latest documentation? Until recently, the URL http://www.boost.org/doc/libs/ did the job, but it does not anymore. Thanks! -- Laurent Dupuy.

2 1

Boost.Build commit heads up
by Beman Dawes 23 Oct '13

23 Oct '13

Here is the commit message for revision 86392: Add Boost.Build support for the Git modular layout, using links to to new header locations, thus preventing breakage to vast amounts of user code and build setups. Being added to SVN so that changes will automatically propagate to Git and modular Boost. Thanks to Steven Watanabe, Jürgen Hunold, Vladimir Prus, and Bjørn Roald for developing this patch. Steven in particular conceived the approach and did the initial implementation, which was further refined by the other contributors. In theory this commit won't break any existing boost builds. To verify that, on Win 7 and Ubunto I've done a fresh SVN checkout of trunk and verified bootstrap.bat, bootstrap.sh, and a b2 build work both before and after the patch is applied. On Windows, I verified that after the patch is applied a b2 build using an unpatched prior compilation of b2 still works. These tests increase confidence that committing the patch to trunk now isn't likely to cause breakage, but please post to this list right away if you spot any build breakage or other odd behavior. The files modified are listed below. Thanks, --Beman Modified: D:\boost\trunk\Jamroot Modified: D:\boost\trunk\libs\geometry\index\example\Jamfile.v2 Modified: D:\boost\trunk\libs\numeric\odeint\examples\vexcl\Jamfile.v2 Modified: D:\boost\trunk\libs\parameter\doc\html\index.html Modified: D:\boost\trunk\libs\parameter\doc\index.rst Modified: D:\boost\trunk\libs\python\example\Jamroot Modified: D:\boost\trunk\libs\python\example\quickstart\Jamroot Modified: D:\boost\trunk\libs\python\example\tutorial\Jamroot Modified: D:\boost\trunk\libs\signals2\example\Jamfile.v2 Modified: D:\boost\trunk\libs\spirit\example\qi\json\build\Jamfile Modified: D:\boost\trunk\libs\units\test\Jamfile.v2 Modified: D:\boost\trunk\tools\Jamfile.v2 Modified: D:\boost\trunk\tools\regression\build\Jamroot.jam

5 6

Re: [boost] [git help] Documenting common modular boost workflows
by Daryle Walker 23 Oct '13

23 Oct '13

Since a project that’s made of a bunch of sub-repositories that’s later merged is (AFAIK) unusual, I don’t think the writer of gitflow had it in mind. I’m guessing that each sub-repository independently uses gitflow. When it’s shipping time, the release-merge script grabs from the “master” branch of each sub-repository. Of course, this doesn’t cover multiple libraries that have to work together or what happens when fixing is necessary (probably due to cross-library problems). And do the test runners work off “develop,” “master,” “release,” or does it shift depending where we are in the release cycle? Sent from Windows Mail From: Peter Dimov Sent: ‎Monday‎, ‎October‎ ‎21‎, ‎2013 ‎10‎:‎16‎ ‎AM To: Boost Dev-List Dave Abrahams wrote: > IIUC we already agreed long ago to use gitflow: It's not entirely clear to me what using gitflow would mean in the context of a Boost superproject with per-library submodules. Who is "we" who would be using gitflow, the Boost release managers or the library maintainers? When Boost release 1.64.0 is started, who is going to create the gitflow release branch, and from what? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 4