November 2016 - Boost - lists.preview.boost.org

[process] Formal Review
by Raphaël Londeix 04 Nov '16

04 Nov '16

> > We encourage your participation in this review. At a minimum, kindly state: > - Whether you believe the library should be accepted into Boost > YES > * Conditions for acceptance > The interface used to spawn processes should be reworked. > - Your knowledge of the problem domain > I have implemented some process wrappers many times. I have used the last release of Boost.Process (0.5 I think?). > - What is your evaluation of the library's: > * Design > I think the similarity with the boost::thread api is a great choice. The lifetime of process is handled by small functors that will be called at specified times. I think is a very good design as it allows one to write small "plugins" in order to affect the setup or the tear down of a process. The integration with Boost.Asio follows the previous choice of using boost::thread as a reference, i.e. the child process is not the resource you read from/write to, you need some separate stream objects whose lifetime are tied to the child process: struct MyProcess { bp::async_pipe std_in; bp::async_pipe std_out; bp::async_pipe std_err; bp::child child; }; I haven't seen a way however to be asynchronously notified when a child exited, so I'm not sure how one would handle gracefully multiple async_read/write while the process could exit at any time. The choice of having a nice interface to spawn processes have been discussed already, but I still think that the library should aim to have the simplest and lowest level interface. IMO, C++ users do not need to have a nice and expressive syntax to spawn process, I cannot imagine a code base where many processes are launched at many places in the code. In other words, I think that either you rarely need to spawn a process (a hack for example), or your job is to spawn processes (a shell, a make clone, ...). In both cases, you will spawn processes in very few places in the code. Moreover, this interface style has an implication on build times, errors seen at build time and makes it hard to use in cases where your program needs to spawn processes based on runtime decisions. if one decided to implement a shell that supports redirections, pipes, environment modification and background jobs, they would certainly need to make runtime adjustments to the arguments given to child constructor. As of today, this has to be worked around by the user ; I think this should be the primary interface. A suggestion has been made to have a more idiomatic C++ construction, I would extend it with a specific options type: auto options = bp::options().args("gcc"); if (verbose) options.append_arg("-v"); if (ignore_errors) options.std_err.redirect(bp::null_device); bp::child child(io_service, std::move(options)); This way you make it impossible to modify the options after the child process creation. But that's just an idea :) * Implementation > The implementation is clear, but the support for the aforementioned constructor interface "leaks" into the implementation everywhere. As the previous version of Boost.Process, the different OS support is nicely separated and each stage of the process creation is clearly implemented in its own header. > * Documentation > The asynchronous section feels a bit short given the many possibilities the interface gives us. > * Tests > Didn't check > * Usefulness > I think it would be very useful to have something we can rely on instead of our own half baked implementations. > - Did you attempt to use the library? If so: > * Which compiler(s) > g++4.8 using c++11 > * What was the experience? Any problems? > I had many problems and decided to fallback on popen(). The first kind of problems were some compile errors. But the author kindly stated that I needed the HEAD of boost (which is not an option for me) but I found a workaround by not using some niceties of the interface: https://github.com/klemens-morgenstern/boost-process/issues/20 https://github.com/klemens-morgenstern/boost-process/issues/21 As said previously, for someone not used to boost.fusion, the errors are hard to read. The other problem that made me give up (temporarily) on using Boost.Process was the fact that asynchronous reads where unreliable when more than one process is spawned. https://github.com/klemens-morgenstern/boost-process/issues/22 This issue has been closed despite the fact that it is not fixed. - How much effort did you put into your evaluation of the review? > I'd say half a day counting this mail and the testing I made. Cheers, -- Raphaël Londeix http://hotgloupi.fr

2 1

[process] Formal Review
by Klaim - Joël Lamotte 03 Nov '16

03 Nov '16

Boost.Process Review ==================== ...At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance YES it should be accepted, though documentation need improvements. - Your knowledge of the problem domain I implemented naive and less naives ways to manage different processes in the past. I currently work on libraries which are all about multi-process communication and we have a poor-man's process management (launching, tracking, etc.) api that I have to maintain on Linux, Windows and MacOSX. I also have home projects which are organized as client-server with master-slave relationship, clients spawning servers and pinging them to keep processes alive mutually (using network communication). So basically, I implemented basic process management libraries, but I'm more a process management library user, in all my projects, paid or not. I have been exposed to a lot of problems related and solved a lot of them. I also used the last 2 Boost.Process versions proposed to Boost (though I voted no for these ones) but in cases where I just needed a cross-platform way to launch an arbitrary executable (no tracking nor communication). You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design The weird choice of variadic arguments in launching functions have been explained so I'm more at ease with it, though maybe ways to simplify it could be attemted in the future. I like that the design of boost::process::child follow, where it make sense, the design of std::thread. Both could be considered as execution resource, so it's fine to me that they share similar interface phylosophies of design (like spawning on construction and move-only). I would love it if there was a way (even slow) to track processes lifetime for processes that I don't have code for. Though it's ok for me if it's a future extension. I like the minimalism of the scope, though useful extensions could be added later. * Implementation I briefly eyescanned the code, looked more closely at the termination trigerriung code because of the discussion we had on termination reqest vs kill. I don't bother much about performance for this library as launching processes is rarely done in a tight high-performance loop. * Documentation I did a report of the documentation a few weeks or months ago, I do not know if changes have been made since. Anyway I think the documentation should have a part focused on explaining the concepts because even if most programmers knows what a process is, all related concepts (like what is the "environnement") are so specific to processes that they are often ignored as long as naive usage works. So as soon as the user need more specific usage, most, I believe, will not know what word to use to find the right concept. I think this library documentation should follow something similar to Boost.MSM which introduce to the basic concepts, though without walls of text. * Tests I didn't have time to try it yet in real applications, but so far didn't find any problem in basic usage. * Usefulness It is very useful for almost all my projects. - Did you attempt to use the library? YES If so: * Which compiler(s) Visual Studio 2015 for now. * What was the experience? Any problems? I only did minimal testing, nothing deep, no problems. - How much effort did you put into your evaluation of the review? Several hours diffused through several months. Joël Lamotte

1 0

[test] tests in master failing
by Aparna Kumta 03 Nov '16

03 Nov '16

I'm seeing the following error in the master branch compiling with Oracle Developer Studio. # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "/export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_regression_src/regression.py", line 287, in __init__ self.main() File "/export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_regression_src/regression.py", line 624, in main getattr(self,action_m)() File "/export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_regression_src/regression.py", line 589, in command_regression self.command_test() File "/export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_regression_src/regression.py", line 368, in command_test self.command_test_boost_build() File "/export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_regression_src/regression.py", line 410, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/results/boost/bin.v2/libs/any/test/any_test.test' Looking at the bjam.log file I see: /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/kernel/modules.jam:107: in modules.call-in ERROR: rule "Jamfile</export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_root>.python-tag" unknown in module "Jamfile</export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_root>". /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/util/indirect.jam:98: in indirect.call /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/build/virtual-target.jam:455: in _adjust-name /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/build/virtual-target.jam:253: in abstract-file-target.__init__ /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/build/virtual-target.jam:561: in class(a)file-target.__init__ /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/kernel/class.jam:90: in class.new /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/build/generators.jam:558: in generated-targets ... Has anyone else seen this? Thanks, Aparna

3 2

[filesystem] Move constructor from string_type
by danny kabrane 03 Nov '16

03 Nov '16

Hi all, boost::filesystem::path has 2 constructors from a string_type, one with a const reference and another one without const (wich I find troubling), but there's no constructor from a rvalue string_type. Is there something planned to add a move constructor from a string_type ? Regards Danny

2 1

[build] Annoying warnings from Asio, -isystem from bjam?
by Vinnie Falco 02 Nov '16

02 Nov '16

When I have "-Wunused-variable" I get these highly annoying warnings from boost/asio/error.hpp which I'm sure almost everyone has seen: boost_1_60_0/boost/asio/error.hpp:258:45: warning: ‘boost::asio::error::system_category’ defined but not used [-Wunused-variable] static const boost::system::error_category& system_category I don't want to disable the warning but I also don't want the false positives. Thankfully, clang and gcc have this wonderful option "-isystem" which lets you mark include paths as belonging to the system. This prevents warnings from being emitted that the programmer can do nothing about. How can I get Boost.Build to add the Boost library header search paths using "-isystem" so that gcc doesn't report warnings in Boost headers that I cannot do anything about? More detail here: http://stackoverflow.com/questions/1867065/how-to-suppress-gcc-warnings-fro… I've played around with <sysinclude> but can't seem to figure it out. Here's my Jamroot (my project builds on its own, without putting it in the Boost tree): https://github.com/vinniefalco/Beast/blob/master/Jamroot#L80 -- Follow me on Github: https://github.com/vinniefalco

2 2

[algorithm]Interface for search algorithms
by Зайцев Александр 02 Nov '16

02 Nov '16

1 0

[release] 1.63.0 closed for major changes
by Daniel James 02 Nov '16

02 Nov '16

Hi, The master branch is closed for major changes. In one week (9th Nov) it will be closing for the beta release. The full schedule is on the website: http://www.boost.org/development/ And if you haven't done so yet, please can you add your libraries' details to the release notes at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_63_0.q… Or email them to me, if you don't like writing quickbook.

1 0

Curiousity question
by Edward Diener 01 Nov '16

01 Nov '16

I would like to ask a design question for any Boost developers or anyone on this mailing list who might care to answer. You are designing or working on a library, perhaps for Boost, perhaps for fun, and part of the design of the library has some public functionality taking a shared pointer as input. You: 1) Use boost::shared_ptr 2) Use std::shared_ptr 3) Use both boost::shared_ptr and std::shared_ptr with the same functionality 4) Use neither, you roll your own shared pointer-like functionality 5) You don't lke shared pointers and use raw pointers instead I really am curious about this. I haven't put any limitation on your library or made any presumption on who your library is for, on purpose. Thanks for anyone answering !

13 53