- Boost - lists.preview.boost.org

Re: [boost] [synapse] Synapse library review starts today December 2
by Barrett Adair 12 Dec '16

12 Dec '16

On Fri, Dec 2, 2016 at 8:19 AM, Edward Diener <eldiener(a)tropicsoft.com> wrote: > - What is your evaluation of the design? I don't know anything about Signals2, but I find the "non-intrusive" argument to be compelling. I don't like that the invocation mechanism is single-threaded by default. I think the thread_local approach is interesting, but it sounds ripe for confusion in application code. > - What is your evaluation of the implementation? This code style is quite foreign to me, but it seems consistent. The mix of Boost and std libraries seems arbitrary (e.g. boost::shared_ptr and <thread>). The Boost.Function dependency appears redundant. The callback is effectively being erased twice. std::invoke or equivalent could serve as a replacement. I don't much like signal_traits.hpp and the limitations it imposes. Arity is capped at 4 parameters, and the signal type must be passed explicitly. The latter is surely good for compile times, but I think it would be nice to have a deduced signal type version that could still support stateful lambdas and member functions. I browsed the test cases, and they seem rather in-depth. I think some comments in this code are warranted. > - What is your evaluation of the documentation? The tutorial is very well done. Overall, the documentation is very solid. I enjoyed reading it. Quickbooks and syntax highlighting would be nice. This line was disappointing: "requires compiler support for the following C++11 features" I have seen this in existing Boost library documentation, so there is precedent, but I do not like it at all. I much prefer to see a range of tested compiler versions, even if it's only a couple. Continuous integration services like Travis and Appveyor are free, and very useful toward this end. > - What is your evaluation of the potential usefulness of the > library? It appears that it could be useful to Qt users. I personally would not find this useful. > - Did you try to use the library? With what compiler? Did you > have any problems? I ran the logger example with GCC 5.3 on Ubuntu 16.04. No problems. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? 4 hours combined of reading the documentation and playing around with the implementation code. > - Are you knowledgeable about the problem domain? My experience with C++ signal libraries is limited. I am comfortable using the Intel TBB flow graph library, which has some degree of overlap. I have a bit of experience with event-driven programming in other languages. I am knowledgeable about C++ callable types and compiler support for their variations. > - Do you think the library should be accepted as a Boost library? This is my first formal review participation, I don't have a library in Boost, I'm not familiar with Signals2, and I do not have a use case for Synapse, so I'm not going to answer this question. Please consider this message as a "technical comment" instead. P.S. For whatever it's worth, I did fork the Synapse code and implement tentative variadic support in connect.hpp and emit.hpp (though I did not get around to translate.hpp). https://github.com/zajo/boost-synapse/compare/master...badair:master It appears to work as-is with the logger example, but similar work would need to be done in translate.hpp to make it fully variadic. I used my proposed CallableTraits library with the intention of implementing deduced signal types, but I ran out of willpower. Please forgive the aggressive formatting.

2 1

Boost.IOStreams mapped_file_sink missing flush() functionality
by AB 11 Dec '16

11 Dec '16

Hello, I wish to bring to your attention two issues regarding mapped_file_sink from Boost.IOStreams (release 1.62.0): 1. There is no member function `mapped_file_sink::flush()` which I would like to use in my program. I believe it could be implemented portably by using `msync()` for POSIX and `FlushViewOfFile()` for Windows; was the omission of this function a deliberate choice or a minor oversight? 2. The member functions `begin()` and `end()` are implemented for mapped_file_sink but are not documented! This will lead to programmers relying strictly on the docs to use `data()` and `data()+size()` instead. Please update the documentation for the next release 1.63.0.

3 3

[1.63.0] Master is closed for beta release + release notes
by Daniel James 10 Dec '16

10 Dec '16

Hello everyone, The master branch is now closed for the beta release. Please can you add any remaining entries to the release notes, either by emailing me, or by creating a pull request at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_63_0.q… To do so, click on the little pencil icon at the top right of the code. thanks, Daniel

4 3

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

[stacktrace] Prereminder of Boost.Stacktrace review starting 14th
by Niall Douglas 10 Dec '16

10 Dec '16

I know we are all likely feeling a bit of tired of reviewing potential new Boost libraries, but I just wanted to remind everyone that Antony's Stacktrace library will start its peer review this coming Wednesday Dec 14th with the review lasting until just before Christmas, Dec 23rd. I appreciate this reminder is a little early given the Synapse review doesn't finish until tomorrow, but today I have the time to do email using both hands, and I likely won't get the time again until next weekend (newborns force a lot of single handed typing with your neck twisted hard to the side. Very slow). Edward I hope this doesn't get in the way of concluding your very interesting review. Antony's Stacktrace library adds a long overdue facility to Boost, a formal portable API for obtaining and parsing the call stack of a thread of execution. It has three user selectable backends, tries to provide a maximum performance (nomalloc) stack capture and I think by now can serialise stacktraces to storage. I'll be honest in saying I sent a long list of fairly strong concerns I had with the design and implementation to Antony last month, but I'll defer in the review to whatever the community votes (increasingly me and the Boost consensus seem to be diverging on what makes for good design and practice). I'll make the formal review announcment on Wednesday, but for those wanting to get started early go to: Github: https://github.com/apolukhin/stacktrace Docs: http://apolukhin.github.io/stacktrace/index.html Regards, Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

[fusion] Compilation errors on Intel compiler (C++14)
by Andrey Semashev 08 Dec '16

08 Dec '16

Hi, I'm seeing compilation errors coming from Boost.Fusion headers on Sandia-intel-17.0-c++14: http://www.boost.org/development/tests/develop/developer/output/Sandia-inte… Notably, the same tests compile fine in C++11 mode on the same compiler, which makes me think that is related to C++14 mode specifically. Looking at the code, it seems the compiler makes constexpr functions implicitly const-qualified even though it shouldn't in C++14 mode, so it's likely a compiler bug. Still, is it possible to add a workaround?

3 3

Solaris Boost Install headaches
by Paluzzi, Aaron 08 Dec '16

08 Dec '16

Hello, I'm currently banging my head against a Boost install on Solaris 10 Sparc. I started with a 1.57 download and install. This had mild success using the "Getting started" documentation with some compilation errors. I've been asked to upgrade this to 1.62, and now I'm getting errors as follows when I run ./bootstrap.sh $ ./bootstrap.sh -n Building Boost.Build engine with toolset ... Failed to build Boost.Build build engine Consult 'bootstrap.log' for more details In the Bootstrap.log file I get the following: ./build.sh: syntax error at line 135: `machine=$' unexpected I've been unable to find any further documentation on this error. Any assistance would be appreciated. Actually an in depth install guide for Solaris would be appreciated. I've had no issues on Windows, but Solaris is giving me migraines.

2 1

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

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 07 Dec '16

07 Dec '16

>boost.asynchronous looks to have many of the same features/functionality as HPX. >Can I ask why you chose to reimplement futures/lightweight thread pools/parallel STL/etc, >rather than working on improving HPX to suit your needs? I don't think the libraries have the same goals (or at least it seems to me so). Asynchronous is first of all an architecture tool focusing on organizing a whole application into thread worlds. The libraries also do not have the same design / tradeoffs. Asynchronous can make use of futures but encourages callbacks and tries to make these as safe as possible. The goal is to be as asynchronous (meaning non-blocking) as possible. It is no coincidence that I'm also the author of Boost.MSM. The encouraged design is a whole lot of state machines, each in its own thread (possibly sharing a thread), sending tasks to threadpools, TCP connections, etc. and waiting for callbacks. Future-based designs do not mix well with state machines' run-to-completion. The reason for the non-blocking focus is that I'm using the library at work in an industrial 24/7 application. When working on the production line, blocking is a disaster. If an algorithm goes astray, or simply takes longer than usually, blocking the production line results in huge costs. Crashes due to races also. Asynchronous provides ways to avoid both. >JB >Disclaimer : I have contributed o HPX, but I'm not one of the "German HPC Guys" :) . No hard feeling. I'm grateful for participation and the chance to explain the underlying ideas of the library. Thanks, Christophe

4 25

[serialization][test] failures in serialization causing regressions
by Barend Gehrels 06 Dec '16

06 Dec '16

> The regression matrix in develop of Boost.Geometry contains many new > compilation failures due to: > > > 1) : D:\t08\run\boost_root\boost/serialization/array.hpp(25) : error C2039: 'array' : is not a member of 'std' > > 2): > ../boost/numeric/ublas/storage.hpp: In member function ???void boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&, unsigned int)???: > ../boost/numeric/ublas/storage.hpp:331:18: error: ???make_array??? is not a member of ???boost::serialization??? > ar & serialization::make_array(data_, s);and a > > > The master is still OK. > > Can this be solved? Ping! This is still the case! Robert, can you explain this? It is (of course) not only geometry failing, also ublas or (if there are) other libraries with ublas dependencies: http://www.boost.org/development/tests/develop/developer/numeric-ublas.html All yellow! Thanks, Barend

3 8