May 2020 - Boost - lists.boost.org

Google Summer of Code 2020 selected projects
by David Bellot 09 May '20

09 May '20

Dear Boost community, I would like to welcome our Google Summer of Code. 2020 students. This year, 10 students will work very very hard on improving and adding new features to many of our libraries. Once again, the competition has been very hard. A few numbers: - we received 93 proposals in total. 85 of them were complete, then we kept 47 proposals only - finally we selected 10 of them, covering 7 different Boost libraries - and countless hours of work from the most incredible team of mentors! Here are the list of projects for 2020: *Boost.Real* Kishan Shukla will be working on making the Real library ready for revision. His main goal is to reimplement the division algorithm so it can be used with any number base representation and the Karatsuba multiplication algorithm. Also, it will be working on implementing some operators and common irratianal numbers as Pi. Mentors: Laouen Belloli and Damian Vicino. *Boost.Astronomy* Syed Ali Hasan will be working on the astronomical coordinate system, he will implement different coordinate conversion using SOFA library Mentor: Pranam Lashkari Gopi Krishna Menon will be completing the parser for FITS file and also optimise the already developed components. Mentor: Sarthak Singhal *Boost.GIL* Debabrata Mandal will be implementing histogram computation as a built-in feature, algorithms for histogram analysis, image processing algorithms based on histogram and possibly integration with Boost.Histogram library. *Mentor*: Mateusz Loskot, Pranam Lashkari Olzhas Zhumabek will be extending GIL's portfolio of image processing algorithms, implementing for image scaling and sampling, Perona–Malik diffusion, Non-Maximum Suppression for object detection, Hysteresis threshold and some more. *Mentor*: Mateusz Loskot *Boost.Multiprecision* Dimitris Los will work on extending and optimizing parts of Boost.Multiprecision to higher precision of many thousands of bits or more. *Mentor*: Christopher Kormanyos *Boost.uBlas* Ashar Khan will stabilize and improve Boost.uBlas using the C++20-Standard. The main focus of his project will be enhancing code-coverage and documentation, integrating static code analysis and generating tensor concepts. *Mentor*: Cem Bassoy Tom Kwok will improve and finalize the implementation of data frames in uBlas, with the aim of delivering production-ready by the end of the summer. Data frame in uBlas are similar in functionalities to other implementations like in R, Python.Pandas or Julia. *Mentor*: David Bellot *Boost.Geometry* Tinko Bartels will work on robust yet efficient geometric predicates for Boost Geometry. *Mentor*: Vissarion Fisikopoulos *Boost.Real* Vikram Singh Chundawat will work in taking Real to revision ready state. His focus will be in improving the internal representation datatypes and providing functions required to conveniently support Taylor series. *Mentors*: Damian Vicino and Laouen Belloli Best regards, David Bellot

1 0

[github] Retriggering CI tests
by Edward Diener 08 May '20

08 May '20

How does one retrigger CI testing for a PR on Github without having to artificially update the PR ? I tried to find the answer to this in Github Help with no success. Maybe you have to retrigger tests within the testing environment somehow but I could not see how in either Appveyor or Travis CI.

4 5

[LEAF] The usage of TLS
by Andrzej Krzemienski 05 May '20

05 May '20

Hi Everyone, I have a remark regarding the LEAF library. But first, I would like to thank Emil for writing and sharing this library. Handling failures is an important aspect of writing programs that does not have an ultimate answer in C++, and is still a subject of exploration. LEAF seems to confirm this. I would also like to thank Michael for managing this upcoming review and for making the announcement ahead of time. A ten-day review period is usually too short (even if later extended), and the early announcement gives the opportunity to devote more time into reviewing a library and interact with the author. The following is not a review, but I wanted to highlight only one aspect of the library. Namely, the usage of thread-local storage. There is a number of reasons people do not want to or cannot use the C++ exception handling mechanism. One of them is that the implementation of exception handling requires the usage of TLS, and TLS is not implementable on some platforms, like GPUs. If Nvidia's compiler does not implement C++ exception handling mechanism, it is not because it would be slow, but because it would require TLS support. From this perspective, if I cannot use C++ exceptions because of TLS and I have to use something else, then another TLS-based library is not really an alternative. In this case it does not matter that it is only IDs that are stored in TLS. The sole fact of even employing TLS is a deal breaker. Of course, LEAF does not have to satisfy all the people that cannot use C++ exceptions. It can service the environments where TLS is affordable. But the usage or non-usage of TLS is an important factor in making a decision what tool/framework/library to use for handling failures, and because of this it deserves to be mentioned in the beginning of the documentation, so that potential clients can quickly make a decision if this library is for them. If your concern is that people would be incorrectly led to think that the entire error objects are stored in TLS, you can also say explicitly up front that it is only about int-size IDs. Otherwise, people will be mislead anyway. A person will ask, "how is it possible that this library does not return the entire error object in leaf::result<> and it does not take the pointer to the allocated object as function argument? Is it using TLS? Let's grep for `thread_local`. Positive: it must be using TLS for storing error objects." For a similar reason, I find the comparison with Boost.Outcome, at the end of documentation, unfair. If the goal of this comparison is to help people decide which library is best suited for them, LEAF or Outcome, the usage or non-usage of TLS is an important factor. Another thing is that I cannot see how a TLS-based implementation can work with C++20 coroutines. In C++ 20 the following piece of code { A(); co_await X(); B(); } means that when the call to B() will be potentially "packaged" as a task and scheduled to be executed possibly on a different thread. It means that B() will be executed on a different thread than A(), which means that any attempt to communicate between A() and B() using TLS will not be reliable (e.g. if A() is in fact a call to leaf::preload()). This is the reason why we still cannot implement the feature known as "on scope failure" (like destructor call, but only when we are leaving the scope due to exception) in C++ even though we have `std::uncaught_exceptions()` (which uses TLS under the hood). This is why a proposal like P0052 ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0052r10.pdf) didn't make it to C++20. Now, LEAF may have a solution to this problem, but I cannot figure it out from the documentation. So, I do not know if it is safe to use LEAF with coroutines in multi-threaded environment. I would really want this to be clarified in the docs before the library review starts. Regards, &rzej;

5 7

Re: [boost] [release] Boost 1.73.0 Release Candidate 1
by Tim Haines 04 May '20

04 May '20

The patch has an extra directory indirection that prevented installation for me. Changing a/boost_1_73_0/boost/outcome to a/boost/outcome worked for me. Thanks. - Tim P.S. Apologies if this interjection breaks the correct flow of the mailing list. I get mine in a digest and couldn't figure out how to reply to just this message. On 28/04/2020 01:08, Glen Fernandes wrote > Niall, if you want we can provide a Boost.Outcome patch on the 1.73 > release notes (in similar fashion to the Coroutine patch on > https://www.boost.org/users/history/version_1_72_0.html under Known > Issues) and on https://www.boost.org/patches/ . Please find attached a diff against Boost 1.73 which was generated from bug fix commit https://github.com/ned14/status-code/commit/9f414ea58264fe0a62172a06f4653ad… Thanks for this, sorry for the bother. Niall

2 1

Circular span still alive
by Bjorn Reese 03 May '20

03 May '20

Last Autumn I asked if people were interested in a circular span and got a positive response. Since then I have been quite about it, mainly due to the usual daily work load. However, I have continued development, and now the project has been renamed and extended with other kinds of spans: circular queue, priority queue, and associative array. https://github.com/breese/vista The common theme for these spans are that they operate on contiguous memory that they do not own. The spans have been developed to be usable for embedded projects that cannot use dynamic memory allocation or exceptions, and where minimal code size is essential. There are also algorithms for in-place incremental insertion and removal in sorted sequences, similar to std::push_heap() and std::pop_heap(). There is also a C++11 std::span in hiding there. The documentation is still incomplete: https://github.com/breese/vista/blob/develop/doc/vista.adoc

1 0

Embarcadero C++ and Boost libraries
by Edward Diener 01 May '20

01 May '20

Embarcardero ( formerly Codegear, formerly Borland ) has had for about five years C++ compilers based on clang, along with the venerable bcc32, which is the Borland compiler of old through a number of transformations. The clang-based Windows compilers are bcc32c/bcc32x for 32-bit development and bcc64 for 64-bit development. The only difference between bcc32c and bcc32x is that the former takes the same command line flags as their legacy bcc32 compiler while the latter, like bcc64, takes clang command line flags. The clang-based C++ compilers are based on clang-5.0, and use the Dinkumware library. The clang based compilers still predefine __BORLANDC__ and __CODEGEARC__ but also predefine __clang__. The latter is the way to distinguish in preprocessor code between the bcc32 compiler and the clang-based compilers. Despite numerous workarounds in Boost code based on the predefined macros __BORLANDC__ and __CODEGEARC__ the bcc32 compiler, not being very C++ compliant even at the C++98/C++03 level at which it operates, has not really worked for Boost since about Boost 1.39. It is useless for modern day Boost. Therefore I have made efforts, in contact with some Embarcadero C++ representatives, to integrate the clang-based compilers into Boost, especially since there is a free non-commercial offering by Embarcadero called C++ Builder Community Edition at https://www.embarcadero.com/products/cbuilder/starter which any Boost developer could use to test these compilers if they wished. I am doing this in the hopes that this may become effective for Boost 1.74.0. Doing this involves: 1) Creating an embarcadero.jam toolset, based on the clang-linux.jam toolset, which supports bcc32x and bcc64. Updating the borland.jam toolset to also support bcc32c. I have done these and the PR has been merged to 'develop' on Boost Build. 2) Updating Boost Config to support the clang-based compilers. I have done this and the PR has been merged to 'develop' on Boost Config. 3) In the update to Boost Config, I have created these macros: a) BOOST_BORLANDC = __BORLANDC__ with __clang__ not defined b) BOOST_CODEGEARC = __CODEGEARC__ with __clang__ not defined c) BOOST_EMBTC = Embarcadero C++ compilers with __clang__ defined Therefore what is really needed in Boost libraries is to change all the code which currently uses __BORLANDC__ to BOOST_BORLANDC and all the code which uses __CODEGEARC__ to BOOST_CODEGEARC when Boost config has been included. When in the rarer case that Boost config has not been included, then __BORLANDC__ logic becomes __BORLANDC__ and !__clang__ and __CODEGEARC__ logic becomes __CODEGEARC__ and !__clang__. I am workiog on doing this for the numerous Boost libraries with workarounds nased on __BORLANDC__ and __CODEGEARC__ in Boost code, and will create PRs for those libraries. I only ask that library maintainers will merge the PRs I create once they have passed their CI tests, since the PRs are almost all just simple transformations regarding the __BORLANDC__ and __CODEGEARC__ in the code. If any library maintainer wants to so this on their own in the 'develop' branch it would be appreciated. Further points: The Embarcadero C++ clang-based compilers are not as good as clang itself, which is at release 9, gcc, or vc++. But they are good enough for the majority of Boost code. The Embarcadero C++ clang-based compilers support only C++17. The documentation implies that they also support C++11 and C++14 but that is not so. But since Boost libraries written for a C++ standard level are supposed to work flawlessly at a higher level this is no impediment for C++ Builder programmers using the Embarcadero C++ compilers in current Boost. I have reported a number of bugs, based on my Boost testing, for the Embarcadero C++ compilers to Embarcadero themselves in their bug reporting system. I believe that any registered user of their free community edition can report bugs to Embarcadero C++ at their bug reporting system at https://quality.embarcadero.com. Hopefully these reports will improve the compilers. It would really be nice, once the Embarcadero C++ clang-based compilers are integrated into current Boost, if regression testers could test their compilers. I will try to do so myself if I have the time and resources. I have discussed this with some Embarcadero C++ representatives about adding the Embarcadero clang-based C++ compilers to one or more CI testing services, but currently there are not any which support them of which I know. Besides the clang-based Windows compiler Embarcadero also has clang-based C++ compilers for 32-bit and 64-bit iOS ( Apple ) and for Android ( Google ). The code in Boost Config distinguishes between these environments, if necessary, with further macros based off of the mnemonic BOOST_EMBTC. It would be nice to add these configurations to embarcadero.jam once the rest of the work is done. But I have no idea how to test any of these other compilers as they are not part of the Windows based Embarcardero C++ Builder Community Edition.

2 4

[review] [LEAF] LEAF Review Starts May 22
by Michael Caisse 01 May '20

01 May '20

The Boost formal review for LEAF (Lightweight Error Augmentation Framework) will take place May 22, 2020 through May 31st. LEAF is brought to us by Emil Dotchevski, the author of Boost.Exception. Similar to Boost.Exception, this library allows arbitrary error objects to be returned; however, unlike Boost.Exception it does not require dynamic memory. The library can be used with or without exception handling. Error handling is such an import part of every software system. LEAF provides a unique solution to the problem. The excellent documentation can be found here: <https://zajo.github.io/leaf/> and includes a tutorial, examples, reference, design rationale, and comparisons to other error handling approaches/libraries. The source is available at github. The review branch will be used during the review period. <https://github.com/zajo/leaf/tree/review> The purpose of this announcement is to give people some time to start looking at the documentation and source code for the library. Feel free to begin asking questions. Most of all, get involved! Everybody has some experience with handling errors. Tell the Boost community what you think of LEAF. Thank you for your participation! michael -- Michael Caisse Ciere Consulting ciere.com

3 2