- Boost - lists.boost.org

[Boost][BGL] What are the correct vertex/edge index types?
by hermann＠stamm-wilbrandt.de 15 Oct '24

15 Oct '24

First I looked in graph/test. Most times int is used there, only once std::size_t: property< edge_index_t, int > Next I looked into graph/example, same picture there. Ok, I read that example and test might contain stuff that would not go into BGL code. So I looked into graph/include/boost/graph: pi@raspberrypi5:~/graph/include/boost/graph $ grep edge_index_t *.hpp | grep size_t directed_graph.hpp: typedef std::size_t edge_index_type; undirected_graph.hpp: typedef std::size_t edge_index_type; pi@raspberrypi5:~/graph/include/boost/graph $ grep edge_index_t *.hpp | grep unsigned directed_graph.hpp: typedef property< edge_index_t, unsigned, edge_property_type > undirected_graph.hpp: typedef property< edge_index_t, unsigned, edge_property_type > pi@raspberrypi5:~/graph/include/boost/graph $ grep edge_index_t *.hpp | grep int graphviz.hpp: property<edge_index_t, int> > pi@raspberrypi5:~/graph/include/boost/graph $ Only graphviz.hpp uses int. But directed and undirected graph use std::size_t as well as unsigned. There are systems when unsigned is smaller than std::size_t: https://en.cppreference.com/w/cpp/types/size_t 1) Shouldn't at least directed_graph.hpp and undirected_graph.hpp make consistent use of std::size_t then? 2) Shouldn't examples and tests be corrected, as their overly use of int for edge and vertex index types is misleading? Regards, Hermann.

2 1

deprecated: MPL, foreach, typeof, ratio, chrono, assign, more?
by Vinnie Falco 12 Oct '24

12 Oct '24

Should one or more of these libraries be marked as "deprecated" in their corresponding meta/libraries.json? Array Assign Chrono Compatibility compressed_pair enable_if ForEach functional mem_fn move MPL Ratio ResultOf Typeof The new website could use this information to annotate the library. We could add a "reason" field to libraries.json which is displayed on the site. The website could have a checkbox, "hide deprecated", enabled by default. We could show the reason for the deprecation. For example, that mp11 is a more modern and functional version of MPL. Or that ForEach is now a C++ language feature. The authors and maintainers of those libraries would need to opt-in to this, although we could have someone work up pull requests for some or all of those libraries. There might be more libraries that belong on the list, feel free to add. Another idea we might consider is to add a preprocessor deprecation warning, unless the user opts-in by defining BOOST_ALLOW_DEPRECATED or something. Before we do that though, we should ensure that no non-deprecated Boost libraries are using the above libraries. Thanks

20 51

Do Tools Need Formal Reviews?
by Vinnie Falco 10 Oct '24

10 Oct '24

Traditionally, tools used by authors and maintainers are quietly integrated with oversight from owners and release managers. Examples include saxon-he and docca (https://github.com/boostorg/docca) Recently there have been noises made expressing the desire for the formal review process to be applied to tools as well. The purpose of this post is to explain why this is a bad idea. There are two kinds of tools. External tools, brought into use by the project through the scripts which create the release, and internal tools which are in repositories added to the superproject. An example of an external tool is asciidoctor: https://asciidoctor.org/ This was quietly added and the command line tool is required to be installed in order to build a Boost release, as libraries such as Boost.mp11 or Boost.Unordered need it for producing their documentation. The Asciidoctor author provides the installation package and provides all support. The only documentation requirement for Boost libraries is that they render into HTML and that "b2 doc" works. A formal review to adopt "asciidoctor" as an available external tool could result in REJECT. This serves no useful purpose other than to make things more difficult for the author or maintainer. They can still use asciidoctor but would have to do it locally and commit the resulting HTML output to the repository, as the tool would not be available to the release process. This is objectively worse for everyone. An example of an internal tool is BoostLook: https://github.com/boostorg/boostlook This is a set of CSS files and Ruby scripts used by some libraries to style their Asciidoctor documentation. This was quietly added to the superproject as the release will need it for some of the libraries to build. Discussion with owners happened beforehand; the files for this tool were originally in the website-v2-docs repo (https://github.com/boostorg/website-v2-docs) but the objection was made (rightly so) that the website-v2-docs repo was too large to add to the superproject. Thus the files were put into their own small repository. A formal review to adopt BoostLook as an internal tool could result in a REJECT outcome. This serves no useful purpose other than to make things more difficult for maintainers. They would manually inline the boostlook files in their repository and be responsible for keeping it up to date (submodules in libraries are intentionally not cloned by the release script). Tools are not user-facing (where "user" is defined as a Boost user and not an author or maintainer). I've seen a lot of intellectual gymnastics trying to justify why tools are the equal of libraries but they fail in light of an obvious fact: tools no longer in use can be removed from the superproject without a tsunami of mailing list protest. It is true that tools which Boost end-users find useful can be adopted, but they do not come with the same promise of forever support the way that libraries do. They are only supported to the extent to which the Boost libraries need them. My maybe-unpopular opinion: b2 was correct to move to an independent repository, as this can come with implied lifetime support. There's a recurring theme: tools are not libraries, despite Robert Ramey's sincere efforts to formally review them as such. A tool is an administrative construct designed to facilitate the efforts of authors and maintainers when they wish to make use of the tool in more than one library. The use of the tool is still possible in a Boost library, without the tool becoming part of the superproject, yet with more effort and opportunity for mistakes. It is for this reason that we do not use the formal review process for tools, as rejecting a tool has only disadvantages for existing libraries. The very last thing we need to do now is to make things harder for authors and maintainers. An argument used to justify a formal review is that the resulting feedback can improve the tool. I agree that feedback is generally helpful, this is true even if there is no formal review. That is, there is no requirement for a formal review to be ongoing for someone to provide feedback. Just provide the feedback. Tools are boring, and unlikely to attract a significant number of review responses. Formal reviews of proposed internal tools which receive a very small number of reviewers do not signal strong consensus and I believe harm morale. The informal process used for oversight on the internal and external tools Boost uses to produce its releases has worked well, and no convincing rationale has been put forth for why it should change. We should not invoke the formal review process for tools. Thanks

8 11

Who can fix CI ?
by hermann＠stamm-wilbrandt.de 09 Oct '24

09 Oct '24

5 days ago I created my first PR: "new planar_vertex_six_coloring() algorithm with examples, tests and doc" https://github.com/boostorg/graph/pull/387 CI helped me to fix things I was responsible for. But after that CI still fails in code I am not responsible for. From release notes: https://www.boost.org/users/history/version_1_86_0.html "...Graph: Major update: C++14 is the new minimum standard; this was partly dictated by dependencies (at least to C++11) and partly by choice. If you require support for an older standard, please contact the maintainer. ..." Somebody (who?) forgot to tell CI that minimum requirement. Example error caused by this: gcc.compile.c++ ../../../bin.v2/libs/graph/test/gursoy_atun_layout_test.test/gcc-5/debug/x86_64/cxxstd-11-iso/threading-multi/visibility-hidden/gursoy_atun_layout_test.o In file included from ../../../boost/math/constants/constants.hpp:11:0, from ../../../boost/graph/topology.hpp:16, from ../../../boost/graph/gursoy_atun_layout.hpp:34, from gursoy_atun_layout_test.cpp:10: ../../../boost/math/tools/config.hpp:28:6: warning: #warning "Boost.Math requires C++14" [-Wcpp] # warning "Boost.Math requires C++14" ^ In file included from ../../../boost/math/tools/mp.hpp:15:0, from ../../../boost/math/policies/policy.hpp:11, from ../../../boost/math/constants/constants.hpp:16, from ../../../boost/graph/topology.hpp:16, from ../../../boost/graph/gursoy_atun_layout.hpp:34, from gursoy_atun_layout_test.cpp:10: ../../../boost/math/tools/type_traits.hpp:208:12: error: 'std::is_final' has not been declared using std::is_final; Since this is my first PR, will there be someone helping me in PR 387? Who owns CI? Can issues be created against CI? Or do I understand this completely wrong? Regards, Hermann.

2 2

(no subject)
by Christophe Henry 08 Oct '24

08 Oct '24

> Should one or more of these libraries be marked as "deprecated" in their > corresponding meta/libraries.json? > > Array > Assign > Chrono > Compatibility > compressed_pair > enable_if > ForEach > functional > mem_fn > move > MPL > Ratio > ResultOf > Typeof Yes for marking old libraries as obsolete, as it does not convey a "might be removed" tag. No for marking as deprecated for this reason. Yes for hiding obsolete libraries by default. Strong no for ever even thinking of removing a Boost library from 1.x. Strong no for marking as obsolete libraries which are using obsolete libraries in the implementation. This one would force me to drop parts of MSM which might be used in production code and I strongly oppose the idea. Christophe

7 20

Scheduled review of Decimal library
by Mateusz Loskot 08 Oct '24

08 Oct '24

Folks, On behalf of the Review Wizards Team, formal review of proposed Decimal library has now been scheduled: - https://github.com/boostorg/website/pull/878 The review details should be soon displayed on the website - https://www.boost.org/community/review_schedule.html Best regards, Mateusz Loskot

4 6

[context] Build error with context-impl
by Tim Haines 08 Oct '24

08 Oct '24

git -c advice.detachedHead=false clone --branch develop --single-branch --depth 1 https://github.com/boostorg/boost.git git -c advice.detachedHead=false submodule update --init --recursive ./bootstrap.sh --with-toolset=gcc --with-libraries=context ./b2 -d+2 --debug-configuration --debug-building --debug-generator headers context-impl=fcontext toolset=gcc cxxstd=20 notice: found boost-build.jam at /boostorg/boost-build.jam notice: loading B2 from /boostorg/tools/build/src/build-system.jam notice: Searching <redacted> for site-config configuration file 'site-config.jam'. notice: Configuration file 'site-config.jam' not found in <redacted>. notice: Searching <redacted> for user-config configuration file 'user-config.jam'. notice: Configuration file 'user-config.jam' not found in <redacted>. notice: Searching '.' for project-config configuration file 'project-config.jam'. notice: Loading project-config configuration file 'project-config.jam' from '.'. notice: will use 'g++' for gcc, condition <toolset>gcc-11 notice: using gcc libraries :: <toolset>gcc-11 :: /usr/bin /usr/lib /usr/lib32 /usr/lib64 notice: using gcc archiver :: <toolset>gcc-11 :: /usr/bin/ar warning: toolset gcc initialization: can not find tool windres warning: initialized from project-config.jam:12 notice: using rc compiler :: <toolset>gcc-11 :: /usr/bin/as /boostorg/tools/build/src/build/feature.jam:327: in validate-feature from module feature error: unknown feature "<context-impl>" /boostorg/tools/build/src/build/feature.jam:361: in expand-subfeatures-aux from module feature /boostorg/tools/build/src/build/feature.jam:422: in feature.expand-subfeatures from module feature /boostorg/tools/build/src/build/build-request.jam:20: in apply-to-property-set from module build-request (builtin):-1: in sequence.transform from module sequence /boostorg/tools/build/src/build/build-request.jam:32: in build-request.expand-no-defaults from module build-request /boostorg/tools/build/src/build-system.jam:778: in module scope from module build-system The feature is present: grep -A5 -n "feature.feature context-impl" libs/context/build/Jamfile.v2 52:feature.feature context-impl 53- : fcontext 54- ucontext 55- winfib 56- : propagated 57- composite I'm not familiar with the Jam DSL, so I'm not sure how to debug this further. Any advice is very welcome. Thanks. - Tim

2 2

[Boost] runtime+memory evaluation of 6 BGL planar graph algorithms
by hermann＠stamm-wilbrandt.de 06 Oct '24

06 Oct '24

Half a year ago I copied together Boost examples making use of: boost/graph/make_connected.hpp boost/graph/make_biconnected_planar.hpp boost/graph/make_maximal_planar.hpp boost/graph/boyer_myrvold_planar_test.hpp boost/graph/planar_canonical_ordering.hpp boost/graph/chrobak_payne_drawing.hpp I added "read_leda_graph()" for processing graph files. And added code to write a graphiviz file from the generated straight line drawing. Use of "layout=neato" with fixated vertex coordinates with exclamation mark (pos="3,2!") misuse GraphViz to just draw the BGL determined straight line drawing. I did evaluation on random maximal planar graphs with 10,000 up to 100 million vertices in 10x steps. In 1993 I wrote a technical report on how to create maximal planar random graphs. I published the 1994 code two years ago (self written graph lib, not LEDA nor Boost): https://github.com/Hermann-SW/randomgraph All details of the evaluation including runtime table in this "straight_line_graphviz.cpp" gist comment: https://gist.github.com/Hermann-SW/99d151a273d290ee0d843c79b2da26a8?permali… Total runtime factors are 13.5x and 20.9x between 1, 10 and 100 million vertex graphs. Since the input graphs were maximal planar, the algorithms make_connected / make_biconnected_planar and make_maximal_planar did not have much to do. The resident RAM usage is perfectly linear, 2.8 / 28.1 / 281.4 GB for 1 / 10 / 100 million vertices. 100 million vertices, 300 million edges, edge property, planar ordering, planar straight line drawing and 8 byte storage for numbers on 64bit OS cause a factor of 2800 comparing resident RAM used with number of vertices. Regards, Hermann.

1 0

Scheduled review of MQTT library
by Mateusz Loskot 06 Oct '24

06 Oct '24

Folks, On behalf of the Review Wizards Team, formal review of proposed MQTT library has now been scheduled: - https://github.com/boostorg/website/pull/877 The review details should be soon displayed on the website - https://www.boost.org/community/review_schedule.html Best regards, Mateusz Loskot

2 4

[optional] Feedback on the range interface for Boost.Optional
by Andrzej Krzemienski 05 Oct '24

05 Oct '24

Hi Everyone, I have just recorded the following message in the Mailing List. sob., 14 wrz 2024 o 02:44 Alan de Freitas via Boost <boost(a)lists.boost.org> napisał(a): > - As people seem to imply, the WG21 issue goes way beyond the motivation > behind the proposals or the difficulty behind the Boost review process. Not > all Boost libraries are intended to go through WG21. Not all WG21 proposals > would make good Boost libraries (like begin/end iterators for > std::optional). We are in the process of implementing the range interface for Boost.Optional, as proposed in P3168R2 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3168r2.html> and to the extent possible in C++11. I would like to hear opinions from the people in this list, on if and why this would be a bad idea. Regards, &rzej;

9 18