March 2020 - Boost - lists.preview.boost.org

[parameter][1.73] Library broken and unattended. Regressions and unmerged PR.
by Andrey Semashev 22 Mar '20

22 Mar '20

Hi, I'd like to draw attention to Boost.Parameter state. Since 1.71, it seems to be broken as described in these issues: https://github.com/boostorg/parameter/issues/91 https://github.com/boostorg/parameter/issues/97 The latter one was actually reported to me in Boost.Log, as this Boost.Parameter bug affected its users in a rather nasty way (the user's code silently compiles and has the wrong effect). For the latter issue I created a PR with a fix: https://github.com/boostorg/parameter/pull/99 which got no reply so far. The person who assumed Boost.Parameter maintenance and made the problematic changes, Cromwell D. Enage, is not responding, so the library is basically broken and unmaintained. I really don't want 1.73 to be released with a bug like the one affected Boost.Log, so I would appreciate if someone with merge permissions could merge my PR. If not, I will be forced to fork the library internally in Boost.Log for 1.73 (which I also really don't want to do). This would take care of my immediate concern. The other issue seems to be affecting users as well and I don't have the solution for it. Given that the library is unmaintained, it might be better to: 1. Move the current state of develop to a separate branch. 2. Revert master and develop to a state prior to Cromwell's commits that went into 1.71 (i.e. to the 1.70 state). This should take care of the Boost.Log issue as well, so it would be fine with me as well. Thanks.

2 2

github pull request process on non-owned submodule
by Jeff Garland 22 Mar '20

22 Mar '20

Sorry if this is obviously documented somewhere, but searches of mailing list aren't helping. I'm looking to submit a pull request for the icl library to remove dependencies on date_time compiled library -- in conjunction with changes to date_time on develop now. I've basically followed the cheat sheet on the wiki: https://github.com/boostorg/wiki/wiki/Getting-Started%3A-Cheat-Sheet but when I try to push my branch I get permission errors. Is there something I did wrong or is the icl repo setup wrong? Thx, Jeff jeff@jeff-mint193:~/dev/boost/libs/icl$ git push origin dt_nolib Username for 'https://github.com': JeffGarland Password for 'https://JeffGarland@github.com': remote: Permission to boostorg/icl.git denied to JeffGarland. fatal: unable to access 'https://github.com/boostorg/icl.git/': The requested URL returned error: 403

2 2

Fwd: Projects for GSoC 2020
by degski 20 Mar '20

20 Mar '20

---------- Forwarded message --------- From: degski <degski(a)gmail.com> Date: Sun, 1 Mar 2020 at 17:00 Subject: Re: [boost] Projects for GSoC 2020 To: David Bellot <david.bellot(a)gmail.com> Yes. On Sun, 1 Mar 2020 at 04:26, David Bellot <david.bellot(a)gmail.com> wrote: > It sounds a good idea to me. Would you like to propose a project and be a > mentor? > It would be great! > > David > > On Thu, Feb 27, 2020 at 8:19 AM degski via Boost <boost(a)lists.boost.org> > wrote: > >> On Wed, 26 Feb 2020 at 14:39, David Bellot via Boost < >> boost(a)lists.boost.org> >> wrote: >> >> > Hi Boost community, >> > >> > so far we received a few good contributions for projects for GSoC 2020. >> The >> > proposals are from our usual mentors but I'm surprised we don't have >> more >> > projects in data structures and algorithms. Most of what we have concern >> > numerical problems. It's great but I wish to see more diversity in the >> type >> > of projects we propose. >> > >> >> Maybe the suggestions put forward do solicit few 'other' proposals. For >> containers, f.e. there are many 'entertaining' and useful things to >> consider, segment tree, spaghetti stack, trie, binary index tree, beap, >> kd-tree, bkd-tree, disjoint-set, n-ary tree, etc etc, etc. >> https://www.geeksforgeeks.org/advanced-data-structures/ presents many >> different data structures, there also a section on algos. >> >> degski >> -- >> @realdegski >> https://brave.com/google-gdpr-workaround/ >> "We value your privacy, click here!" Sod off! - degski >> "Anyone who believes that exponential growth can go on forever in a finite >> world is either a madman or an economist" - Kenneth E. Boulding >> "Growth for the sake of growth is the ideology of the cancer cell" - >> Edward >> P. Abbey >> >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > -- @realdegski https://brave.com/google-gdpr-workaround/ "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey -- @realdegski https://brave.com/google-gdpr-workaround/ "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

3 7

binomial distribution setter function
by Kemin Zhou 18 Mar '20

18 Mar '20

This is my first time posting in this mailing list. Not sure how to post to the developer only mailing list after reading the document for mailing list for a good half an hour. If I posted in he wrong mailing please let me know and kindly provide the developer mailing list. I am looking at the binomial.hpp file. I need to use the binomial object in a loop which requires to have high performance. I am thinking constructing the binomial object each time in the loop would be less efficient than if I construct a single object, the each time reset the p parameter and use the object. I am not sure why the setter method was not provided. 296 RealType success_fraction() const 297 { // Probability. 298 return m_p; 299 } 300 void set_success_fraction(RealType p) { 301 m_p=p; 302 } Line 296 is the getter method, I added the setter method at line 300. -- Kemin Zhou 858 366 8260

4 4

Boost.Nowide Ready for release
by Alexander Grund 16 Mar '20

16 Mar '20

Hi all, after the discussion in January this year I took over maintenance of Boost.Nowide. First goal: Integrate all changes and requests that came up during review and as Github Issues including the docs. Second goal: Get extensive CI running with coverage especially on Windows (it is a mainly Windows library) Third goal: Iron out bugs, performance issues and incompatibilities. Of great help was my fork I prepared (and announced here) earlier but it was still an incredible amount of work. I can now say I'm done! I invite everyone to test it, (re-)review the code or check the docu for anything that's missing: https://github.com/boostorg/nowide One of the bigger changes was to make the library "less header-only" (it already required compilation on Windows when using iostreams). This was due to some required functions being considered extensions by e.g. MinGW/Cygwin and hence failing for consumers build with `-std=c++98` (or similar). This now works! Final note for those interested: The standalone (non-Boost) version and converter will be available later. Happy poking!

3 3

[gil] Broken bit-aligned pixel locator on MSVC++ 64-bit optimized builds only
by Mateusz Loskot 14 Mar '20

14 Mar '20

Hi, Over the last few months, intermittently I've been chasing a peculiar bug that has been revealing itself in failing checksum tests in GIL's test/legacy/image.cpp [1] since we started testing GIL with MSVC++ (VS2017, VS2019) with b2 toolset=msvc variant=release address-model=64 [1] https://github.com/boostorg/gil/blob/2ff2d31895dae665ef3e05d0496bc082470e22… The peculiarity of this bug is that it has not been observed using any of these compilers: - GCC: 4.8, 4.9, 5, 6, 7, 8, 9 - Clang: 3.9, 4.0, 5.0, 6.0, 7, 8, 9, 10 - XCode: 8.3, 9.0, 9.1, 9.2, 9.3, 9.4, 10 There is complete report [2], but I also decided to reach the list looking for any insights that may help me to understand what may be causing the bug. Complete repo [3] has GitHub Actions to build and run minimal_test.cpp test. [2] https://github.com/boostorg/gil/issues/447 [3] https://github.com/mloskot/boost-gil-checksum-bug This minimal_test.cpp (at the bottom) leaves out the checksum calculation and narrows the scope of the bug down to the `xy_locator` and advances of the iterators. The test basically is this: 1. Create 3x3 image based on bit-aligned BGR or RGB pixel (e.g. bgr121_image_t) 2. Fill image with red 3. Draw blue diagonal ``` bgr121_image_t img(3, 3); // ... fill img with `bgr121_red` pixels // draw blue diagonal auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value ++loc.x(); // INCREMENT X FIRST --loc.y(); } ``` If the loop like this is compiled using either - `b2 toolset=msvc variant=release address-model=64 optimization=space` (/O1 /Ob2) - `b2 toolset=msvc variant=release address-model=64 optimization=speed` (/O2 /Ob2) then pixels of the blue diagonal are messed up. If the loop is compiled without optimization using either - `b2 toolset=msvc variant=debug address-model=64` (/Od /Ob2) - `b2 toolset=msvc variant=release address-model=64 optimization=off` (/Od /Ob2) then pixels of the blue diagonal are correct. Now, if the `for` loop above is modified, that is, lines incrementing the `x_iterator` and `y_itertor` are reordered: ``` for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value --loc.y(); ++loc.x(); // PRE-INCREMENT X SECOND } ``` or ``` for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value --loc.y(); ++loc.x(); // POST-INCREMENT X SECOND } ``` then the blue diagonal is drawn correctly regardless of the MSVC++ optimizations. If the loop is manually unrolled, see minimal_test.cpp below, the blue diagonal is correct too. I'm yet to try the CE to see compare the generated code, as far as my limited assembly fu goes, but currently Boost for MSVC++ on CE is broken (https://github.com/mattgodbolt/compiler-explorer/issues/1816) If anyone would have any insights on what may be causing the problem, or any suggestions what else to test, I would greatly appreciate that. Obviously, I'm getting suspicious about the MSVC++ optimizer, but I do know blaming a compiler is last+1 resort :) Thanks Mateusz ``` // minimal_test.cpp #include <boost/version.hpp> #include <boost/core/lightweight_test.hpp> #if BOOST_VERSION < 106900 #include <boost/gil/gil_all.hpp> #else #include <boost/gil.hpp> #endif namespace gil = boost::gil; #if BOOST_VERSION > 107200 using channel_sizes_t = boost::mp11::mp_list_c<int, 1, 2, 1>; #else using channel_sizes_t = boost::mpl::vector3_c<int, 1, 2, 1>; #endif using bgr121_ref_t = gil::bit_aligned_pixel_reference < std::uint8_t, channel_sizes_t, gil::bgr_layout_t, true > const; using bgr121_image_t = gil::image<bgr121_ref_t, false>; using bgr121_view_t = typename bgr121_image_t::view_t; using bgr121_pixel_t = typename bgr121_view_t::value_type; bgr121_pixel_t bgr121_red(0), bgr121_blue(0); void fill_image_red(bgr121_image_t& img) { gil::rgb8_pixel_t red8(255, 0, 0); gil::rgb8_pixel_t blue8(0, 0, 255); gil::color_convert(red8, bgr121_red); gil::color_convert(blue8, bgr121_blue); auto v = view(img); std::fill(v.begin(), v.end(), bgr121_red); for (auto it = view(img).begin().x(), end = view(img).end().x(); it != end; ++it) BOOST_TEST(*it == bgr121_red); } void test_draw_with_xy_locator_loop_fail(std::ptrdiff_t w, std::ptrdiff_t h) { bgr121_image_t img(w, h); fill_image_red(img); { auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // OPTION 1 FAILS ++loc.x(); // PRE-INCREMENT X FIRST --loc.y(); // OPTION 2 FAILS TOO //loc.x()++; // POST-INCREMENT X FIRST //loc.y()--; // OPTION 3 FAILS TOO //auto& x_it = loc.x(); // PRE-INCREMENT NAMED X FIRST //++x_it; //auto& y_it = loc.y(); //--y_it; } } { auto it = view(img).begin().x(); // row 0 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // row 1 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // FAIL BOOST_TEST(*it == bgr121_red); ++it; // row 2 BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); } } void test_draw_with_xy_locator_loop_good(std::ptrdiff_t w, std::ptrdiff_t h) { bgr121_image_t img(w, h); fill_image_red(img); { auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // OPTION 1 WORKS --loc.y(); ++loc.x(); // PRE-INCREMENT X SECOND // OPTION 2 WORKS TOO //loc.y()--; //loc.x()++; // POST-INCREMENT X SECOND } } { auto it = view(img).begin().x(); // row 0 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // row 1 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; // row 2 BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); } } void test_draw_with_xy_locator_step_good(std::ptrdiff_t w, std::ptrdiff_t h) { bgr121_image_t img(w, h); fill_image_red(img); { auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); *loc = bgr121_blue; // red red blue ++loc.x(); --loc.y(); *loc = bgr121_blue; // red blue red ++loc.x(); --loc.y(); *loc = bgr121_blue; // blue red red ++loc.x(); --loc.y(); } { auto it = view(img).begin().x(); // row 0 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // row 1 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; // row 2 BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); } } int main() { test_draw_with_xy_locator_loop_fail(3, 3); test_draw_with_xy_locator_loop_good(3, 3); test_draw_with_xy_locator_step_good(3, 3); return boost::report_errors(); } ``` Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

[website] Update notes of historic releases
by Mateusz Loskot 11 Mar '20

11 Mar '20

Hi, Is this possible to update release notes of historic releases? I'd like to update notes of GIL for 1.69 which, as I found, have been never collected and are completely missing https://github.com/boostorg/gil/commit/2ff2d31895dae665ef3e05d0496bc082470e… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

C++ Deflate (zlib-like) library
by Janson R. 11 Mar '20

11 Mar '20

Hello everyone, I have recently been working on a C++ compression library very similar to zlib after trying to implement some HTTP compression support over Boost.Beast and realizing after some discussion with sir Falco that while it would be a nice builtin feature for Beast, it would possibly be a better idea to have zlib-like compression be a separate library in order to be properly maintainable and likely more useful. The current working version can be viewed at https://github.com/ryanjanson/Deflate however the API could still be helped in terms of modern C++ usability, and what I currently have in mind can be found annotated here: https://gist.github.com/AeroStun/687ec9ca69404e26f8e02e5084926036 Do you thing that this could be useful to have as its own entity in the Boost environment? Any kind of feedback on the idea and the library is warmly welcome. Regards, Janson

14 58

boost thread strange behaviour
by Adham Sabry 08 Mar '20

08 Mar '20

hi , i am trying to learn executors and executors thread pools using with boost::async but i found strange behabiour when i make thread pool adaptor ea and submit tasks to it and make ea00 and submit tasks to it if i started ea with async , it automatically starts ea00 the attached file has the code i thought that async will only start the passed thread pool"adaptor" But i think there is underlying thing which gather all threads of different pools into single entity and starts them with any call to boost::async is this a bug??? i run this from windows 7 64 by visual studio 2017

3 7

[GSoC20] [Boost.Geometry] Seeking mentor for project 1
by João Tavares 07 Mar '20

07 Mar '20

Hello, I am a third year undergraduate student from IST - University of Lisbon in Applied Mathematics and Computer Science. I am very interested in the project 1 on the Boost.Geometry library. Having dealt with this sort of problem both on my university courses and on my own, in the context of competitive programming, I feel like I could contribute to this project during GSoC 2020. Regarding the competency test I have not been able to understand how or where it should be submitted. I am sending this e-mail to know whether there is someone willing to mentor me for this project. Thanks for the replies in advance. Best regards, João Tavares IST - University of Lisbon

2 1