- Boost - lists.preview.boost.org

[1.73][thread] Merge to master and apply PRs
by Andrey Semashev 04 Apr '20

04 Apr '20

Hi, There are a number of fixes in Boost.Thread develop that I would like to see in 1.73, but they are not merged to master. The last commit to develop was in Dec 2019, so plenty of time has passed for testing. I'd like to ask someone to merge develop to master. https://github.com/boostorg/thread/issues/311 Also, there are two PRs hanging for quite some time that I would also like to see in 1.73: https://github.com/boostorg/thread/pull/309 https://github.com/boostorg/thread/pull/310 I'd like to ask someone with merge permissions to have a look and merge them (first to develop, and then to master, after testing). I tried pinging Vicente, but he is not responding. Most of the changes in develop and the PRs are aimed to resolve various warnings generated by Boost.Thread, including using deprecated features of Boost.Bind, Boost.WinAPI and C++. Thanks.

1 0

Re: [boost] Linking libboost_python.so to libpython
by Peter Dimov 03 Apr '20

03 Apr '20

> That's why you weren't getting the error before 1.72, but not the reason > why libboost_serialization ends up with the different property sets. FWIW, my Travis build/install of --with-mpi works: https://travis-ci.org/github/boostorg/boost_install/jobs/669821455 and I can't find the place that's setting <dll-path>/usr/lib <dll-path>/usr/lib/python3.8/config.

2 1

Linking libboost_python.so to libpython
by Jonathan Wakely 03 Apr '20

03 Apr '20

tools/build/src/tools/python.jam says: # On *nix, we do not want to link either Boost.Python or Python extensions # to libpython, because the Python interpreter itself provides all those # symbols. If we linked to libpython, we would get duplicate symbols. So # declare two targets -- one for building extensions and another for # embedding. Why would that give duplicate symbols? Wouldn't ELF symbol interposition mean that only one is used? Why would it be a problem to link to libpython? In Fedora's Boost RPM packages we *do* link libboost_python.so to the system libpython (and we don't get any problems). But to do this, we have these two local patches: https://src.fedoraproject.org/rpms/boost/blob/master/f/boost-1.57.0-python-… and then to make it link to libpython3.7m.so (rather than libpython3.7.so) we have this patch to pass the "m" into the Boost build: https://src.fedoraproject.org/rpms/boost/blob/master/f/boost-1.66.0-python-… I'd prefer not to need these local hacks. Would the upstream Boost.Python consider making changes so that libboost_python.so can be (optionally) linked to libpython? Is there a cleaner way to do this than those patches?

5 12

Regarding GSoC 2020 Proposal for uBLAS Dataframes
by Tom Kwok 02 Apr '20

02 Apr '20

Hi everyone, I have submitted a final PDF version of my GSoC 2020 Proposal for uBLAS Dataframes, just before the deadline yesterday. I would be looking forward to receiving feedback from potential mentors. Today I read my final proposal again and I noticed a bunch of typos, such as incorrectly stating “heterogenous” columns for a data frame (which should be “homogeneous” columns since they are single-typed), and a few others. I am very sorry for the typos due to rushed drafting and submission. I am aware that it would be unfair to other participants to make corrections after the deadline, and please take the final PDF version submitted for review. Here I am only trying to let reviewers know, when they give comments, that I am already aware of some of the minor typos, which are fixed in a patched version of my proposal accessible via the submitted link to “draft” that points to a Google Drive document that I can update at any time (with document creation date in the heading generated by my Latex template). Best regards, Tom

2 1

[gil] Review of move assignment operator for image class
by Mateusz Loskot 02 Apr '20

02 Apr '20

Hi, We're adding move semantics to some of GIL classes [1] and we'd like to receive feedback on the move-assignment operator for the image class [2] (copied below) that we've worked out so far if there are any major blunders to correct or gaps to fill for C++11 compliant implementation: image& operator=(image&& img) { if (this == std::addressof(img)) return *this; auto const exchange_memory = [](image& lhs, image& rhs) { lhs._memory = boost::exchange(rhs._memory, nullptr); lhs._align_in_bytes = boost::exchange(rhs._align_in_bytes, 0); lhs._allocated_bytes = boost::exchange(rhs._allocated_bytes, 0); lhs._view = boost::exchange(rhs._view, image::view_t{}); }; constexpr bool pocma = std::allocator_traits<Alloc>::propagate_on_container_move_assignment::value; if (pocma) { // non-sticky allocator, can adopt the memory, fast destruct_pixels(this->_view); this->deallocate(); this->_alloc = img._alloc; exchange_memory(*this, img); } else if (_alloc == img._alloc) { // allocator stuck to the rhs, but it's equivalent of ours, we can still adopt the memory destruct_pixels(_view); this->deallocate(); exchange_memory(*this, img); } else { // cannot propagate the allocator and cannot adopt the memory if (img._memory) { allocate_and_copy(img.dimensions(), img._view); destruct_pixels(img._view); img.deallocate(); img._view = image::view_t{}; } else { destruct_pixels(this->_view); this->deallocate(); this->_view = view_t{}; } } return *this; } One thing that is still missing is the noexcept with expression evaluated based on something like this template <class _Alloc> using is_noexcept = std::conditional_t < std::allocator_traits<_Alloc>::is_always_equal::value, _Equal_allocators, typename std::allocator_traits<_Alloc>::propagate_on_container_move_assignment::type >; but we there is no is_always_equal in C++11, so there are gaps to fill. Any comments are appreciated. [1] https://github.com/boostorg/gil/pull/457/ [2] https://github.com/boostorg/gil/blob/7d8df1c105e81070e30ef68ea7abb8e39111d6… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Request to review my GSoc Proposal[Boost multiprecision
by suyashtava 01 Apr '20

01 Apr '20

Dear Sir/Ma'am, It would be great if you could review my GSOC proposal for [Boost multiprecision]: New Big-Double Backend Types Doc link: https://docs.google.com/document/d/1xznSxg1XcAiQMnVXSMG_NwxuUeGmkI5iXhabSXe… I deeply regret and apologize for the late submission, but I request you to review it once as it will surely help me to update it in required ways. With regards Suyash Srivastava IIT(ISM) Dhanbad -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

5 6

[GSoC2020][Boost.Real] Greeting
by Firmin Martin 01 Apr '20

01 Apr '20

Hi, Boost community! This mail is not intended to serve as a proposal review (it's too late obviously). Instead, I would want to greet my potential mentors and possible collaborators. Anyway, whether or not my proposal is retained, I will probably still contribute after GSoC 2020 since I've got familiar enough to the codebase by dint of reading blog posts, references and code sources. I made a small PR involving BBP formula to compute the n-th binary digit of pi and already submitted my final proposal to GSoC. Best regards, Firmin

2 1

Download links all broken?
by John Maddock 31 Mar '20

31 Mar '20

All the download links from www.boost.org appear to be currently broken - which is to say no one can download Boost right now. Ideas or fixes anyone? Thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

10 21

[test][program_options] Avoid deprecated bind placeholders in global namespace
by Mateusz Loskot 31 Mar '20

31 Mar '20

Hi, I have a shy request to maintainers of boostorg/test and boostorg/program_options Would it be possible to merge these trivial patch to both: https://github.com/boostorg/test/pull/259 https://github.com/boostorg/program_options/pull/92 Thanks in advance. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Proposal Review
by Kishan shukla 31 Mar '20

31 Mar '20

Hello everyone, I have prepared the draft proposal for the boost.Real project. It involves adding new mathematical functions and operators into the library. I have also planned on optimizing a few algorithms and addressing previously unresolved issues. The proposal is the result of my discussion with my mentor Damian Vicino. Sorry for being late. Please review the proposal and provide your valuable feedback. Proposal link: https://docs.google.com/document/d/1oXAaaiqgtC2bTCfADPwXUY4ItYw-C8EMOLr2Bhu… Regards, Kishan Shukla

2 2