- Boost - lists.boost.org

[gsoc2017] Please review my proposal for project "Nearly antipodal points distance accuracy improvement. "
by Satyam.Pandey 02 Apr '17

02 Apr '17

Hi all, I want to contribute to the project "Nearly antipodal points distance accuracy improvement." I have attached my proposal in the mail. I request the mentors to review my proposal. I know I'm pretty late to start. But it would be great help if you can review my proposal and suggest the changes if required. Proposal : https://docs.google.com/document/d/19WYR0RHINxqhtu0SIN0ZUxYMNKxAf1LOBPGl7j7… Thanks Satyam Pandey -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc2017-Please-review-my-proposal-for-p… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 4

equivalent for 'pause' mnemonic on ARM - or boost.pref?
by Oliver Kowalke 02 Apr '17

02 Apr '17

Hi, does someone know an equivalent of x86 'pause' mnemonic for ARMv6? Raspbian (-march=armv6) and Debian armel (-march=armv4) seam no to accept The 'yield' mnemonic seams no to be right in both cases. Or does boost.predef's BOOST_ARCH_ARM give a hint for both cases? ty, Oliver

2 2

BOOST license & GPL
by Oliver Kowalke 02 Apr '17

02 Apr '17

Hi, I encountered a open source project that is released under GPL and uses Boost - that's OK, because GPL and Boost license should be compatible. But the developers of those project copied code from Boost into their own library. The question is, is this new library now GPL or Boost license? Additionally, because they copied the code from several Boost files into one, they mixed up copyright statements. As a result, some people get copyright on code they never wrote. Seams to me that's not correct. Oliver

4 15

[gsoc17] My proposal
by GuillermoReyes 01 Apr '17

01 Apr '17

Dear Vissarion and Adam, My name is Guillermo- a Computer science student at UCLA. I am excited at the possibility of contributing to such a useful library! My application is not yet complete, but I will post my draft on here to demonstrate my intent to participate in the program. For the competency test, I began to implement a representation of points on earth and used the great-circle formula to calculate the shortest distance between two points. I will have a more in-depth explanation of the code by the final iteration of the draft along with the complete proposal and application. Sincerely, Guillermo R. -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc17-My-proposal-tp4693288.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[Stacktrace] Review 2 Manager report
by Niall Douglas 31 Mar '17

31 Mar '17

Many thanks to all those who participated in the second review of proposed Boost.Stacktrace. I received the following formal reviews: 1. Peter Dimov (ACCEPT) 2. Vladimir Batov (ACCEPT) 3. Artyom Bellis (CONDITIONAL ACCEPT) 4. Bjorn Reese (ACCEPT) 5. Edward Diener (ACCEPT) Extensive comments without a formal recommendation were also made by: 1. Mark Bartosik 2. Florian Weimer Some of the more important conditions for acceptance as judged by the review manager are: * Problems on FreeBSD (and by inference OS X?). * Per frame execution of addr2line rather than calling it once. * Throw-with-trace was asked for by a lot of people. * One reviewer suggested that the addr2line backend was async signal unsafe. My reading of the code is that it is async signal unsafe to parse a stacktrace (and unavoidably so on any platform), but the capture of backtraces is now fully async signal safe. * Some disliked the bringing in of windows.h and the COM headers on Windows. For a header only library I consider this acceptable, Stacktrace when configured in non-header only mode does not inject windows.h into everything including stacktrace. Congratulations to Antony on getting yet another library of his into Boost! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 2

[Beast] Redesigned HTTP algorithms and parser!
by Vinnie Falco 31 Mar '17

31 Mar '17

Background: Websocket connections start with an HTTP UPGRADE request/response sequence. Often people want to customize this handshake so I added code in Beast to read and write HTTP messages. Upon reviewing the HTTP RFC (rfc2616 and rfc7230) it seemed to be logical that the HTTP message could be modeled as a single class. And there could be free functions implementing the algorithms to serialize and deserialize these messages in th HTTP/1 format. I took this as far as I could and I was pretty happy with the result. You have functions like read, async_read, write, and async_write which take beast::http::message objects as parameters. Example: http://vinniefalco.github.io/beast/beast/ref/http__read/overload3.html The innovation here is the "Body" template type which controls not only the type of container used to represent the body but also the algorithms used to transfer bytes from the message body on the wire into and out of that container. The Body concept, and its nested Reader and Writer concepts, are documented here: http://vinniefalco.github.io/beast/beast/ref/Body.html http://vinniefalco.github.io/beast/beast/ref/Reader.html http://vinniefalco.github.io/beast/beast/ref/Writer.html Previous efforts and HTTP implementations focused heavily on the representation and parsing of the headers. To my knowledge Beast is the first implementation to provide caller flexibility in the body representation. Now the Beast websocket implementation has a reasonable set of primitives it could use to perform the handshake, and users could get control of that process. The Problem: Unfortunately, while treating the message as an object that can be read/written atomically works great for example programs and trivial use-cases, it fails in the real world. These are issues with it: * The caller must commit to a Body representation before receiving the HTTP Header * No way to properly read and respond to Expect: 100-continue * An efficient HTTP relay function (one that does not buffer the entire body up front) cannot be implemented by the caller * The caller cannot reasonably set a timeout, for example what if the body is 2 gigabytes received over a slow connection? * The parser interface forces algorithms to perform an unnecessary buffer copy for body containers that are entirely stored in memory (e.g std::string or boost::asio::streambuf). These issues sparked quite a bit of discussion on GitHub: https://github.com/vinniefalco/Beast/issues/154 https://github.com/vinniefalco/Beast/issues/265 In October of 2016 these problems became apparent. I tried a lot of different ideas to improve the design to solve it, but none of them worked. Some of my co-workers looked at it but we didn't really find anything great. One user in particular, on GitHub, had strong ideas involving the concept of "completion conditions" to augment the read/parse algorithms but it didn't feel right to me. The Solution: After suffering from writer's block for 5 months inspiration hit and I tried a combination of interface changes that got the design to where it needs to be to solve these problems. * The Reader concept is refined into two types: "indirect" readers, and "direct" readers. This is described here: http://vinniefalco.github.io/stage/beast/beast/ref/Reader.html * The parser exposes a small number of internal states, informing callers of where it is at and giving the caller control over if and when the parser advances to the next state: https://github.com/vinniefalco/Beast/blob/http/include/beast/http/basic_par… * The parser is rewritten to work only on linear buffers (allowing it to be optimized to become 20 times faster if SSE2 instructions are allowed). To facilitate this requirement, the flat_streambuf class is provided which works just like a basic_streambuf except it guarantees a single buffer. If the parser is given multiple buffers, it allocates memory to flatten it: https://github.com/vinniefalco/Beast/blob/http/include/beast/core/flat_stre… * New functions parse_some and async_parse_some allow the caller to perform incremental parsing. This allows for the implementation of relay functions, or reading just the header (for Expect: 100-continue): https://github.com/vinniefalco/Beast/blob/http/include/beast/http/parse.hpp… With these changes callers can get control of the inner loop that reads the body off the socket or stream, so they can do whatever custom steps are necessary if they want. They can set timeouts, and write their own loop that calls parse_some repeatedly. I think it solves all of these issues. I've written some test code which demonstrates how direct and indirect body readers are implemented, and what calling code looks like. I've also written a prototype "relay" function (read a message from one socket and efficiently write it to another socket). And there's an example of how Expect: 100-continue might be implemented. These prototypes are located here: https://github.com/vinniefalco/Beast/blob/http/test/http/design.cpp#L30 How to Help? These are some controversial changes and I think they could use some polish and vetting before I merge it to the master branch. Maybe there is something I haven't thought of, or a use-case it doesn't address. Perhaps there is a better way, or perhaps there are tweaks to make it even more usable and understandable. If some kind soul(s) would look through it and offer some feedback, positive or negative, that would be enormously helpful. The formal review for Beast is now scheduled for the first week of July and like an expectant father I am anxious and would like everything to go just right! My only objective is to polish up the library and its documentation so it is in the best possible shape for review. Thanks for listening!

1 1

[release] Boost 1.64.0 Beta 2
by Rene Rivera 31 Mar '17

31 Mar '17

Boost release 1.64.0 beta 2 is now available at: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.2/source/> The SHA256 checksums are as follows: 49c9339b9d8e7b2610ef84c80cd10b2252c119ebcc3222450beb0e94c1da1522 boost_1_64_0_b2.7z 92ec7cbf1e77c5979e381dd8104f9e96c0471c276e566272751a981d806db94b boost_1_64_0_b2.tar.bz2 da5670892b7b572808491b13a7b9421c3c18e6f395d6a5ec822466db466eda01 boost_1_64_0_b2.tar.gz 61d6e29e8a1d7503fe13a9d916842f0ec2e625f733b98b29ce563f8cbdb482bf boost_1_64_0_b2.zip The notable difference from Beta 1 is the inclusion of the missing Boost Process library. For details of what's in the release, see < http://www.boost.org/users/history/version_1_64_0.html>. Note that the links to files on this web page are for the final release - use the link above to get the beta files. There are also pre-built libraries provided by Tom Kent here: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.2/binaries/> Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

6 5

[gsoc17]Proposal draft shared of Boost.Geometry Project 1
by Ruoyun Jing 30 Mar '17

30 Mar '17

Hi Adam, Vissarion, boost all: I have finished my proposal of Boost.Geometry Project 1, I am very pleasure you to give me more advice of my proposal! :) Any aspect of the proposal is OK! I would like to get feed back from you! Looking forward from you! :) Thanks all and Best Regards. Google docs: https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb… Ruoyun Jing -- Northwest University of China Software Engineering jingry0321(a)gmail.com <jingry0321(a)163.com>

1 0

Boost.SIMD review
by serge guelton 30 Mar '17

30 Mar '17

Hi Boost Dev, I'm the core maintainer of Pythran[0], a python-to-native-code compiler focused on numeric computations. For more than 3 years, we've been using Boost.SIMD [1] as a generic backend for SIMD code generation, without much worries. Basically our compiler generates C++ code that includes Boost.simd calls. The big plus to us are: + Performances. The generated code runs at the same speed as the one written with intrinsics; + Target abstraction, esp. concerning the vector size and the various arithmetic operations; + Complete libm API, vectorized, which is a big plus when porting existing code (or when matching an existing API as we do); + Header only, which actually makes it easier for us to ship; + Low requirements (it does not require us to ship a large part of boost).? The compilation time is sometimes a worry, but it has decreased over the year. We don't use complex data movement like shuffle or pack, so I don't have any feedback on that. All in one, if that ever matters, I would be happy to have it integrated in Boost! ++ Serge [0] https://pythonhosted.org/pythran/ [1] https://github.com/NumScale/boost.simd

1 0

NuDB: A fast key/value insert-only database for SSD drives in C++11
by Vinnie Falco 30 Mar '17

30 Mar '17

I just released version 1.0.0 of my header-only C++11 library NuDB. Its quite a mature library, haven't had to make any changes in a while. Its been running on production servers for 2 years or so with no problems, managing ever-growing databases of 2TB. I'm wondering what the level of interest, if any, there would be for making this a part of Boost. You can check it out here: https://github.com/vinniefalco/NuDB

11 91