- Boost - lists.preview.boost.org

[asio] Any interest in a boost::asio::mockup_serial_port ?
by Damien Buhl 07 Dec '15

07 Dec '15

Dear Boost.Asio developers, I wanted to know if there was any interest for a mockup_serial_port_service, so that one might write cross platform unit-tests of code based on serial_port. I implemented this mockup this summer for a project where the best way to unit test some modules was to act as another peer on a serial port and needed to be doable on any platform supported by asio::serial_port. I find it quite useful, because there - is no need to use separate tools like socat on linux or install virtual COM ports applications on windows. Which ease the setup of the test environment - the fake serial port doesn't pollute the system where the test is run - many test cases can be run in parallel, as there is no native ressources involved. One might use it as this : > using namespace boost::asio; > > boost::thread simulate_writing_device([](){ > io_service ios; > basic_serial_port<mockup_serial_port_service> port{ios, "my_fake_serial_port"}; > > const std::string message = "Hello"; > > for (;;) { > boost::asio::write(port, buffer(message.data(), message.size())); > boost::this_thread::sleep_for(boost::chrono::seconds(1)); > } > > }); > > boost::thread simulate_reading_device([](){ > io_service ios; > basic_serial_port<mockup_serial_port_service> port{ios, "my_fake_serial_port"}; > > for (;;) { > char message[5]; > boost::asio::read(port, buffer(message, 5)); > std::cout << "received : " << std::string(message, 5) << std::endl; > } > > }); A short documentation is available here : http://goo.gl/24JnUg And the implementation is on github in a holdall library for the moment : https://goo.gl/E7KGdn It's a library whose goal is to shrink over the time as they get merged in upstreams project. Hopefully there is interest for this mockup_serial_port, and if so I'll cleanup the code some more and make a pull-request to Boost.Asio. Cheers from Berlin where meetingcpp already ended :'-( -- Damien Buhl

2 2

[fiber] ready for next review
by Oliver Kowalke 06 Dec '15

06 Dec '15

As request, I'd like to announce that boost.fiber has addressed the requests of the last review. Especially migrating fibers between threads is supported - sub-directory 'examples' contains code demonstrating work-sharing and work-stealing. boost.fiber: github.com/olk/boost-fiber/tree/develop (branch develop) requires boost.context (branch develop) Oliver

2 22

Boost 1.60.0 beta 1 Release Candidate 2 available for testing
by Marshall Clow 04 Dec '15

04 Dec '15

Release candidate files for 1.60.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Changes since rc1: * Boost.Sprit has been updated and Boost.Log now builds. * Boost.Math has been updated and now builds. Known issues: * Errors when building libraries for visual studio: test and type_erasure. * Boost.Test fails when building on Darwin with gcc 4.9.2 The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc2.7z) = dd38daa9378a6002fc12da0cab695511 MD5 (boost_1_60_0_b1_rc2.tar.bz2) = f3c9ffc14db3b2e55c7c5c703e69883d MD5 (boost_1_60_0_b1_rc2.tar.gz) = 89365262443cc16990b69f8e4b8b47ab MD5 (boost_1_60_0_b1_rc2.zip) = 3389bd4595a989fe95966440cbe45ca9 Thanks! -- The release managers

7 12

thread_specific crashes the application when it is in a .so file
by George Georgiev 03 Dec '15

03 Dec '15

Hi, Is there a known issue about boost::thread_specific when a global thread_specific object is in a .so file? The exact same code replacing it with thread_local boost::unique_ptr<Foo> works. By the way is there a macro that determines is thread_local supported from the compiler or not? Thanks, George

3 3

Documentation for boostbook
by Soul Studios 02 Dec '15

02 Dec '15

I've seen the existing documentation, and wasn't impressed- is there a better site for details on this? Something with at minimum, a copy of the DTD and an example .xml file? Thanks, Matt

1 0

compilation errors with ublas / cppad
by Peter Caspers 30 Nov '15

30 Nov '15

Hi, I think this has been asked before, but since I am not aware of any answer, I would like to bring up the topic again: When using CppAD::AD<double> with boost ublas, certain compilation errors show up. I attach a small example (ublas_cppad.cpp) and the (start of the) error messages I get (compilation_errors.txt, produced with boost 1.59.0, g++ 4.9.3, CppAD-20151124). The problem is in matrix_assign.hpp; when changing template<class E1, class E2, class S> BOOST_UBLAS_INLINE bool equals (const matrix_expression<E1> &e1, const matrix_expression<E2> &e2, S epsilon, S min_norm) { return norm_inf (e1 - e2) < epsilon * std::max<S> (std::max<S> (norm_inf (e1), norm_inf (e2)), min_norm); } to template<class E1, class E2, class S> BOOST_UBLAS_INLINE bool equals (const matrix_expression<E1> &e1, const matrix_expression<E2> &e2, S epsilon, S min_norm) { S tmp = norm_inf (e1 - e2); return tmp < epsilon * std::max<S> (std::max<S> (norm_inf (e1), norm_inf (e2)), min_norm); } the example code compiles without errors. Can someone point out, how this should be fixed (either on boost or CppAD side)? In general, are there requirements for a type T to cooperate with ublas matrices one should be aware of? Thank you Peter

2 3

Is master branch open for bug fixes?
by Vicente J. Botet Escriba 30 Nov '15

30 Nov '15

Hi, the calendar says that master branch is open for bug fixes, but not mail has been sent to to notify it. Could some release manager confirm that? Best, Vicente

2 2

[program_options] empty string argument
by Benedek Thaler 30 Nov '15

30 Nov '15

Hi, I have the exact same problem: http://boost.2283326.n4.nabble.com/ProgramOptions-explicit-empty-string-arg… --compression '' gave me a specified, empty compression switch value, as expected, on boost 1.58. However, on 1.59, the empty string counts against the positional arguments, and causes regressions. Also, --compression='' gives: The argument for option '--compression' should follow immediately after the equal sign. What is the recommended workaround? Is it planned to be fixed/changed? Thanks, Benedek

1 0

[Boost.LLVM] Synopsis now available
by Andy Jost 29 Nov '15

29 Nov '15

I've created a new GitHub repository for this project and uploaded a synopsis of the proposed interface. I redesigned the interface, so it differs slightly from the prototype code and examples I gave before. Please take a look and provide feedback if you can! https://github.com/andyjost/Boost.LLVM/blob/master/boost_llvm.cpp -Andy

1 0

Interest in an LLVM library?
by Andy Jost 26 Nov '15

26 Nov '15

Is there interest in an LLVM library? My motivation is to simplify the dynamic creation of functions, modules, and programs by defining an EDSL modeled after the C language. LLVM provides an API based exclusively on function calls that is verbose and difficult to use. The EDSL is more expressive and easier to use. (This may remind some people of Boost.Python and indeed these libraries are similar in motivation.) The scope of this proposal is limited. The proposed library does not compile, link, optimize, save, or load anything, for example, since the LLVM API is suitable for that. Also, it may not support obscure features, even if they seem to be within its purview, since one can always make direct calls to the LLVM API. I have written about 6500 lines of prototype code in the context of another project (a compiler for the language Curry, if anyone is interested). It is not a complete solution, but is by no means trivial, either. I'll discuss that next, but since the discussion is somewhat lengthy, let me first explain what I'm looking for by sending this. I think this EDSL would make a good Boost library. If others agree, then the next step is to review the design. I need second opinions and help from more knowledgeable people to improve the design. There are a few places in particular where I think a redesign is necessary. After that, I'm happy to implement the final library (and would gladly accept help, if anyone is interested). Now, I'll show a few examples and provide links to the prototype code. First, here's how to create a module and put it in scope: module const example_module("example"); scope _ = example_module; The scope object sets the insertion point for types, functions, and global variables. We can create a type as follows: type i32 = int_(32); i32 is a 32-bit integer. It is easy to build more complex types, e.g., i32[2] is an array type, *i32 is a pointer type, and i32(i32,i32) is a function type. An expression like i32(42) produces a constexpr. As you might guess at this point, the prototype makes heavy use of SFINAE. I've gone to a lot of effort to make this work with everything I can think of, particularly multi-dimensional arrays and initializer_lists. So, an expression like (i32[3][2])({{1,2,3},{4,5,6}}) works! (Note: i32[3][2] is the C++ type int32_t[2][3] because that's the only sensible way to interpret successive calls to operator[]). We can create a struct from a sequence of types like this: type foo = struct_("foo", {i32, *i32}); Or, we can leave out the sequence to get an opaque struct. A function prototype can be created as follows: function const f = extern_(i32(i32), "f", {"i"}); This function, f, takes an i32 (named "i") and returns an i32. The function is placed in example_module, since the code appears in its scope. There are two other linkage-specifying functions: static_ and inline_. extern_ and static_ are also used to create global variables (i.e., if the type is not a function). To define the body, we create another scope: { scope _ = f; // code for f. } To understand this, we have to discuss scopes in more depth. There are three nested levels of scope: the current module, the current function, and the current basic block. The code above sets the current function to f and the current basic block to f's entry point. Generally speaking, within a function body we write statements that generate instructions. Those instructions are inserted into the current function at the end of the current basic block. To define the body, we can declare values and operate on them. For example: value i = arg("i"); Here, "arg" is a special function that fetches the named function parameter. We can add instructions to f using operators or special methods. For example: value j = i + 1; return_(j); Branches manipulate the current basic block. Here's an if statement: label true_path, false_path; if_(i, true_path, false_path); { scope _ = true_path; // code for true. } /* else */ { scope _ = false_path; // code for false. } // new basic block here. This generates instructions to test i, take the appropriate branch, and then continue to a new basic block in the right places (which depends on whether the paths terminate with a branch instruction). It also updates the scope so that statements following if_() are inserted into the new basic block. Believe me when I say it is not trivial to do this with the LLVM API. Although it is sometimes necessary to pre-declare labels as shown above, we can usually employ C++11 lambdas to simplify the encoding: if_(i , []{ /* code for true */} , []{ /* code for false */ } ); The prototype code can be found under https://github.com/andyjost/Sprite-3/tree/master/include/sprite/backend. Also, there are many examples under https://github.com/andyjost/Sprite-3/tree/master/examples. Other parts of the Sprite-3 project are unrelated to this proposal. A good example to start with generates the Fibonacci numbers (https://github.com/andyjost/Sprite-3/blob/master/examples/fib.cpp) Here's the interesting part: // Create a new module and associate it with this lexical scope. module const fib_module("fib"); scope _ = fib_module; // Declare types. auto const char_ = types::char_(); auto const i32 = types::int_(32); auto const i64 = types::int_(64); // Declare external functions. auto const printf = extern_(i32(*char_, dots), "printf"); // Define the @fib function. auto const fib = extern_(i64(i64), "fib", {"n"}); { scope _ = fib; value n = arg("n"); if_(n <(signed_) (2), []{return_(1);}); return_(fib(n-2) + fib(n-1)); } // Define the @main function. auto const main = extern_(i32(), "main"); { scope _ = main; value const x = fib(5); printf("fib(5)=%d\n", x); return_(0); } After this code runs, fib_module contains an intermediate representation of the program. The LLVM API can be used to save that to disk, compile it to assembly, link in the C library (to get printf), or JIT compile any of the functions, among other things. Thanks to everyone who made it this far :) I'm looking forward to your feedback. -Andy

9 21