January 2017 - Boost - lists.boost.org

Re: [boost] [root_ptr] Into consideration by Qt & QtQuickCompiler
by Mathias Gaunard 03 Jan '17

03 Jan '17

On 28 Dec 2016 2:32 pm, "Phil Bouchard" <philippeb8(a)gmail.com> wrote: Greetings, I did my homework and the Qt Project is considering root_ptr despite the fact that there is no paper written on it: http://lists.qt-project.org/pipermail/development/2016-December/028222.html So there is a big demand out there. I am not sure what else is required to find a review manager but everything is on a silver plate now. I don't understand how you can possibly interpret that reply as "big demand".

2 3

bad boost_1_63_0.tar.bz2 sha256sum
by jack nade 03 Jan '17

03 Jan '17

Expect beae2529f759f6b3bf3f4969a19c2e9d6f0c503edcb2de4a61d1428519fcb3b0 for https://sourceforge.net/projects/boost/files/boost/1.63.0/boost_1_63_0.tar.… Get a9eec759dd97798b06eb258a1c6ad4a39ff43b483594a22298ccdfae8116ce16

3 3

[trac] Boost v1.64 in the milestones?
by Raffi Enficiaud 03 Jan '17

03 Jan '17

Dear all, Since 1.63 is (almost) out, would it be possible to have 1.64 in the milestones of trac? Thanks, Raffi

7 15

Review quality (was: [stacktrace] review (changing vote to NO))
by Andrey Semashev 03 Jan '17

03 Jan '17

On Mon, Dec 26, 2016 at 3:58 AM, Vladimir Batov <Vladimir.Batov(a)constrainttec.com> wrote: > On 2016-12-26 10:41, Andrey Semashev wrote: >> >> Acknowledging the need for a particular functionality is not the same >> as accepting a particular implementation. > > Put bluntly users do not care about implementation. Please, don't speak for others. I, personally, very much care about implementation, and I can see other reviewers did take a look at the implementation as well. I think, making judgment on the library quality without regard to the implementation quality is irresponsible and short sighted. That kind of approach tend to result in "5 minute hack" solutions of obviously poor quality. But that's just my opinion. > They care about > functionality provided. I advocate giving the lib a "foot in the door". That > and far better feedback from the users will be a strong incentive for the > author to keep working and improving the lib. You seem to prefer > all-or-nothing approach. I believe it's unrealistic and bad. You might > disagree. First, nowhere in my message I advocated for "all-or-nothing approach". What I advocated for is a fair review, outlining all ups and downs of the library, and if the reviewer feels downs are significant enough, he would be right to vote for rejection. Second, it's not like the library does not exist before it is accepted. Users and the author have every opportunity to try the library in the field, if they want to. There is blincubator.com as well. >> By >> turning a blind eye on a design flaw of a presented library you're >> doing a disservice to the library author and the library users. >> Instead, by giving constructive feedback (positive and negative), >> especially if supported by real world experience, you help the library >> improvement. In fact, this (the feedback) is the most valuable reward >> for the author from the review. And let me say, there's nothing >> humiliating in having a library rejected during a review. > > Well, I do not get scolded often these days. So, it is quite "refreshing" to > learn that I am "turning a blind eye on a design" and "doing a disservice". > I thought I was merely expressing my humble opinion... but probably I got it > all wrong. Well, maybe you shouldn't have taken my message personally then. It wasn't meant to scold anyone. If anything, it was written with the intent to provide another (mine) perspective on what a review is and object to your notion of library review as being a humiliation. The last part, actually, was kind of offending from your side and what triggered my reply in the first place. > As for the feedback, then I do not see voting something useful "no" to be > much of a feedback. Indeed, the author does get initial feedback during a > review. However, not all of that feedback is constructive. Some valid, some > subjective, some capricious. After it's voted out the feedback is no more. The review entails a discussion. Some reviewers get convinced. Some review points get refined, and the author gets convinced. Sometimes review votes get changed. And it's not like the votes are final - the actual decision is taken by the review manager, and he can weigh the points made in reviews and discussion at his discretion. And it's not like the library disappears after the review. If it's interesting and useful, it'll have its users, and they will no doubt provide feedback. > Real valuable feedback will come when the lib is in Boost. People'll start > using the lib (I would) in their real projects asking for this and that. Real world usage produces valuable feedback, no doubt about that. But Boost acceptance is not a pre-requisite for real world usage. >> There are things that can be fixed post-review. >> ... >> There are other things that cannot be fixed easily and would probably >> require changing library design. Those changes often affect library >> API and usage patterns, which warrants the need of a new review of the >> reworked library. > > Yes, all that sounds wonderful... on paper. In real life as a user I'll take > what's available first. Then, if that is improved in the next version, I'll > take it gladly. If design changes and gives me more or fixes something, I'll > accept that. I doubt you'd be so easy to accept the changes if that required you to rewrite half of your code. :) > I do not remember Spirit transitioning from V1 to not > backward-compatible V2 being re-reviewed. I can be wrong though. I don't remember the review either. But Spirit v2 was added in addition to Spirit Classic (aka v1), which is still available in Boost. It was more like a new library was added. Should it have been reviewed? In my opinion, at least a mini-review should have been performed. Luckily, Boost.Spirit dev team has rich experteese in the domain and a lot of experience gained with v1, so v2 was a success. >> In those cases it's better to reject the library so >> that the new, improved version is presented later. > > Again, wonderful.. in theory. The reality IMO is different because 1) > "improving" is better with real user feedback that you deny to the author by > voting "no"; 2) "later" might never come as the review process is quite > exhausting/draining; not everyone wants to experience it again; you might > say "too bad for him"; I'll say it's bad for the user as well as they end up > with your good intentions and no library; 3) "later" might be too late as by > that time the user'll have something else in place. Again, it's not like the library doesn't exist outside Boost. If it fits you, go right ahead, so 1 is not true. But Boost does set a certain bar of quality, and the review process exists precisely to maintain that bar. And I'll take your 2 and 3 any time if it results in a high quality library in Boost. >> Consider also that whenever a library is accepted into Boost, the >> matter of backward compatibility appears. If the accepted library is >> somehow seriously flawed, that flaw may be difficult and painful to >> fix in the future. > > "difficult", "painful", "backward compatibility"... Come on. I am sure > you've been in the industry for a while, have "survived" many > upgrades/updates, etc. We all know it's not an issue. We update, adjust, > move on. Let's just say it can be an issue. On Mon, Dec 26, 2016 at 3:54 AM, Robert Ramey <ramey(a)rrsd.com> wrote: > On 12/25/16 3:41 PM, Andrey Semashev wrote: >> >> Consider also that whenever a library is accepted into Boost, the >> matter of backward compatibility appears. > > How so? Certainly there is no requirement that boost libraries support older > versions of C++ and/or compilers - and indeed many don't. I don't think I > see what you're referring to here. I think you misunderstood. I wasn't speaking of C++ versions backward compatibility. I was speaking of the library backward compatibility. AFAIK, making backward incompatible changes is still considered an undesirable practice. >> If the accepted library is somehow seriously flawed, > > Then of course it should be rejected. Of course reaching a concensus as to > whether it's flawed might not be so easy. Right, that was my point. >> [1]: http://www.boost.org/community/reviews.html > > I checked this page and don't see where it says anything relevent to your > points. Maybe you missed this section: http://www.boost.org/community/reviews.html#Comments <quote> Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. The goal of a Boost library review is to improve the library through constructive criticism, and at the end a decision must be made: is the library good enough at this point to accept into Boost? If not, we hope to have provided enough constructive criticism for it to be improved and accepted at a later time. The Serialization library is a good example of how constructive criticism resulted in revisions resulting in an excellent library that was accepted in its second review. </quote>

8 16

[sandia] Sandia-intel-16.0-c++11 is running in C++14 mode
by Andrey Semashev 02 Jan '17

02 Jan '17

Hi, Despite what the name implies, Sandia-intel-16.0-c++11 is actually running in C++14 mode. You can see there is -std=c++14 in the compiler command line: http://www.boost.org/development/tests/develop/developer/output/Sandia-inte… Could this inconsistency be fixed?

2 1

[Stacktrace] Review Manager report
by Niall Douglas 02 Jan '17

02 Jan '17

Firstly happy new year to everyone, and many thanks to all those who participated in the peer review of proposed Boost.Stacktrace before Christmas. I received the following formal reviews: 1. Vladimir Batov (YES) 2. Klemens Morgenstern (YES) 3. Andrey Semashev (NO) 4. Nat Goodspeed (YES) 5. Artyom Beilis (NO) 6. Barrett Adair (YES) Extensive comments without a formal acceptance recommendation were also made by: 1. Peter Dimov 2. Edward Diener There was a very noticeable lack of consensus on the strengths and weaknesses of the proposed library which has made summarising all these reviews into a coherent report with concrete conditions for acceptance very difficult. Antony also responded to many of the concerns throughout the review, agreeing with some points, disagreeing with others. I think this lack of consensus stemmed from multiple opinions on what a stacktrace library ought to provide: Minimum viable product: A portable backtrace() and backtrace_symbols() implementation with a C++ STL idiomatic API. The stack backtrace capture implementation must not allocate memory and be "fast". Note that backtrace_symbols() does NOT symbolise into strings containing source file name and line number. It also allocates memory (backtrace_symbols_fd() does not). Opinion 1: Portable serialisation of the stacktrace with instruction pointers converted to offsets into SO/DLL binary paths so a later external process can use those in combination with their debug symbols to retrieve source file names and line numbers. Ideally the serialisation formats supported would include those consumable by well known tooling for this purpose e.g. addr2line or llvm-symbolizer. Opinion 2: That Stacktrace can in process use debug symbols to retrieve source file names and line numbers. This could be implemented by invoking addr2line or equivalent as a child process which has the enormous advantage of being async safe, but has disadvantages in almost every other area. Or it could be implemented by one's own DWARF parser but with the huge caveat that memory could be badly corrupted by now. Opinion 3: That Stacktrace be "async safe" in that backtraces can be safely captured and parsed from a signal handler or SEH/TEH handler callback or point of C++ exception throw. *This implies no memory allocation during the execution of the handler*. >From the reviews, I think there is consensus that the minimum viable product is achieved in Stacktrace though many mentioned that improvements are needed to the documentation and most of the negative feedback was on features not in the minimum viable product described above. I therefore recommend the ACCEPTANCE of proposed Boost.Stacktrace into Boost with the following conditions: 1. That the documentation more clearly set out what Stacktrace does and especially does not do, and that the default facilities provided are those of the Minimum Viable Product described above i.e. no source file nor line number discovery, no external dependencies on libraries not always provided on the target platform, no invocation of child processes, no async safety during stacktrace parsing. Stacktrace ought to be pared back to the minimum viable product featureset with no external dependencies at all. 2. That suitable predefined macros opt in to additional functionality such as serialisation of offset translated backtraces, retrieval of source code path and line number etc. Enabling these may introduce dependencies on third party libraries not always present on a system such as libunwind, or on third party helper utilities such as addr2line. I would recommend that the APIs the use of which are dependent on such third party items are entirely compiled out of Stacktrace when the macro enabling them is not defined. 3. That the documentation describe ONLY the default minimum viable product functionality in its tutorial and quick start. All extra functionality enabled by macros is to be relocated into a separate documentation section away from the main documentation e.g. "Advanced/optional features". 4. That APIs made available only when a given macro has turned them on are documented as such in the API reference docs. I'd like to congratulate Antony on getting yet another library of his into Boost. I hope some of his magic rubs off on me when I bring Outcome to review later this year! Regards, Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 3

Re: [boost] documentation 1.63 not up to date
by Oliver Kowalke 02 Jan '17

02 Jan '17

Hello Daniel, I'm referring to http://www.boost.org/doc/libs/1_63_0/libs/fiber/doc/html/fiber/performance.… . The page should contain three tables (the one related to threads is missing) - my modification s date from end of November. Oliver Am 27.12.2016 1:35 nachm. schrieb "Daniel James" <dnljms(a)gmail.com>: On 27 December 2016 at 08:59, Oliver Kowalke <oliver.kowalke(a)gmail.com> wrote: > Hi, > could you update the documentation of boost-1.63 please - it is not up to > date. > For instance in boost.fiber commit 648de6a66544c5d03e5595cb25ed76 5ee0cd40d2 > (17.12.2016) is missing. > Thank you in advance, > Oliver The documentation on the website should just be whatever is in the release. It's a bit hard to know without a link to the page where that change is meant to be. I think what you're seeing on the website are the html files that are checked into git. I guess the documentation build isn't replacing them. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

3 4