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

23 Jan '18

While refactoring the test Jamfile for Boost.System, I wrote this rule: rule system-run- ( sources + ) { local result ; result += [ run $(sources) : : : <link>static : $(sources[1]:B)_static ] ; result += [ run $(sources) : : : <link>shared : $(sources[1]:B)_shared ] ; result += [ run $(sources) : : : -<library>/boost/system//boost_system <define>BOOST_ERROR_CODE_HEADER_ONLY : $(sources[1]:B)_header ] ; return $(result) ; } to avoid repeating each test three times. The inconsistency is somewhat annoying. We could normalize the third line by introducing a third link type, <link>header, in response to which the library can switch to header-only mode. This is more or less the same suggestion as Niall's _hl targets from the CMake discussion, but it fits Boost.Build better, because the <link> property is automatically propagated to dependencies. Furthermore, after thinking about it a bit, I think that we might even have room for a fourth link type, <link>source, in response to which the library target would pass an appropriate <source> usage-requirement upwards. (<source>error_code.cpp in Boost.System's case.) <link>source is kind of best of both worlds, as it doesn't reparse the source code each time the library is used, and at the same time is not prone to the ODR violations introduced by inadvertently compiling the library and the executable with different, ABI-incompatible options. Comments?

2 4

[git][releases] removing beta tags
by Raffi Enficiaud 22 Jan '18

22 Jan '18

Hi all, I would like to know if it is allowed to delete the git tags that are associated to beta releases (such as "boost-1.45.0-beta1"). Thanks, Raffi

2 2

[trac] email notifications?
by Raffi Enficiaud 22 Jan '18

22 Jan '18

Hi, Is trac sending email notification on comments and changes regarding tickets? It used to do so, but I am not receiving anything. I am asking because I am waiting for ppl to comment on the tickets for some time. If people do not receive email notifications, I think I will wait for ever. Thanks, Raffi

2 2

[trac] new versions of boost
by Raffi Enficiaud 22 Jan '18

22 Jan '18

Hi there, Would it be possible to add the next versions of boost to trac/milestones ? Thanks! Raffi

7 12

[system] Would it be possible to trial a breaking change to Boost.System and see what happens?
by Niall Douglas 22 Jan '18

22 Jan '18

SG14 the low latency study has been looking into how to improve some design decisions in <system_error>. The relevant WG21 paper is https://wg21.link/P0824 and recent discussion can be found at https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/j7tQybEjP5s. What we'd like to do is to test whether some very mildly breaking changes to <system_error> are so mild as to affect no users, and on that basis propose WG21 to make those mildly breaking changes to <system_error> in the next C++ standard. And to test this, we'd like to modify Boost.System with those mildly breaking changes, ship a release and see how many users complain. If it is zero, we have evidence for WG21 that this is not a consequential change. What we'd like to change is this: 1. Stop treating code zero as always meaning success irrespective of category. This remedies a defect where some custom error code domains cannot be represented by error_code due to using value 0 for an error. In actual code, I've never seen anyone ever use comparison to anything but a default constructed error code, so I think this will be safe. 2. Success becomes solely the default constructed error code, which is code zero and a new category of "null_category". This is internally represented by { 0, nullptr }, and thus makes the default constructor trivial which is highly desirable as it eliminates any compiler magic static fencing for the default constructor. Right now the default constructor uses system_category with value 0, and I suspect no code will notice this change either. 3, Make the default constructor constexpr, now possible. No code should notice a difference, except less runtime code will be generated. 4. error_code::message() returns a std::string_view instead of std::string if running C++ 17 or better. This lets us remove the <string> dependency, and thus stop dragging in half the STL with <system_error> which in turn makes <system_error> actually useful to the embedded systems crowd. The guess here is that std::string_view has such excellent interoperation with std::string that I think 99% of code will compile and work perfectly without anybody noticing a thing. I appreciate that this would undo Peter Dimov's excellent work at having Boost.System alias <system_error> under C++ 11 and later. I also appreciate that we are deliberately going to potentially break end user code. But my personal guess is that in practice, the breakage will not be noticed by 99% of code out there right now. It'll just compile against the improved Boost.System and everything will work as before. Boost was originally intended as an incubator for C++ standard changes. This ticks that box perfectly. Thoughts on feasibility? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

15 76

Travis CI Resources
by James E. King, III 22 Jan '18

22 Jan '18

Last summer we had a discussion about Travis CI Resource Usage for boostorg. Originally the discussion was about purchasing more resources; however the discussion quickly focused on finding the root cause of the backlog. The desire is to ensure that pull requests submitted to repositories are processed in a timely manner. This is not happening, and there is at least a 12 hour backlog on pull request builds for boostorg right now. Summarizing the discussion back then, it was proposed that the backlog was caused by folks working on feature branches directly in their boostorg repository, with the Travis CI setting enabled to "build branch updates". The proposed solution was to encourage everybody to fork their repository and set up their own Travis CI and Appveyor under their account, and work feature branches on your fork. If working alone, this is efficient for everyone as we all end up with faster builds because your account will not contend with boostorg for resources. So please, use your personal account to build up features if you can. Additionally, tuning your Travis CI build script to do a little bit less work will help. If you have a script that builds with gcc, gcc-5, gcc-6, gcc-7, clang, and cxxstd of 03,11,14,1z - for most libraries that are at the c++03 language level this is going to be significant overkill for use as a pull request gate. In the example above, there are 20 builds to do; double that if you build debug and release variants. If each build takes just 2 minutes that's still an 80 minute CI cycle. Please spend some time reviewing your practices around the use of the free CI resources we all share. Thanks, Jim

5 11

[config] Supporting newer compilers: what does it take?
by Olaf van der Spek 22 Jan '18

22 Jan '18

Hi, What does it take to support new compilers, especially MSVC? 15.6 Preview 1 has been released now. Is some documentation or policy regarding test runners etc available? https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-… Gr, -- Olaf

1 1

[gsoc18] RSS
by Greger 22 Jan '18

22 Jan '18

Got some code/idea for RSS. possibly an GSoC18 topic?anyone? br g

2 3

[bjam] Can I disable a test based on an environment variable?
by James E. King, III 21 Jan '18

21 Jan '18

I'd like to disable some serialization tests if I am running a ubsan build on travis. Is there a way in the Jamfile I can make it conditional on an environment variable, or should I define something like BOOST_DATE_TIME_UBSAN and put "if !defined" in the appropriate tests?

2 2

[gsoc2018] Dynamic Shortest Path Tree
by a.i＠acm.org 21 Jan '18

21 Jan '18

Hi, I am Donghyuk Kim, a Ph.D. Student at Korea Advanced Institute of Science and Technology. I tried to contribute something last year but was not able to start the project for some reason. So I am about to re-try again this year. What I would like to contribute is a specific algorithm, "Dynamic Shortest Path Tree" which is simply, a dynamic version of Dijkstra's algorithm. It is a tree-based data structure to maintain single-source to all destination shortest paths and known to outperform Dijkstra or A* where the insertion and deletion of vertex/edge frequently occur. The concept of "Dynamic Shortest Path Computation" was originally introduced in [Fully Dynamic Algorithms for Maintaining Shortest Paths Trees] by D. Frigioni, et al. (http://dl.acm.org/citation.cfm?id=338900) I have already implemented a working prototype for my research, but unit test, coding style unification, and much more c++ style modifications are required for the general purpose. I hope someone finds it interesting and be a mentor on this journey. Thanks in advance. Best Regards, Donghyuk Kim a.i(a)acm.org _____________________________________ Sent from http://boost.2283326.n4.nabble.com

2 1