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

path length too long for 64 bits builds
by Vicente J. Botet Escriba 27 Oct '17

27 Oct '17

Hi, we have an issue since we have added threadapi= . On 64 bits windows machines we are seen Austin Beer said in https://github.com/boostorg/thread/pull/188#issuecomment-339829423 "FYI, the 64-bit Windows builds are failing due the unit tests exceeding the 260 character filepath limit on Windows. Every filepath includes |\msvc-14.1\debug\address-model-64\threadapi-win32\threading-multi|. Do you know if there is an easy way to shorten this? On the 32-bit builds the filepaths don't have |\address-model-64| which is just enough to keep them under the 260 character limit so they don't fail." Is there a workaround to this issue without changing the specific part of the test files folder structure? Best, Vicente

3 3

Boost::iostreams dual-use seekable filter
by Jonathan Biggar 26 Oct '17

26 Oct '17

I see dual-use filters and seekable filters, but I can't find an example of a dual-use seekable filter. Any help digging me out of template error heck would be appreciated.

1 0

Seems like I need write-access to merge a PR
by Fernando Cacciola 25 Oct '17

25 Oct '17

Hi, It's been a lifetime since I last worked on Boost, and I'm lost as to the current procedures with the repository. I've been looking into this open ticket: https://svn.boost.org/trac10/ticket/12972 and noticed this open pull request: https://github.com/boostorg/numeric_conversion/pull/7 but even though I'm logged with my Github account, it appears I don't have write-access to merge this PR. I tried the wiki but seems to have way too much information. Can you simplify the steps needed, these days, to fix a bug on a library? specially if someone else already created a PR as in this case? TIA -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com

7 17

Help wanted: Open pull request reminders
by Beman Dawes 25 Oct '17

25 Oct '17

As a library maintainer, I'd like to get periodic reminders of open pull requests for libraries I maintain and perhaps some other libraries I'm interested in. I'd like a email reminder, but others might prefer Slack or other forms of notification. A related need is for anyone to be able to find the total number of open pull requests for Boost as a whole, and perhaps get a sorted list of the per library counts. Or maybe we should just show today's count on the web site? Googling for "github open pull request reminders" shows that lots of others feel the same need. Would someone like to volunteer to review what others are doing to meet this need, and recommend an approach suitable for Boost? --Beman

9 12

Re: [boost] Boost.TR1 silently removed with 1.65?
by Guido Trentalancia 25 Oct '17

25 Oct '17

On the 9th of September 2017 19:38:43, Tim Rakowski <tim.rakowski_at_[hidden]> wrote: > Hi, > > I noticed that boost 1.65 does not contain the tr1 folder and found that > the documentation was updated accordingly: > http://www.boost.org/doc/libs/1_64_0/ contains > http://www.boost.org/doc/libs/1_64_0/libs/tr1/, while > http://www.boost.org/doc/libs/1_65_0/ has no > http://www.boost.org/doc/libs/1_65_0/libs/tr1/. > But http://www.boost.org/users/history/version_1_65_0.html > <http://www.boost.org/users/history/version_1_65_0.htmldoes> does not > mention this. > Even if it was deprecated, shouldn't this be mentioned somewhere? Googling > "site:https://lists.boost.org/Archives/boost/ 1.65 tr1" didn't yield > anything either :/ > Regards, > Tim Hello ! I am experiencing the same problem... Software packages using boost require the TR1 header files in order to build, but the TR1 header files are no longer available in version 1.65.1 ! What is going on ? Regards, Guido

5 5

[regression tests] feature request: UI integration of bjam requires clause
by Joaquin M López Muñoz 25 Oct '17

25 Oct '17

Hi, Boost regression tests as run by run.py can be explicitly disabled through two different mechanisms: 1. By marking the disabled toolsets with <mark-unusable> in status/explicit-failures-markup.xml. 2. By adding a requires clause in the corresponding Jamfile.v2 file. For instance, in Boost.PolyCollection C++11 is mandated through project : requirements [ requires cxx11_noexcept ] # used as a proxy for C++11 support ... (https://github.com/boostorg/poly_collection/blob/develop/test/Jamfile.v2 ), which results in non-C++11 toolsets being effectively disabled. The problem is that both mechanisms show very differently in the HTML report: http://www.boost.org/development/tests/develop/developer/poly_collection.ht… Toolsets disabled through markup appear grayed out wth a "n/a" legend and an (optional) link to an explanation of why the toolset doesn't work, whereas tests blocked by Jamfile's requires just show a blank column. Would it be possible to modify the regression test HTML reporting utility so that Jamfile-blocked toolsets show also as "n/a" in gray or something similar? The possibility of also adding a link to a custom explanation would be a boon, but I guess this is much harder. This would greatly increase the readability of the reports, particularly by non-savvy users who are likely to deem blank columns as just missing tests that might eventually be filled up. Many thanks, Joaquín M López Muñoz

2 2

Release Note responsibilites for maintainers
by James E. King, III 24 Oct '17

24 Oct '17

The upcoming release of 1.66.0 will be my first release in a maintainer role. How are the release notes generated and what are maintainer's responsibilities during each phase of the release cycle? Thanks, Jim

2 1

RFC.. Steering Committee Bylaws Proposal
by Rene Rivera 24 Oct '17

24 Oct '17

It has become clear to me, and some others, that the recent decisions of the Steering Committee have exposed various problems with how the Steering Committee operates. At CppCon I met with some of the Steering Committee and expressed the concerns with them. I also explained, from my experience in other organizations, how such issues are managed. The result of that is that I will be proposing the Steering Committee adopt operating Bylaws. But before formally presenting them to the Steering Committee I'd like get feedback on them <http://bit.ly/2hI22DN>[1]. The Bylaws hopefully address some key issues that I feel are at the core of the current problems: * Decisions can be made without input from interested parties. * Opaque selection of members. * No recourse by library authors to correct problems. This follows the original goals of the formation of the formation of Steering Committee of being transparent and responsive < http://bit.ly/2yoL5Ij>[2]. [1] <https://github.com/grafikrobot/other/blob/master/ bsc-bylaws-proposal/Boost%20Steering%20Committee%20Bylaws.md> [2] <https://github.com/grafikrobot/other/blob/master/ bsc-bylaws-proposal/2011-05-20%20Boost%20governance%20annotated.pdf> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

13 35

boost timer, warnings, backlog
by James E. King, III 24 Oct '17

24 Oct '17

I'm seeing a warning for use of "long long" in a lot of builds, originating in Boost.Timer. I like warning-free builds, so this is something I would like to see resolved. There's an issue in Boost Trac for it: https://svn.boost.org/trac10/ticket/12996 There's a pull request open since April for it (and 3 more going back a couple years): https://github.com/boostorg/timer/pull/4 Is this module still actively maintained? Thanks, Jim

5 6

[Outcome] WG21 papers of interest to Boost and Outcome
by Niall Douglas 24 Oct '17

24 Oct '17

This October's mailing has lots and lots of WG21 papers related to Outcome which were strongly influenced by the peer review here in May. Boost members who contributed to the Outcome v1 review in May should please take a bow and accept thanks for spurring so much discussion and debate regarding these potential future C++ features. Thank you. 1. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r3.pdf Utility class to represent expected object 2. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0650r1.pdf C++ Monadic interface 3. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0762r0.pdf Concerns about expected<T, E> from the Boost.Outcome peer review 4. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0779r0.pdf Proposing operator try() (with added native C++ macro functions!) 5. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0786r0.pdf SuccessOrFailure, ValuedOrError and ValuedOrNone types 6. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0824r0.pdf Summary of SG14 discussion on <system_error>: towards exception-less error handling Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0