- Boost - lists.boost.org

Re: [boost] [release] 1.69.0 deadline for new libraries approaching
by Peter Dimov 24 Oct '18

24 Oct '18

> Robert Ramey wrote: > > On 10/22/18 10:19 AM, Peter Dimov via Boost wrote: > > > Marshall Clow wrote: > > > > > >> * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes > > > > > > OK... do we want CMake config files installed by 1.69 or not, then? > > > > I'd like to know this as well. If so, I presume that we can consider > > the Boost/CMake issues resolved and we can just move on from this? > > I doubt it. The CMake issue is much bigger than this. To expand on that: The Boost/CMake issues concern four scenarios: 1. CMake users who want to use a pre-built Boost from CMake, after installing it either with `b2 install`, as usual, or via some other mechanism; 2. CMake users who want to use Boost (or an individual Boost library) from CMake without building it with b2 and installing it, but as a subproject, built by CMake; 3. Building and installing Boost with CMake, replacing the current Boost.Build building/installing infrastructure; 4. Testing Boost with CMake, replacing the current Boost.Build testing infrastructure. Installing CMake config files as part of `b2 install` falls into scenario number 1. Boost is still built with Boost.Build as always, it's just that in addition to libboost_foo.a, the user also gets libboost_foo.cmake, which allows him to do `find_package(boost_foo)` from his CMakeLists.txt file. Nothing more than that. This doesn't affect, doesn't target, and doesn't address, scenarios 2-4 at all.

8 25

boost-cmake and quickbook
by Raffi Enficiaud 23 Oct '18

23 Oct '18

On 23.10.18 21:29, Edward Diener via Boost wrote: > On 10/23/2018 2:36 PM, Robert Ramey via Boost wrote: >> On 10/23/18 11:17 AM, Peter Dimov via Boost wrote: >>> Robert Ramey wrote: >>> >>>> And I place the html and pdf versions into the repo so users don't have to build it. >>> >>> Placing the .html/pdf files into the repo is one - unquestionably modular - way to do it, but it does have its downsides. >> >> Both true. >> >> downside >> - "wastes" a lot of space >> - redundant - docs could get out sync with the code. >> >> >> upside >> >> - current documentation is always available to the user. In the two libraries of mine - documentation is an important part and I don't think the either would be usable without them. >> - only needs to be built on one machine no hassle for users >> - document build doesn't have to be "portable" >> - potential users can easily browse the documentation before they clone/download the package. This works well with github. I think this is very valuable - especialy for safe_numerics which most people don't actually see the need for. Call it a sales tool. > > I am sure you know that github already has support for viewing the documentation via the github io mechanism, so your last '-' item is not really applicable to your argument. > > My argument is simply that lots and lots of libraries use Boost Build to generate the docs, very often through the quickbook -> docbook -> pdf/html mechanism and unless we are going to continue to do it that way when Boost uses CMake we will eventually need a way to duplicate the Boost Build mechanism for creating the docs in CMake. > > Nonetheless I continue to believe that the move to CMake by Boost should be achieved in small steps, so that we can assure success in one step for all libraries before we even think about attempting the next. I still have the same fear that trying to accomplish everything at one time will mean that nothing really will ever get done. I only added item 5) to Peter's list because that is something we will eventually have to decide about. [sorry for multiple posting] Talking about small steps, feel free to copy paste this wherever you need it: https://github.com/raffienficiaud/boost-cmake/blob/master/boost-cmake/quick… I compiled Boost.Test documentation with this, this is fully cmake and it does the catalog generation on the fly. This is a small step, usually this is where collaboration starts, since I do not have all the knowledge of quickbook/docbook nor the bandwidth ATM. *But* if somebody is kind enough to assist me on this, in particular explaining me if we would want --stringparam chunk.first.sections "1" --stringparam chunk.section.depth "4" --stringparam generate.section.toc.level "3" --stringparam html.stylesheet "boostbook.css" --stringparam toc.max.depth "3" --stringparam toc.section.depth "10" to be exposed when compiling a documentation, or how to run the doxygen part, then porting things to cmake will be definitely faster. Raffi _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[preprocessor] vc++ using the experimental preprocessor
by Edward Diener 23 Oct '18

23 Oct '18

I have updated on the 'develop' branch Boost PP code that will use the vc++ C++ standard conforming preprocessor in VS2017 15.8 and above, as explained at https://blogs.msdn.microsoft.com/vcblog/2018/07/06/msvc-preprocessor-progre…. The code essentially treats vc++ in this mode as a strictly standard conforming preprocessor. There is the switch of /experimental:preprocessor which turns on the new preprocessor for the end-user, else the normal non-standard vc++ preprocessor is still the current default. BTW I tried to post a comment to the link above, explaining that the test posted in the article for the new preprocessor was wrong, but for whatever reason it never was actually posted as a comment. Nonetheless I got it right for myself in the Boost PP code in its config.hpp, so I am not going to worry about the fact that others may use the erroneous test in the article in their code. The change I made to Boost PP does not affect any other compiler, including vc++ in normal non-standard preprocessor mode. I have no idea if any regression tests for msvc-14.1 are made with this /experimental:preprocessor switch, but I will wait for 'develop' to cycle through before merging to 'master' in Boost PP. My preprocessor tests show four failures with the new vc++ preprocessor. Two of the failures are based on the fact that the test code expects a macro called with the wrong number of arguments to produce a compiler error and not just a warning. But since I have been told, vis-a-vis the same situation occurring for the Oracle C ++ compiler, that compilers are allowed under the C++ standard to produce a warning and just "chug" on, even if producing macro output that is certainly not what the programmer intended, rather than produce a compilation error maybe I just need to eliminate those tests, as important as I think they are. The other two failures are with the BOOST_PP_ITERATE macro and corresponding structures. The new preprocessor also erroneously continues to give a number of argument mismatch warnings in cases where it does not really exist, similar to the non-standard preprocessor, but since it "chugs" on despite the false warnings it ends up producing the correct output anyway. I have already posted a bug report about the fact that the new preprocessor gives a warning and continues when a macro is called with the wrong number of arguments. The other problem with BOOST_PP_ITERATE will be harder to determine because the iterate mechanism in Boost PP is fairly complex and I will need to figure out what is causing it and reduce the failure to a much simpler form in order to report it. As far as the compiler warnings of the wrong number of arguments when they do not exist, again I will have to try and figure out why and report the bug(s) to Microsoft. If anyone wants to try this out on Boost PP 'develop' feel free to do so. You will need to invoke the msvc-14.1 toolset in Boost Build with the /experimental:preprocessor switch and you will need to upgrade VS2017 to 15.8 or above. You can tell whether you have succeeded invoking the Boost PP tests with the new preprocessor by looking at the run output of the config_info test. If the BOOST_PP_CONFIG_FLAGS() is 0x0001 it is the new preprocessor, else it is the default non-standard preprocessor (0x0004).

6 13

Invitation to join the C++ chat community!
by Vinnie Falco 23 Oct '18

23 Oct '18

All: Hi there. I would like to personally invite all of the Boost authors, participants on the mailing list, and interested parties to join the most popular C++ Slack workspace, where many lively technical discussions related to C++ and its ecosystem take place. There are channels for everyone, especially the #boost channel, but also channels for WG21 committee discussions such as #future_standard and #wg21. There's even an #sg14 ! You can learn more and request a free invitation here: <http://slack.cpp.al> This workspace is sponsored by the C++ Alliance, a non-profit organization which promotes and advances the C++ language and provides educational resources. Find out more about the Alliance here: <http://cpp.al> Regards

3 5

Development Calendar is empty
by James E. King III 23 Oct '18

23 Oct '18

When is the next freeze or release? https://www.boost.org/development/index.html - Jim

5 5

[histogram] Finalising version for submission
by Hans Dembinski 22 Oct '18

22 Oct '18

Hi all, I have a general question regarding the submission process on how to deal with extensions of the library. I am currently working on the points raised in the review. Clearly, the bugs need to be fixed and the documentation improved where it was lacking. So the procedure is clear in that regard, but the final version to be included in Boost will also have more features, the main ones are: - support for profiles and in general arbitrary accumulators as bin "counter" types - in particular any Boost.Accumulator - allow arbitrary metadata (or no metadata at all) to be associated with the builtin axes types, instead of just supporting a string label (the metadata type will be a template parameter) - use axis types through a traits-interface to make adding custom axis types really easy (a minimal axis only needs to implement `int operator()(something) const` and `unsigned size() const`, everything else is optional) - use storage types through a traits-interface to allow arbitrary STL and Boost containers as storage backends - add a support library for typical calculations done with histograms, like reducing a high-dimensional histogram to a lower-dimensional histogram, shrink an axis, etc - growing axes that increase the number of bins while the histogram is filled I started working on these features and switching to C++14 would simplify the implementation a lot, thanks to generic lambdas and return type deduction. So I would like to raise the requirement for the final library from C++11 to C++14. Since these are substantial changes, is another formal review of the final version required? In any case, I will request informal feedback on the final version on the list before histogram is released with Boost for the first time. Best regards, Hans

5 10

[all] Hidden visibility is on by deafult
by Antony Polukhin 22 Oct '18

22 Oct '18

Good news everyone! I'd like to announce that now Boost libraries are build with hidden visibility by deafult. Many thanks to Andrey Semashev for providing the required patches and PR to fix some builds, and to Glen Fernandes for merging. Separate thanks to all the Boosters who reported/fixed visibility related issues.

3 2

[review][histogram] Histogram Review Results
by Mateusz Loskot 22 Oct '18

22 Oct '18

Hi Everyone, Please, welcome the Histogram library to the Boost collection! Thank you Hans for submitting a high-quality library for review. Thank you to the reviewers as well as those who just exchanged their comments on numerous aspects of the library and participated in the fruitful discussions. Among reviewers, we can recognise veteran Boost contributors and authors as well as experts in the fields of statistics, raster analysis, including authors of histogram-oriented software packages. ---------------------------------------- Official reviews and votes: ---------------------------------------- 1. Klemens David Morgenstern - ACCEPT 2. Jim Pivarski (off-list) - ACCEPT 3. Bjorn Reese - ACCEPT conditionally 4. Steven Watanabe - ACCEPT conditionally 5. Alex Hagen-Zanker - ACCEPT Non-review participations: 1. Andrea Bocci (off-list) 2. degski 3. Glen Fernandes (off-list) 4. Gavin Lambert 5. Seth 6. Mateusz Loskot ---------------------------------------- Acceptance conditions ---------------------------------------- Two reviews stated conditions which are important fulfilled: Bjorn Reese - Reference documentation is finalized Steven Watanabe - Various exception safety and memory issues must be fixed. - The reference documentation must be completed. Specifically, various preconditions, requirements, and assumptions must be made explicit. I believe those are not controversial at all and Hans is also interested in addressing those requests. ---------------------------------------- Concerns and comments ---------------------------------------- Jim Pivarski mentioned importance of profile plots as fundamental enough that they should be part of the feature set. In short term, the profile plots can be implemented as a new storage type, using the extension capabilities. Similarly, some concurrent applications would need atomic-valued bins, but these, too, can be storage types. Bjorn Reese pointed out some aspects of the design that makes the library not work very well with STL algorithms. Bjorn strongly recommended that the default storage policy is changed to remove some of those limitations. Steven Watanabe provided Hans with large number of very detailed comments and fixes (eg. do not call destructor which has been fixed), suggestions how to improve run-fail tests and serialization tests. Alex Hagen-Zanker commented that range-based for-loops support could be improved, suggested to provide separate ranges or views for certain histogram access scenarios. Another important theme of Alex' review was Histogram applicability for moving window type analysis. Then, Alex requested clarification on choosing variance based on the Poisson distribution instead of the binomial distribution. degski suggested to look for some "low hanging fruits" in C++14 and/or C++17, the library could potentially benefit from, pushing the 'modern C++' trait of the library even further. Gavin Lambert suggested to allow use of quantity types like Boost.Units. Glen Fernandes mentioned he would raise allocator model support issues or relaxing the requirement that the pointer must be a raw pointer of type value_type*. Glen mentioned he may even be available to help. Hans has already addressed many of the suggestions and issues or planned related features for future releases of the library. Issues resulting from the feedback received during the review can be tracked and further discussed on GitHub, labelled with boost-review: https://github.com/HDembinski/histogram/labels/boost-review ---------------------------------------- The Upsides ---------------------------------------- There were lots of great things said about the Histogram library: - design: excellent, clean, simple and extensible in principle - useful and well-designed features - geared towards readability and performance - very good documentation ---------------------------------------- Final Thoughts ---------------------------------------- Reviewers are worth their weight in gold nowadays. Once again, I'd like to thank all participants for great amount of quality feedback that already led to important improvements in the Histogram library in very timely manner - thank you Hans! The Histogram library is a valuable addition to Boost. Best regards, -- Mateusz Loskot Review Manager for the proposed Boost.Histogram

2 1

Re: [boost] Mail List Migration - Update
by Tom Kent 21 Oct '18

21 Oct '18

> > The Boost mail lists are now migrated to a new set of servers. > This change affected all mail lists and web resources (signing up, > changing passwords, moderator access, archives...) that were associated > with the domain lists.boost.org . > If you are having difficulties, please drop me an email. (Oh the irony) > Happy coding! > michael > -- > Michael Caisse > Ciere Consulting > ciere.com Michael- I've tried to send e-mail to a couple lists with boost over the past few days. On Tuesday, Oct 16, I sent an e-mail at 19:21 CDT to the boost(a)lists.boost.org list, "Non-ASCII Path Names in Repo" [1]. It seemed to take the better part of a day to be received by the list. I remember it taking a long time (>24hrs), but I can't prove that. However, if you click the previous message/next message links on [1], you'll see that both of those messages (including the one previous!) are timestamped several hours after mine. Now, as of Friday, Oct 19, at 06:59 CDT I had sent another e-mail, this time to boost-testing(a)lists.boost.org. As of writing this e-mail (07:35 CDT, Sunday Oct 21), it still hasn't shown up on the testing list [2], and I haven't received an e-mail saying that it was received by the list. Any thoughts as to what might be happening here? In the past (including earlier this month for boost-testing), I was able to post without issue from this address (lists(a)teeks99.com) to both of these lists. Thanks, Tom [1] https://lists.boost.org/Archives/boost/2018/10/243784.php [2] https://lists.boost.org/boost-testing/2018/10/index.php

1 0

Allow LICENSE file per a library repository (PR #374)
by Mateusz Loskot 21 Oct '18

21 Oct '18

Hi, I'd like to bring this proposal to the community's attention: https://github.com/boostorg/website/pull/374 BTW, from time to time, while I looking at various requirements I try to refresh those outdated and catch up with the reality. I take baby steps. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0