- Boost-announce - lists.boost.org

[gsoc17] Attn: We need 2017 mentors and project ideas for Boost!
by Niall Douglas 07 Feb '17

07 Feb '17

Dear Boost community, We are now a few weeks from the beginning of Google Summer of Code 2017! Last year we had the big surprise of being rejected by Google as an org, the second time ever, on the basis that Google felt we needed a year off. Thanks to the quick actions of the Boost Steering Committee and IMC Financial Markets we managed to put together a "Boost Summer of Code" so the students with projects in progress would not be left stranded. Despite a fair few teething problems, I think that worked out okay. As part of filling in our application for 2017, we must supply to Google a list of potential GSoC mentors and potential GSoC projects for summer 2017 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/SoC2017 before *February 9th* would be an enormous help to getting us approved again this year and bringing to Boost another US$35,000 of Google funding. 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. The year before last we had more slots awarded to us by Google than we had good combinations of student and mentor, so we had to return slots which I believe has not happened here at Boost GSoC in at least a decade. That means that your project ideas have a better chance than ever of receiving funding if you can find a good student, 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.

1 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/

1 0

Boost 1.63.0 is released!
by Marshall Clow 27 Dec '16

27 Dec '16

Release 1.63.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1.63.0 You can also download directly from SourceForge: https://sourceforge.net/projects/boost/files/boost/1.63.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks to everyone who participated in this release. Thanks, --The Boost release team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

1 0

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

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

14 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/

1 0

Review period has ended for the Synapse library
by Edward Diener 12 Dec '16

12 Dec '16

The review period has officially ended for the Synapse library by Emil Dotchevski. I have received one e-mail specifying a review that will come sometime today and therefore will wait before making my decision as Review Manager for that review and Emil's possible response. I would like to thank all those who took part in the review during the review period, and Emil for responding to the remarks of those who have participated. I know another library will shortly begin its review, but I will not rush my final analysis and decision regarding Synapse and intend to make it sometime by the end of this week. Edward Diener, Review Manager

1 0

Synapse library review final 2 days
by Edward Diener 10 Dec '16

10 Dec '16

Today and tomorrow are the last 2 days of the review of the Synapse library by Emil Dotchevski. If anybody intends to review the Synapse library but cannot finish their review this weekend, but will be able to finish their review by this coming Monday, please e-mail me and I will take into account your review when making my decision as Review Manager. I encourage all those who are interested in signal/slot programming to look at Synapse and make a review. Synapse is a signal programming library, similar to Boost Signals2 and the signals-slots system in Qt. The main difference is that Synapse is non-intrusive: the address of any object of any static type whatsoever can be passed to synapse::emit to emit a signal. This makes it possible to emit Synapse signals from objects of third-party types as well as system objects (e.g. standard FILE pointers, HWNDs, etc.) or any other object that can be converted to a pointer. The library has been formatted to fit the Boost directory and namespace structure. To get Synapse, clone 'https://github.com/zajo/boost-synapse.git' into a directory called 'synapse' under your boost/libs directory. See the tutorial at 'http://zajo.github.io/boost-synapse/Tutorial.html', or read full documentation at 'http://zajo.github.io/boost-synapse/index.html'. You can also view the documentation locally from your clone of the library at boost/libs/synapse/doc/index.html.

1 0

Synapse library review ongoing
by Edward Diener 07 Dec '16

07 Dec '16

We are in our final 5 days of the review of the Synapse library. We have had some good discussions about Synapse for those willing to review the library, but we really need much more from those who are, or might be, interested. Without wishing in any way to limit reviews or discussions to specific topics I would like to suggest to those interested in the library that they might address soem of these particular questions about Synapse in their commenst or review: 1) Is the documentation understandable for programming with Synapse ? 2) Does the library successfully achieve what it says it can do, providing a non-intrusive signal/slot system ? 3) Is the Synapse syntax easy enough for a programmer to use ? 4) Does testing show that Synapse works with user's code ? 5) Is the design of the library clear enough and flexible enough to make working with it viable ? While I realize that much of the discussion has been about particular end-user's preferences for a signal/slot library or Synapse's way of doing signal/slot programming versus Boost Signals/Signals2, all important topics in a review, it would be helpful if reviewers or commenters would consider Synapse for what it does do, even if they might not personally find a use for it in their programming tasks. ----------------------------------------------------------------------- Synapse is a signal programming library, similar to Boost Signals2 and the signals-slots system in Qt. The main difference is that Synapse is non-intrusive: the address of any object of any static type whatsoever can be passed to synapse::emit to emit a signal. This makes it possible to emit Synapse signals from objects of third-party types as well as system objects (e.g. standard FILE pointers, HWNDs, etc.) or any other object that can be converted to a pointer. The library has been formatted to fit the Boost directory and namespace structure. To get Synapse, clone 'https://github.com/zajo/boost-synapse.git' into a directory called 'synapse' under your boost/libs directory. See the tutorial at 'http://zajo.github.io/boost-synapse/Tutorial.html', or read full documentation at 'http://zajo.github.io/boost-synapse/index.html'. You can also view the documentation locally from your clone of the library at boost/libs/synapse/doc/index.html.

1 0

Synapse library review starts today December 2
by Edward Diener 02 Dec '16

02 Dec '16

The formal review of the Synapse library by Emil Dotchevski starts today, December 2, and is scheduled to continue through December 11. This gives two full weekends and the week in between for the formal review. Synapse is a signal programming library, similar to Boost Signals2 and the signals-slots system in Qt. The main difference is that Synapse is non-intrusive: the address of any object of any static type whatsoever can be passed to synapse::emit to emit a signal. This makes it possible to emit Synapse signals from objects of third-party types as well as system objects (e.g. standard FILE pointers, HWNDs, etc.) or any other object that can be converted to a pointer. The library has been formatted to fit the Boost directory and namespace structure. To get Synapse, clone 'https://github.com/zajo/boost-synapse.git' into a directory called 'synapse' under your boost/libs directory. See the tutorial at 'http://zajo.github.io/boost-synapse/Tutorial.html', or read full documentation at 'http://zajo.github.io/boost-synapse/index.html'. You can also view the documentation locally from your clone of the library at boost/libs/synapse/doc/index.html. Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[synapse]' 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 'eldiener at tropicsoft 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? - 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. I encourage all programmers with an interest or knowledge of signal/slot processing to be part of the review or discussion of the Synapse library as your time permits.

1 0

Upcoming review of the Synapse library starting tomorrow
by Edward Diener 01 Dec '16

01 Dec '16

1 0