- Boost - lists.preview.boost.org

[1.77] Requesting post-beta merges
by John Maddock 15 Jul '21

15 Jul '21

I have some late changes I'd like to merge to master if possible: For multiprecision, it's basically a single bug fix (for https://github.com/boostorg/multiprecision/issues/342) details here: https://github.com/boostorg/multiprecision/pull/344, note that the single CI failure is spurious. For Math, the collected changes are here: https://github.com/boostorg/math/pull/661 The really big changes here are documentation, the remaining issues fixed are documented in the PR above. There is one further change for Math, that I've neglected to cherry pick to the PR above, but it's this one: https://github.com/boostorg/math/pull/659 which fixes some invalid code that had slipped through. Many thanks! John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 2

[1.77] Permission to merge to master
by Andrey Semashev 15 Jul '21

15 Jul '21

Hi, I'd like to merge the following changes to master: https://github.com/boostorg/filesystem/commit/003f00239963e4b270a47d7e78664… https://github.com/boostorg/filesystem/commit/9e5a3e231e5a5d3c501447ca307a3… Fixes Boost.Filesystem compilation for Android and Mac OS. https://github.com/boostorg/utility/commit/6cca23a63a1c038b9afc261037548b78… Removes dependency of Boost.Utility on Boost.ContainerHash.

2 1

Master branch now closed for 1.77.0 beta release
by Marshall Clow 14 Jul '21

14 Jul '21

Please do not make any commits to the master branch. — Marshall

2 1

[release] Boost 1.77.0 beta 1 released
by Marshall Clow 14 Jul '21

14 Jul '21

Boost release 1.77.0 beta 1 is now available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.77.0.beta1/source/> The SHA256 checksums are as follows: 1aba2bf9416d71026c9e6bbd10a2b7cfb31b0950baa7ad0861dfb74984d96bd9 boost_1_77_0_b1.zip 55126d149664541ffc9fd1f41b2ec67146d69bdab92e41da4bb8610b755ca9ec boost_1_77_0_b1.7z 1aabe7704e91f4f8d97b81d03ddc21c3396f4b72fc4041f01bfcfc128bac0d73 boost_1_77_0_b1.tar.gz 3d5801790c96d2bc9ed23372c4f9fd963bc2f39fe540e35d7b4fe586ba77dfa7 boost_1_77_0_b1.tar.bz2 For details of what's in the release, see <https://www.boost.org/users/history/version_1_77_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

boost.python compilation error (newbie)
by maths soso 11 Jul '21

11 Jul '21

I'm new to boost, I decided installing it by following instructions provided at SO: https://stackoverflow.com/a/24086375/10213771 (The only difference is that I used version 1.76) Everything went fine, then I decided to compile this C++ file: char const* greet(){ return "hello, world";} #include <boost/python.hpp> BOOST_PYTHON_MODULE(hello_ext){ using namespace boost::python; def("greet", greet);} Since boost.python is not header only library, I needed to link to it on compilation, I used the following compile command: g++ -I ~/Desktop/boost_1_76_0/ -I /usr/include/python2.7/ main.cpp -o prog ~/Desktop/boost_1_76_0/stage/lib/libboost_python27.a but I get the following errors: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': (.text+0x24): undefined reference to `main' /usr/bin/ld: /home/sofiane/Desktop/boost_1_76_0/stage/lib/libboost_python27.a(registry.o): in function `boost::python::converter::registration::get_class_object() const': ... /usr/bin/ld: function_doc_signature.cpp:(.text+0x1de): undefined reference to `PyObject_IsTrue' /usr/bin/ld: function_doc_signature.cpp:(.text+0x23e): undefined reference to `PyInt_FromLong' /usr/bin/ld: function_doc_signature.cpp:(.text+0x28b): undefined reference to `PyInt_FromLong' ...

3 2

[release] Boost 1.77.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 10 Jul '21

10 Jul '21

The first release candidates for the 1.77.0 beta release are now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.77.0.beta1/source/ 1aba2bf9416d71026c9e6bbd10a2b7cfb31b0950baa7ad0861dfb74984d96bd9 boost_1_77_0_b1_rc1.zip 55126d149664541ffc9fd1f41b2ec67146d69bdab92e41da4bb8610b755ca9ec boost_1_77_0_b1_rc1.7z 1aabe7704e91f4f8d97b81d03ddc21c3396f4b72fc4041f01bfcfc128bac0d73 boost_1_77_0_b1_rc1.tar.gz 3d5801790c96d2bc9ed23372c4f9fd963bc2f39fe540e35d7b4fe586ba77dfa7 boost_1_77_0_b1_rc1.tar.bz2 The web site has NOT YET been updated. 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 Release managers

3 3

The Master branch will be closing for the 1.77.0 beta release TODAY!
by Marshall Clow 07 Jul '21

07 Jul '21

If you have changes for the beta, they need to be merged to master today. See https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> for the full calendar — The Release managers

1 0

The deadline for Major changes for Boost 1.77.0 is TODAY!
by Marshall Clow 04 Jul '21

04 Jul '21

See https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> for the full calendar — The Release Managers

4 6

Poor performance on windows with logging sinks::file_collector when two file logs use same directory. Thoughts?
by Nicholas Neumann 24 Jun '21

24 Jun '21

I've got two different rotating file logs that point to the same directory (with different file name patterns). Is this in general just a bad idea? They end up sharing the same file_collector, which seems wrong, so perhaps that is a clue that I shouldn't have my logs set up like this. In production I've got a service that compresses, archives, and manages the size of the logs. But in dev, I don't, so the number of files in the directory slowly grew. But the startup time for my program grew much faster. On windows the scan_for_files function in the collector has a loop that is O(mn), where m is the number of files in the directory, and n is the number that matched in previous calls to the scan_for_files function This means the scan_for_files for the first rotating file log in the directory has no issue (n is 0), but the second can be problematic. It iterates over the files in the directory and for each file in the directory, it calls filesystem::equivalent on all of the matches from previous scan_for_files calls. On windows, filesystem::equivalent is particularly heavy, opening handles to both files. Thoughts? Is the two file logs getting the same collector the real issue? Or is it my pointing two file logs to the same directory? I see some ways to mitigate the slowdown in scan_for_files - e.g., filesystem::equivalent could be called after all of the method/match_pattern check, but the two file logs sharing the same collector feels like the real issue.

3 3

The deadline for new libraries and breaking changes in Boost 1.77.0 is this Wednesday, June 23
by Marshall Clow 21 Jun '21

21 Jun '21

See https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> for the full calendar — The Release Managers

1 0