- Boost - lists.boost.org

[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

[gsoc18] SafeFloat proposal
by Damian Vicino 21 Jan '18

21 Jan '18

Hi, I added a proposal to get SafeFloat ready for review: https://github.com/boostorg/boost/wiki/Boost-Google-Summer-of-Code-2018#3-b… This was a project I started in gsoc2015 as student mentored by Robert Ramey. Please contact me if you are interested in further details. Best regards, Damian Vicino

2 1

Google Summer of Code 2018
by David Bellot 20 Jan '18

20 Jan '18

Dear Boost community, once again this year, we will apply to be a mentoring organization for the Google Summer of Code 2018. Our organization has been quite succesful for the last decade and this year we hope to be selected again. As part of filling in our application for 2018, we must supply to Google a list of potential GSoC mentors and potential GSoC projects for summer 2018 in order to be approved as an organisation this year. Therefore a lengthy page of awesome project ideas at https://svn.boost.org/trac/boost/wiki/SoC2018 before *January 23rd* would be an enormous help to getting us approved again this year and bringing to Boost another Google funding (worth dozens of thousands of dollars on average). If you think yourself able to mentor a student doing some work on Boost this summer, *please* consider adding a description of the proposed work item and your name to the list. If you want to have a better chance receiving funding for your project ideas, it is better to find good students early and that is best done by getting project ideas floated *early*. If you want to know more about mentoring a Google Summer of Code funded student work before you nominate yourself, please feel free to ask on the main Boost developers mailing list boost(a)lists.boost.org or via gsoc-admin(a)boost.org. Thank you in advance for your time. Finally, I would like to thank Niall Douglas, our previous Boost admnistrator for GSoC, who did an awesome work during many years and helped the Boost community grow thanks to all the funding we received years after years from Google. Best regards, David

4 9