October 2018 - Boost - lists.preview.boost.org

[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

Re: [boost] Fwd: Installing CMake configuration files
by Peter Dimov 20 Oct '18

20 Oct '18

Steven Watanabe wrote: > Just a couple comments: ... > * I'm not fond of the ROOT parameter for boost-install.boost-install. > * Dependencies can be referenced with /boost/$(deps)//[stage|install] > * You can find the full path to the boost-install.jam with > [ path.root [ modules.binding $(__name__) ] [ path.pwd ] ] > This avoids hard-coding the location of boost_install relative > to the superproject. Actually, [ modules.binding $(__name__) ] seems to return an absolute path, so path.root/path.pwd may not be needed here? boostcpp.jam does BOOST_ROOT = [ modules.binding $(__name__) ] ; BOOST_ROOT = $(BOOST_ROOT:D) ; which kind of implies that it relies on getting the absolute path. > * That just leaves the stage directory, which is tied to the > project root, and should perhaps be calculated in Jamroot > instead of in boost_install. The stage directory needs to be retrieved from boostcpp, but boostcpp just sets it to "stage", which only works from top-level. It should probably use $(BOOST_ROOT)/stage, and then other modules can peek for it. There are other things that are needlessly replicated - install-header-subdir, install-default-prefix. All of these need to be peekable from a canonical location. > * This seems to handle --layout=versioned, but I'm not clear on > how well it handles --layout=system where we expect to use a > single compiled library for all configurations. It worked when I tried it. Note that you can have two libraries with --layout=system, not just one; libfoo.a and foo.so. > * Are the error messages that you get from CMake when there > isn't a configuration that matches the request intelligible? Not very. There's Boost_DEBUG, which tells you why something was skipped, but ideally, it needs to detect the case when no variant matched, and _then_ tell you why things were skipped without your having to set Boost_DEBUG beforehand. I haven't gotten that far yet; usability can be improved once we have it working. > It looks like the target will exist but will silently do nothing? Yes, you get a link error. > What if something goes wrong and there are multiple matches? I haven't encountered this so far :-) although it's possible in principle because at the moment I ignore some "non salient" properties. > * If generate-cmake-config takes the library as a source, > then it's possible to derive both the library dependencies > and the exact library name from the library target. The > dependencies can be found at the virtual target level in > generate-cmake-config, and the exact file name will appear > as the source in generate-cmake-config-. Doing it this way > also has the side effect that the CMake configuration won't > be installed if the library fails to build, which may be a > good thing. These may take me a while to figure out. :-)

3 15

[asio] Issues piling up
by Vinnie Falco 20 Oct '18

20 Oct '18

There are issues which are years old which have been lingering in the Boost.Asio repository, and there are also old issues in the stand-alone Asio repository. It seems like these are being ignored, is there any strategy for addressing this? Examples: This one is going on a year: <https://github.com/boostorg/asio/issues/77> Two years: <https://github.com/chriskohlhoff/asio/issues/124> Thanks

10 16

Re: [boost] Fwd: Installing CMake configuration files
by Peter Dimov 20 Oct '18

20 Oct '18

> Yeah, I haven't been able to figure this part out. How do I pass the > $(sources) from generate-cmake-variant to generate-cmake-variant-'s > sources? The sources - in this case $(lib-target) go here, after `non-scanning-action`: local a = [ new non-scanning-action $(lib-target) : boost-install.generate-cmake-variant- : $(property-set) ] ; :-)

1 0

Installing CMake configuration files
by Peter Dimov 19 Oct '18

19 Oct '18

I've taken another stab at installing CMake configuration files along with the libraries in `b2 install`. CMake configuration files are .cmake files, typically installed into $prefix/lib or $prefix/lib/cmake, that allow f.ex. `find_package(boost_system)` in a CMakeLists.txt file to find the installed Boost.System library and declare a CMake target Boost::system that refers to it. CMake targets can then link to Boost::system and all is well. The work in its current state is available on the feature/cmake-config branch of the superproject: git clone --recursive -b feature/cmake-config https://github.com/boostorg/boost cd boost bootstrap b2 --prefix=... install After that .../lib should contain the libraries and .../lib/cmake - the config files. Then from CMake cmake -DCMAKE_INSTALL_PREFIX=... .. as usual. See for example the test scripts at https://github.com/boostorg/boost_install/blob/master/.travis.yml#L60 and https://github.com/boostorg/boost_install/blob/master/appveyor.yml#L40 Since `b2 install` installs more than one library variant, the CMake configurations need to pick the correct one and to do so look at (a subset of) the FindBoost-compatible variables as described at: https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L122 Boost_USE_DEBUG_LIBS, Boost_USE_RELEASE_LIBS, Boost_USE_STATIC_LIBS, Boost_USE_STATIC_RUNTIME, Boost_COMPILER, Boost_DEBUG are honored and have the same meaning as in FindBoost. Boost_USE_MULTITHREADED and Boost_USE_DEBUG_RUNTIME are presently ignored, but probably shouldn't be. :-) The default of Boost_USE_STATIC_LIBS being OFF is a bit inconvenient on Windows, where without `--build-type=complete` our installation only gives you static libraries, and there are suggestions to respect it being ON or OFF, but when not set, to look at BUILD_SHARED_LIBS instead. Under the hood this represents a refactoring of the current centralized installation approach in which the superproject staged and installed the libraries on `b2 stage` and `b2 install`. Now the top level stage and install targets just delegate to each library's stage and install targets, which are responsible for staging/installing that particular library, its CMake config, and its dependencies. These library-level stage and install targets are created by the helper b2 rule boost-install, which already existed (in Jamroot), but is now much enhanced and lives in its own module tools/boost_install. In addition, a metalibrary libs/headers is introduced, which corresponds to the headers as present in a release (in subdirectory boost/) or as installed by `b2 install`. Its install target, in fact, installs the headers, and its stage target, currently empty, should probably assume the function of linking the headers (which at the moment also lives in Jamroot.) At some future point, when we decide to switch to releasing the headers in their original libs/$lib/include locations, the install target of a library will just copy that library's headers; but we aren't there yet. The header-only libraries are used from CMake by finding the package boost_headers and linking to the target Boost::headers. I've deliberately not done anything about Boost::boost and find_package(Boost), to allow FindBoost.cmake to delegate to the config files if present (when Boost 1.69/1.70 or higher is installed), while preserving backward compatibility (when 1.68 or lower is installed.)

6 13

test message - please ignore
by Robert Ramey 19 Oct '18

19 Oct '18

just to see if my newsgroup interface is working. Robert Ramey

1 0

[python] Checking Python version
by Edward Diener 18 Oct '18

18 Oct '18

How do I check the Python major version in code when using Boost.Python ? I know there is a way to do it through a preprocessor define by including the CPathon patchlevel.h file but I would rather not include low-level Python files if Boost.Python has some way of doing it.

2 1

[test] How to execute shell commands
by Mike Dev 18 Oct '18

18 Oct '18

As an extension to my previous question: Does the boost test framework provide an integrated mechanism to get the binary directory (the directory where the currently running test executable is placed) and/or the source directory (where the jam-file resides that defined the test)? Best Mike

4 5