April 2020 - Boost - lists.boost.org

Fwd: teeks / boost.test: some test files not found
by Raffi Enficiaud 16 Apr '20

16 Apr '20

I am cross-posting this on the dev mailing list as I would like to know how to fix this before the 1.73 deadline. Thanks and sorry for cross-posting, Raffi -------- Forwarded Message from the test gmane group Hi, On some teeks workers, I have this strange issue: teeks99-09-p-64: https://www.boost.org/development/tests/develop/developer/output/teeks99-09… The error says: .../libs/test/test/framework-ts/log-formatter-test.cpp(117): error: in "test_logs": check output.match_pattern(true) has failed: Pattern file can't be opened! which means some files used for testing, such as test/test/baseline-outputs/log-formatter-test.pattern , are not found. Those files are advertised in the Jamfile, https://github.com/boostorg/test/blob/develop/test/Jamfile.v2#L145 I guess it would be a hard error on b2 if the files were not found. What should I do such that those workers find the test files? I recently added one file to the previous 2 existing files. Thanks, Raffi

1 0

[Graph] Min Cut with float weights
by Phil Endecott 16 Apr '20

16 Apr '20

Dear Experts, I am attempting to use stoer_wagner_min_cut for the first time. Using float as the edge weight type seems to be problematic for non-trivial graphs. I think this is possibly because it adds an edge weight to the cut weight and then later subtracts the same value, but doesn't get back to exactly the previous value due to loss of precision. The errors accumulate and eventually the reported cut weight is nonsense. I am now trying with integer weights but I worry that this could suffer overflows. If my edge weights are in the range 0...W, for a graph with E edges the largest cut weight would be < W*E. But does the algorithm ever use larger values internally? Also, I'd be interested if anyone has tried to break a graph into subgraphs by recursively breaking at the min_cut until the min_cut weight is below some threshold. I have a graph with of the order of 10^4 vertices and 10^6 edges and this would be tractable if the min_cuts broke the graph into roughly equal pieces; instead, they tend to remove a small number of vertices each time, leaving almost as much work for the next recursion. So I think I want to find a cut whose weight is below a threshold and that is in some sense locally minimal and that leaves two largish subgraphs. Any ideas? Cheers, Phil.

1 0

Reminder: 1.73.0 master branch closes one week from today
by Marshall Clow 15 Apr '20

15 Apr '20

22-Apr Boost 1.73.0 closed for release ASAP Boost 1.73.0 release -- Marshall

1 0

Re: [boost] MySQL ASIO library
by Andrey Semashev 14 Apr '20

14 Apr '20

[Sending this reply to list as opposed to personal email] On Wed, Mar 4, 2020 at 3:39 PM Richard Hodges <hodges.r(a)gmail.com> wrote: > On Wed, 4 Mar 2020 at 13:25, Andrey Semashev <andrey.semashev(a)gmail.com> wrote: >> >> On Wed, Mar 4, 2020 at 1:50 PM Richard Hodges via Boost >> <boost(a)lists.boost.org> wrote: >> > >> > > Why just MySQL? >> > >> > Getting something useful released is more important than getting something >> > perfect released. >> > >> > If Ruben has a ready-to-go solution for MySQL, why not make it available to >> > users? >> >> Making it available to users is not the same as making it part of >> Boost. Boost is known for general purpose libraries, as well as more >> domain-focused solutions, but it is not a place for wrappers around >> specific other libraries. Let alone, when the said libraries already >> have C/C++ API. > > Boost also has mpi, regex, asio::ssl and python. What are these if not wrappers around common c libraries? I'm not sure about Boost.MPI, but I thought it was not a wrapper of a single library, but of a standard API that can be implemented by different libraries. Boost.Regex is not a wrapper at all; it implements regular expressions from scratch. asio::ssl is not a library but a plugin for Boost.ASIO that provides one small piece of functionality compared to the rest of the library. Boost.Python is probably closest to an exception, although it is a binding to another language (not a library), which arguably only has one C API and implementation. Yes, there is CPython, but I don't believe it offers a C API. >> > It can always be complemented or extended with Oracle, SQLite, ODBC etc etc >> > later. >> >> If the proposed library offers a stable and flexible API that can be >> backed by multiple implementations then by all means - that would be a >> very interesting proposal indeed. But the author has to demonstrate >> that the proposed user API can in fact be supported by more than one >> backend, so at least two backends need to be presented, and preferably >> with guidelines and infrastructure for adding more. > > Mpi, regex and python would dispute this arbitrary restriction. I don't think so, as per above. > Boost suffers from a lack of contribution. Is there any value in making contribution difficult? I don't think the amount of contributions by itself is the goal. There has to be value associated with the contribution. I just don't think a C++ wrapper of a specific library has enough value.

11 28

Code coverage tests
by Edward Diener 14 Apr '20

14 Apr '20

A number of libraries have code coverage/project tests in Github. I am not against such tests but I am against the idea that "failing" such a test, whatever that means, should prevent a PR from being merged into a Boost library. To me it is nonsense that a perfectly logical change to software should lead to some code coverage "failure", and that therefore the change should be deemed incorrect. I admit I do not know what the criteria are for code coverage but I do not see code coverage determining whether any change to a library is incorrect or not.

11 19

[release] Boost 1.72.0 Beta 1
by Marshall Clow 12 Apr '20

12 Apr '20

Boost release 1.73.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.73.0.beta.1/source/> The SHA256 checksums are as follows: 44f323b42c4375ab3751b67ac5ce53ba5267af20cf375be75675d8952d3cca4e ./boost_1_73_0_b1.7z 5270fa89243a3508331bd3773800de6d2f98d1f160b95e362fa8269d9cd58773 ./boost_1_73_0_b1.tar.bz2 82ffcd4a2e558a31f1ddd6a54ef6c00dae28b95c2ddee575c285544085dcb004 ./boost_1_73_0_b1.tar.gz 910b7560ee239472cc69e6a0c680dc4d9d7ea234faad807738ec98e4811c63d4 ./boost_1_73_0_b1.zip For details of what's in the release, see <https://www.boost.org/users/history/version_1_73_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

[release] Boost 1.73.0 Beta 1 Release Candidate 1
by Marshall Clow 10 Apr '20

10 Apr '20

The release candidates for the first 1.73.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.73.0.beta.1/source/ The release notes are not yet available. The SHA256 checksums are as follows: 44f323b42c4375ab3751b67ac5ce53ba5267af20cf375be75675d8952d3cca4e ./boost_1_73_0_b1_rc1.7z 5270fa89243a3508331bd3773800de6d2f98d1f160b95e362fa8269d9cd58773 ./boost_1_73_0_b1_rc1.tar.bz2 82ffcd4a2e558a31f1ddd6a54ef6c00dae28b95c2ddee575c285544085dcb004 ./boost_1_73_0_b1_rc1.tar.gz 910b7560ee239472cc69e6a0c680dc4d9d7ea234faad807738ec98e4811c63d4 ./boost_1_73_0_b1_rc1.zip 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. -- The Boost Release Managers

4 6

Re: [boost] [Boost-users] 404 GMane link in Boost.FileSystem doc
by Glen Fernandes 09 Apr '20

09 Apr '20

On Thu, Apr 9, 2020 at 6:15 AM Dominique Devienne wrote: > > Over at > https://www.boost.org/doc/libs/1_72_0/libs/filesystem/doc/reference.html#pa… > (and older version of the doc too) there's a link to > http://permalink.gmane.org/gmane.comp.lib.boost.devel/199744 > which is no longer so permanent :). According to https://en.wikipedia.org/wiki/Gmane > the website is no longer available. I guess any GMane link in docs should be updated > to another ML archive. Yes, the link should be updated to: https://lists.boost.org/Archives/boost/2010/02/162028.php Created https://github.com/boostorg/filesystem/commit/aaf54ada48b8da2bfc22b87d2890a… Glen

1 0

[release] 1.73.0 closed for Beta
by Marshall Clow 09 Apr '20

09 Apr '20

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_73_0.q… > Thanks, -- The Boost Release Team

1 0

1.73.0 Beta Deadline this Wednesday 4/8
by Marshall Clow 09 Apr '20

09 Apr '20

The deadline for major changes has passed. Upcoming dates: 8-Apr Boost 1.73.0 closed for beta ASAP Boost 1.73.0 beta 22-Apr Boost 1.73.0 closed for release ASAP Boost 1.73.0 release "ASAP", in this list, means "As soon as possible after the preceding milestone" -- Marshall

6 16

boost [math] excessive warnings via [lexical_cast] from [date_time] (and others) for clang 3.4?
by Jeff Garland 08 Apr '20

08 Apr '20

In the regression tables the following warnings are coming out of math config. I'm trying to understand what this means given that 1) the tests compile and execute fine, 2) the deadline is up, and 3) several of the cases are compiled in c++11 mode (is it pre conformance bc it's clang3.4?). I've seen this warning in other places that include lexical_cast as well. So sure I could go and define the macro to quiet this, but seems like that should be done closest to the source. In other words maybe math should only tell us that in headers that have a real issue? Or will this soon be a real issue? ../boost/math/tools/config.hpp:42:9: warning: CAUTION: One or more C++11 features were found to be unavailable [-W#pragma-messages] ../boost/math/tools/config.hpp:43:9: warning: CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021. [-W#pragma-messages] ../boost/math/tools/config.hpp:44:9: warning: CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message. [-W#pragma-messages] Full examples https://www.boost.org/development/tests/develop/developer/date_time.html https://www.boost.org/development/tests/develop/output/teeks99-dkr-dc3-4-98…

5 23

Gsod20 interest
by Damian Vicino 08 Apr '20

08 Apr '20

Hi, I'm wondering if there is interest in submitting boost as a potential org for Google season of docs (https://developers.google.com/season-of-docs) Also, if someone would like to be mentor on it, that would be great to know too. Best regards, Damian

2 1

Boost local unix domain example for IPC
by Jupiter 08 Apr '20

08 Apr '20

Hi, I am doing boost local unix domain for IPC, I midified the code based on sample code from boost_asio/example/local/stream_server.cpp, I am a little bit puzzled for errors calling different async_read, if I call original code using shared_from_this() it works fine: boost::asio::async_read(this->mSocket, boost::asio::buffer(this->mData), boost::bind(&session::HandleRead, shared_from_this(), boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); But if I tried to run a following lambda function which works in in my other boost asio TCP socket, it got an error "Operation canceled", what I could be missing here? Or do I have fundamontal problems in the lambda function I used for other TCP socket programs? boost::asio::async_read(this->mSocket, boost::asio::buffer(this->mData, sizeof(this->mData)), [=](const boost::system::error_code &status, const uint32_t size) {this->HandleRead(status, size);}); Thank you. Kind regards, - jh

2 2

[xpressive] Where are the names in the c_ctype.h file coming from
by Edward Diener 07 Apr '20

07 Apr '20

In the xpressive header file c_ctype.h there are names such as _ALPHA, _UPPER, _LOWER, _DIGIT etc. Where are these names declared or defined ? I searched through all the Boost libraries and did not find any of these names declared or defined anywhere. Are they supposed to be part of some C++ standard header file ?

1 0

Asio, gcc and -fconcepts
by Richard Hodges 07 Apr '20

07 Apr '20

Dear all, With the upcoming Boost 1.73 release imminent, I felt it was worthwhile pointing out that latest gcc has a problem with Asio if the `-fconcepts` command line flag is set. There is an issue in the Boost.Asio repo here relating to the manifestation of the bug in MSVC: https://github.com/boostorg/asio/issues/312 and an issue here in the Boost.Beast repo: https://github.com/boostorg/beast/issues/1884 It seems that the file boost/asio/detail/config.hpp was written when concepts support was not widespread and still in the concepts.ts stage. The syntax and capabilities of concepts were subtly changed during standardisation, with gcc and MSVC only supporting the C++20 dialect. Thus, compiling an Asio-based program with concepts enabled in either of gcc or MSVC fails unconditionally. I'm wondering if anyone has Chris' ear and might ask him to indulge us with a fix prior to the 1.73 release. I fear that by the time Boost 1.73 is in mainstream use, C++20 will be upon us we'll see an increase in issues and a loss of reputation as a result. Thanks for your time, Sincerely, -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

3 4

[Performance of circular_buffer vs Queue][Multithreading may be broken]
by Jan Hafer 04 Apr '20

04 Apr '20

Dear Boost developer, I found the circular buffer to be slower than std::queue for multithreading except in the case of a single thread (where it is notably faster). I am using resize() to have the expected size filled as in vector. Is this behavior expected or documented anywhere? What kind of speedup is to be expected against the std::queue implementation? If there is none, then what is the purpose of circular buffer? I do also have broken code on a multithreaded application that worked fine before. I do pass the circular buffer as reference via functions from file scope, which in combination with the threads (initially starting elsewhere) somehow broke the code. Do you do regular benchmarks against other implementations? I dont see linked graphs on your homepage. Regards, Jan

7 10

[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 03 Apr '20

03 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