- Boost - lists.boost.org

Re: [boost] [Boost] [Stacktrace] review
by Nat Goodspeed 21 Dec '16

21 Dec '16

On Wed, Dec 14, 2016 at 3:43 AM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: For your review you may wish to consider the following questions: > > - What is your evaluation of the design? > I'm generally pleased with the design. There's a documentation section "Exceptions with stacktrace" that discusses techniques for incorporating stacktrace data into your own exceptions. I see a real possibility for integration with Boost.Exception, perhaps even a mechanism to make BOOST_THROW_EXCEPTION embed the stacktrace at the throw point. This is not an objection to accepting the library, but rather a feature request for when we do. I do have a question about use of a template parameter to constrain the number of entries, rather than a runtime parameter. Presumably that's necessary to permit certain backend implementations to be async-signal-safe? (Whatever the rationale, a note in the documentation explaining it would be nice.) My objection to that is that apparently, with the present design, if I want to write a function that accepts any specialization of basic_stacktrace, that must itself be a template function. If I'm correct about the reason for using a template parameter, would it be reasonable to split the class into a non-template base class supporting all the methods, with a template subclass that provides the storage? The base class could store a (pointer, length) passed by the subclass constructor. Without having looked at the implementation, I expect that you wouldn't even need virtual-function dispatch: the only indirection would be through the data buffer pointer. That would even permit a subclass that provides dynamic storage, for async-signal-unsafe use. Then a processing function could accept reference-to-base-class and handle any stacktrace instance. > - What is your evaluation of the implementation? Sorry, I haven't looked at the implementation. > - What is your evaluation of the documentation? > Generally good. It could stand a cleanup pass; there are a few typos here and there. I do like that each method explicitly states both complexity and async signal safety. The description of the nullary frame() constructor says that source_line() will return both empty string and 0. > - What is your evaluation of the potential usefulness of the > library? > VERY! I want this. > - Did you try to use the library? With what compiler? Did you > have any problems? > No, I haven't tried to use it. (A deadline is coming up fast.) > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? > I read through the documentation. > - Are you knowledgeable about the problem domain? > I have occasionally used platform-specific tactics to try to achieve the same thing, on a couple different platforms. Each time it's been painful enough to make me wish that this problem were solved, once and for all. > And finally, every review should attempt to answer this question: > > - Do you think the library should be accepted as a Boost > library? > Yes I do. I would like to see the non-template base class, but that's not a showstopper: I would rather have this library without than not have it at all. As I mentioned, I would like to see integration with Boost.Exception. That just seems like a natural next step. I see further opportunities for integration with Boost.Context, Boost.Fiber...

11 121

Stacktrace library starts review today 14th Dec
by Niall Douglas 21 Dec '16

21 Dec '16

The formal review of the Stacktrace library by Antony Polukhin starts today 14th Dec and will conclude before Christmas. I appreciate we are likely a bit tired out from the many library reviews recently and of course it's Christmas, but given the lack of a portable way to work with stack backtraces, which you inevitably need to do eventually in any non-toy production application, Stacktrace needs your review! Stacktrace is an optionally header-only library providing four implementation backends, libunwind (POSIX only), windbg (Windows only), backtrace (from the C library on most POSIX implementations) and a null backend. At its very simplest it lets you capture the stack backtrace for the calling thread and to print it to a std::ostream& of your choice. The basic_stacktrace<> class quacks like a STL container of frame object instances. The rest of the API pretty much follows STL design principles for the most part. Use is therefore unsurprising. You can find the documentation at http://apolukhin.github.io/stacktrace/index.html and the github repo at https://github.com/apolukhin/stacktrace. Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[stacktrace]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 's_sourceforge at nedprod dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? Most of my personal concerns with this library are with the implementation and I would hugely appreciate feedback from others with substantial experience of using stacktracing "in anger" in non-trivial use case scenarios. - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome. Finally, thanks to Edward whose announcement of the Synapse library review I borrowed heavily from as I thought it very well structured. Hopefully the above is just as clear. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 21

Re: [boost] [EXTERNAL] Boost 1.63.0 Release Candidate 1
by Marshall Clow 21 Dec '16

21 Dec '16

On Tue, Dec 20, 2016 at 2:51 PM, Marshall Clow <mclow.lists(a)gmail.com> wrote: > On Tue, Dec 20, 2016 at 12:49 PM, Rene Rivera <grafikrobot(a)gmail.com> > wrote: > >> >> >>>>>> >> >>>>>> As I mentioned to Marshall, the results here: >> >>>>> http://www.boost.org/development/tests/develop/developer/ >> config.html >> >>>>> are >> >>>>> horribly outdated - are they actually being run and updated? >> >>>>> >> >>>>> >> >>>> It appears that all 'develop' tests are at least one week late if not >> >>>> much >> >>>> more. >> >>>> >> >>> >> >>> >> >>> I was not aware of the stalled results.. Investigating now. >> >>> >> >> >> >> I think Sandia testers on Darwin and Linux are cycling okay in both >> >> develop and master, there’s results up there from Dec 20th. Are the >> Sandia >> >> config test results wrong or unexpected? >> >> >> > >> > The latest results from Sandia that I can see are from 12th. The report >> > info[1] also says it was run last time on 12th. >> > >> > [1]: http://www.boost.org/development/tests/develop/developer/ >> index.html >> >> >> The report generation issue is now addressed. The results are current and >> show tests from today. >> >> > I see lots of new results for "master", but none for "develop". (yet) > > Interesting. This page: http://www.boost.org/development/tests/develop/developer/config.html shows new results, but this one http://www.boost.org/development/tests/develop/developer/summary.html does not. -- Marshall

3 3

[test] Really deactivate test
by Florian Lindner 19 Dec '16

19 Dec '16

Hello, I need to conditionally decativate tests and use a custom decorator for that, like that: virtual void apply(bt::test_unit& tu) { [...] if (std::find(_ranks.begin(), _ranks.end(), rank) == _ranks.end()) { std::cout << rank << " Disable, because of rank, test: " << tu.full_name() << std::endl; tu.p_default_status.value = bt::test_unit::RS_DISABLED; return; } } (i'm happy to provide full source code, if anyone is interested) As you can see it's deativated on some MPI ranks only. However, if a user uses -t "testname" it is activated again. Is there a way to really deactivate the test? Or delete it from the test tree? Thanks, Florian

2 5

[variant] gcc crash
by Igor R 18 Dec '16

18 Dec '16

Consider the following snippet (trying to compile with Boost 1.62): ///////////////////////////////////////////////////////////// #include <boost/variant.hpp> template<class Node> struct node1_type; struct var_type; using var_base = boost::variant<int, boost::recursive_wrapper<node1_type<var_type>> >; template<class Node> struct node1_type { Node child; }; struct var_type : var_base { using var_base::var_base; }; int main() { var_type v1 = 1; } /////////////////////////////////////////////////////////////////// It crashes GCC: http://melpon.org/wandbox/permlink/A6BuYqqrG4COcfFl and produces compilation error with any released version of Clang: http://melpon.org/wandbox/permlink/1JQ7OVLV3crERRJX (Although it does compile with Clang-4 trunk). I'd appreciate if Variant maintainers could take a look at it. Thanks.

3 2

Re: [boost] [Boost-users] Stacktrace library starts review today 14th Dec
by Antony Polukhin 18 Dec '16

18 Dec '16

2016-12-15 3:44 GMT+03:00 Edward Diener <eldiener(a)tropicsoft.com>: > In the documentation for stacktrace I do not see anything about what level > of C++ is required for a compiler using the stacktrace library or any > information on what compilers have been tested when using the library. It's C++98. Tested on latest clang(c++03, c++11), gcc(c++98, c++11, c++1y), msvc. > In the section of "Build, Macros and Backends" I do not think there is > enough information about using a particular backend, other than saying that > you need to link with such-and-such. Does stacktrace "automatically" find > the header files it needs from these backends ? Even so I think some > information about where it looks for the backend header files need to be > given. I also think that some information of what libraries it looks to link > with needs to be given. I am assuming it links with the static versions of > these backend libraries unless I define either BOOST_STACKTRACE_LINK and > BOOST_ALL_DYN_LINK, or BOOST_STACKTRACE_DYN_LINK. What if I want to use the > header-only version but I want to link with the shared library backend ? I > also assume that if I link with the static library backend I should probably > be linking with the RTL static library, while if I link with the shared > library backend I should also be linking with the RTL shared library. > > What about 32-bit versus 64-bit use of stacktrace ? Do they both work as > advertised with the correct backends, whether static or shared ? I think the > "Build, Macros and Backends" need rto be expanded to cover alol these > topics. All the headers are found automatically and the library is header only if you do not define BOOST_STACKTRACE_LINK or BOOST_STACKTRACE_DYN_LINK. Backend is chosen automatically in header only mode. You need to do nothing, unless you encounter some problems on default setup (like you OS is POSIX but not LSB Core Specification 4.1) or unless you wish to disable stacktraces. If you define BOOST_STACKTRACE_LINK or BOOST_STACKTRACE_DYN_LINK you have to manually link with one of the backends. I'll try to improve the "Build, Macros and Backends" section to be more clear. -- Best regards, Antony Polukhin

3 3

[iterator][type_traits] A test is failing with gcc in c++03 mode
by Edward Diener 17 Dec '16

17 Dec '16

The zip_iterator_test_std_pair is failing with gcc in c++-03 mode. The problem reduces viqa Boost type traits to the fact that in gcc c++03 mode the expression: __is_abstract(std::pair<int&, std::string&>) where __is_abstract is a compiler intrinsic, gives an error of: error: forming reference to reference type 'std::__cxx11::basic_string<char>&' pair(const _T1& __a, const _T2& __b) ^~~~ Is this a valid error according to the C++ 2003 standard ? The test works in c++11 or c++14 mode.

4 8

Synapse library review result
by Edward Diener 14 Dec '16

14 Dec '16

The Decision --- -------- There were a total of 9 people, outside of the library author Emil Dotchevski, who reviewed/commented about the Synapse library during the review period and the Monday following where I accepted a late review and people's responses to that late review. The voting in the Synapse review is: 0 for YES 2 for NO, with one of the two a provisional NO. Among the other people who commented but did not vote I have 2 people who said they definitely liked the library and 2 people who said they definitely did not like the library. Among other commenters I interpreted 2 other people as probably approving of the library as it now is and 1 other person as probably not approving of the library as it now is. Given the actual YES or NO vote, and the small amount of people who took part in the review, and the even smaller amount of people who decided to vote YES or NO for the library, the Synapse library is NOT accepted into Boost. My decision as review manager is based on the review of the library by others and not on my own personal view of whether the library should be accepted or not. Issues ------ I want to use the next part of this decision to summarize the issues brought up largely, but not exclusively, by those who did not see the Synapse library as currently being worthwhile to become a part of Boost. This issues I summarize below may or may not be seen as relevant or not by others but they do represent the areas of criticism of the library made during the review. All the issues were answered by Emil during the review, and I think he did an excellent job of answering reviewers based on how he sees these issues. Some of these issues may be seen as unimportant or trivial or already well answered, but I want to list them all nonetheless. The issues are presented in no particular order of importance. I will refrain from making my own comments about these issues until my own general summary at the end of this review decision: 1) The current Boost signals/signals2 library is adequate for signal/slot processing and another signal/slot library such as Synapse does not provide enough of a usage argument to be added to Boost along with what already exists. 2) The documentation needs to be more expansive on the difference between Boost signals/signals2 and the Synapse library. 3) The end-user should have some sort of control where Synapse stores its information regarding the connection between signal emitters and slots ( signals handlers ). 4) Since Synapse is a C++11 library it should use C++11 standard library constructs across the board rather than their Boost equivalents. 5) There should be some "natural" way in which slots can return a value, ala the signals2 library. 6) A more flexible way of handling the slot lifetimes should be created as an addition to the shared_ptr/weak_ptr way the library currently employs. 7) A means by which a particular thread can be specified ( thread-affinity ) for a particular slot when connected should be created; or a dispatching mechanism, perhaps using asio, for connecting a slot to an emitter. 8) The ability to have signals emitted with more than four parameters should be created. 9) The fact that emitters are identified strictly by address was seen as a weakness in the design since at least theoretically, if not very often practically, it is possible for two different variables to have the same address. Connected to this is that the address of emitters is noted with a "void *" in the public interface, and that was criticized as not C++-like. 10) Connection objects should be movable rather than using shared_ptr. 11) The central dispatching mechanism is too slow for large scale continuous changes which emit signals to be handled by slots in some systems ( a stock market changes type of application was brought up as such an example ). 12) The use of only Boost function as a callable slot is too inflexible. 13) The signal type ( pointer to function whose return type identifies signals ) was seen both as cryptic and inflexible, and a deduced signal type was suggested. 14) Having more than one signal type in Boost in general was seen as a bad situation. 15) More specific information on which compilers should work with Synapse. Summary ------- First of all, thanks to everyone who participated in the review and for Emil for answering and providing explanations for his design and coding decisions. I cannot say it enough but I really hope that more people can be encouraged to look at libraries up for review and make comments, even if they do not want to make an official vote or comment on any particular area in which they do not feel they have adequate knowledge. All comments and personal or technical evaluations are important and help a review manager make a final decision, as well as telling a library author what others think of what he has done. With that said I will not try to hide the fact that I personally view the Synapse approach to signal/slot processing as different enough, and useful enough due to its non-intrusive nature, from signals/signals2 to be a valuable addition to Boost, even while I recognize that there was not enough of a consensus or enough of an interest among others during the review to have that happen now. Among the issue brought forth by others my personal view for possibly improving Synapse to where it might be more acceptable to reviewers and might draw more people's interest as a possibly Boost library in the future pending another review, lies mainly in these numbered issues above: 2), 4), 5), 7), 8), 12), 15). I also feel having the documentation discuss in more detail the major concepts of the library, as a bridge between the Tutorial and the Synopsis, would be very helpful for interesting programmers In Synapse. Of course other people's views may vary greatly, and further discussion of Synapse on the Boost developers mailing list or the Boost users mailing list is, I am sure, welcome to the author of Synapse Emil Dotchevski.

1 0

[root_ptr] documentation fix
by Phil Bouchard 14 Dec '16

14 Dec '16

Greetings, I just realized that root_ptr is "container-oriented" and therefore I added this information to the documentation: http://philippeb8.github.io/root_ptr/root_ptr/intro.html#root_ptr.intro.roo… I think this summarizes it all with these few keywords and at some point people will get tired of the garbage collectors and "click" ;) Sincerely, -Phil www.fornux.com www.finitetheory.com www.loaapu.com (in progress)

1 0

[synapse] Review
by David Sankel 14 Dec '16

14 Dec '16

On Fri, Dec 2, 2016 at 9:19 AM, Edward Diener <eldiener(a)tropicsoft.com> wrote: > > For your review you may wish to consider the following questions: > > - What is your evaluation of the design? > The design looks reasonable. > - What is your evaluation of the implementation? > I found the use of typedef's to functions returning inline struct definitions to be overly clever and cryptic to new C++ developers. I also found the lack of static type checking in certain places to be objectionable. The unusual formatting is an important subjective turnoff to potential users. Presumably the goal of the library is to enable users to get the functionality they've been missing. The hurdle of a new formatting style to get used to goes against this goal. Fortunately, this is something easily remedied. > - What is your evaluation of the documentation? > Looked reasonable. > - What is your evaluation of the potential usefulness of the > library? > Given the prior existence of Boost.Signals I wouldn't find this library to be useful. There is an important aspect to this review that I want to call out. A signal is a "vocabulary type" in that it is pervasive through systems and frequently used in public interfaces. One of the most important qualities of a vocabulary type is that there be only one of them. Imagine the confusion if we had one thread-safe shared pointer class and another one optimized for single threaded usage, or if we had an suite of different variant types with different tradeoffs. No, there should only be one signal type and Boost.Signal made the correct choice of using a so-called intrusive design. - Did you try to use the library? > Nope. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? > I spent a few hours on the review. A small amount of time was reading the documentation and a much longer amount of time was spent pondering the implications of incorporating the library into Boost. - Are you knowledgeable about the problem domain? > Yes. I've used Qt signals, Boost.Signals1, and Boost.Signals2 extensively in various projects. > - Do you think the library should be accepted as a Boost library? > No. -- David Sankel

4 6