August 2015 - Boost - lists.preview.boost.org

1.59.0 rc2 is now available
by Marshall Clow 08 Aug '15

08 Aug '15

Release candidate files for 1.59.0 are available at: http://boost.cowic.de/rc/ (rc1 failed a smoke test) 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. The files (and associated md5s) are: MD5 (boost_1_59_0_rc2.7z) = 1854999b8d32ba89acbf4384fe55e0ab MD5 (boost_1_59_0_rc2.tar.bz2) = 1783f07dd4736ffd9fc97874ce4ef4bf MD5 (boost_1_59_0_rc2.tar.gz) = 47e6db09fd7e1265b9b7046f654e9a72 MD5 (boost_1_59_0_rc2.zip) = 9061c5bbc3399f3f220036e896c202aa Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_59_0.html

3 2

[1.59] Still unmerged changes in the super-project
by John Maddock 08 Aug '15

08 Aug '15

There are a number of unmerged changes in develop of the super-project that look like they should really be in release, in particular: * Jamroot, contains amongst other things a very old fix for Oracle C++ support, without which building with Oracle is more or less broken. In fact unmerged commits on this file go back to....wait for it... 2011 ! * bootstrap.bat has fixes for some rather embarrassing typos. * bootstrap.sh has lots of fixes, also going back to 2011. Those were the "highlights" that stood out to me, the full list with unmerged changes is: .gitmodules | 613 ++++++++++++++++++------------------ .travis.yml | 6 +- Jamroot | 32 +- boostcpp.jam | 47 +-- boostcpp.py | 459 --------------------------- bootstrap.bat | 4 +- bootstrap.sh | 24 +- doc/Jamfile.v2 | 2 - doc/src/boost.xml | 2 - libs/libraries.htm | 10 +- libs/maintainers.txt | 5 +- status/Jamfile.v2 | 4 - status/explicit-failures-markup.xml | 41 +-- tools/Jamfile.v2 | 2 +- 14 files changed, 336 insertions(+), 915 deletions Best, John.

3 2

[iostreams] Ticket #5237 - Chance to get fix applied into Boost 1.59?
by Deniz Bahadir 08 Aug '15

08 Aug '15

Hi everyone, in our application we use Boost.Iostreams with GZip functionality to write some data into gzipped output-files. Eventually we realized, that we would get corrupted output-files if no data was available that could be written to the output-file By looking for a patch we stumbled across an issue-report [1] which seems to be open for more than 4 years, although a simple fix was already provided in its comments 3,5 years ago. My question is: Can somebody apply that fix to the development branch and could it still make it into the upcoming Boost 1.59 release? Thanks, Deniz [1] https://svn.boost.org/trac/boost/ticket/5237

4 4

Getting started with Boost
by Prathamesh Dahale 08 Aug '15

08 Aug '15

Hello, I am Prathamesh Dahale, third year computer engineering student. I am interested in contributing to Boost through gsoc 2016. I know c and c++, I am familiar with c++ STL and I have very good programming skills. I participate in many online programming contests. my handle on codechef.com is 'miracle003'. I would like to utilize my skills for contributing to Boost and I am interested in doing some project with Boost in gsoc 2016. from where i should start?

2 1

Re: [boost] [asio-users] [http] Formal review of Boost.Http
by Lee Clagett 08 Aug '15

08 Aug '15

Sorry for any duplicates and top posting, but I didn't reply-all, so boost got dropped (which was probably more important). And this likely ruins some mail clients (again sorry!). On Fri, Aug 7, 2015 at 11:10 PM, Lee Clagett <forum(a)leeclagett.com> wrote: > On Fri, Aug 7, 2015 at 6:29 PM, Vinícius dos Santos Oliveira < > vinipsmaker(a)users.sf.net> wrote: > >> 2015-08-07 12:53 GMT-03:00 Niall Douglas <s_sourceforge(a)nedprod.com>: >> >>> I do not believe Http is ready for peer review for these reasons, and >>> I personally would urge you withdraw it until you have fixed these >>> issues and then come back to us. If you do not withdraw it, I will >>> vote for rejection. >>> >> ...[large snip]... >> > >>> * I don't understand why you cannot issue more than one async read at >>> a time nor async write at a time. In something like pipelined HTTP >>> that seems like a very common pattern. I smell a potential design >>> flaw, and while the docs mention a "queue_socket" I can't see such a >>> thing in the reference section. >>> >> >> Too much synchronization and buffering. >> >> The pipeline has the following requests: >> >> A => B => C >> >> If I were to allow replies to request B, the design would be more >> complex, increasing the difficult to implement alternative backends and >> everyone's life. Also, the reply to request B cannot actually be sent while >> the reply to request A is on hold. This means that the whole response to >> request B would need buffering and if response B is a video live stream, >> this means an implicit (the user cannot know) crash after an unfortunate >> memory exhaustion. I couldn't claim a **lightweight** server if this >> excessive buffering was to occur. I couldn't claim the project is >> appropriate for embedded devices if I had chosen the buffering approach. >> It's a trade-off. I should write about it in the "design choice" of the >> documentation. >> >> HTTP/2.0 does have proper multiplexing and it can be more useful to >> respond several requests without "head of line blocking". >> >> A queue socket is a concept, I don't provide one. I can look into how >> make the documentation less confusing by adding a page exclusively >> dedicated to explain the problem it solves. Would that work for you? >> >> > FWIW it should be possible to do client and server side pipelining with > this design right now. The reads and writes of the HTTP Socket concept > should be (and currently are by `basic_socket`) handled independently. > Since the notification for a write completion is based on the lower layer > write completion, and NOT whether a HTTP response was received, multiple > (pipelined) requests should be possible by a client. Similarly, this design > should allow servers to handle pipelined requests in parrallel. Providing a > framework for client or server pipelining will require more work, and > should probably not be a part of the Socket concept. In fact - > > I think the ServerSocket concept should be removed entirely. The > `http::basic_socket<...>` models both concepts, so theres lots of server > specific code in it, which seems confusing to me (is this really a "basic" > socket?). I think standalone functions for typical client and server > operations can be implemented as "composed" operations similar to > `asio::async_write`. The documentation will have to be explicit on what the > composed function is doing so that users know whether the Socket concept > has outstanding reads or writes (and therefore cannot do certain operations > until the handler is invoked). In fact, if there is a server operation that > _cannot_ be done with the Socket concept, then the concept probably needs > to be re-designed. > > Lee >

2 1

Is master open for release 1.59?
by Vicente J. Botet Escriba 08 Aug '15

08 Aug '15

Hi, I was on vacations. Is the master branch open for merge? Best, Vicente

3 4

[Property Tree] Comments in info format
by Gavin McNiff 05 Aug '15

05 Aug '15

First time posting, so hopefully no grave faux pas! I have found the Property Tree info format very useful for config files. However, the in-built comment ";" can be a little limiting. In particular, I miss not being able to comment out an entire block. To this end I have being modifying the relevant header to file to allow ; // and -- as inline comments and /* */ as a block comment. These are familiar to many users. Naturally, with every Boost release I have to re-patch this file, so I thought maybe the info format could be updated to allow comments in these styles. Since the format is not any kind of official format and adding new comment styles should not break existing files, I would hope there should be no major objections. I have taken the liberty of attaching the updated header file, as well as the adapted test file. The _gmcn suffix is just for identification purposes. The changes in the code are marked with !!! GMcN !!!. The changes pass in the built-in tests and my own usage tests. Best regards Gavin McNiff

2 2

boost::asio and I2P connection handling.
by Janusz Zradomia 05 Aug '15

05 Aug '15

Hello. I would like to extend the ASIO (in boost::asio) by adding support for new virtual protocols. For example i2p, it is similar to Tor but it works with equivalent of .onion hidden servers, and is not used to connect to "normal Internet" usually. It works like this: - the end-points, equivalent of the ip4/ip6 address, is a very long string (around 500-1000 characters, it is technically the public key of data) - the end-point address is often expressed as shorter version of the address, that is around 50 characters afair, in two possible formats (b32 and b64) - user can create new i2p listening socket for TCP-like data (for stream of bytes), or for UDP-like data (message oriented). On creation of the listening socket you can get a new own "address" as above. Or, you can on creation/before creation tell it to reuse an previously created address by providing the std::string with private key of it (that you saved previously) - user can connect to an i2p address. When connecting, he is getting a new endpoint from which he connects, or he can reuse old one by loading the private key as above. - there exists naming lookup system, that allows to convert domain-name strings like "zzz.i2p" into proper i2p address Can I add such new class of protocol on top of ASIO? Which classes I need to extend (create child class)? Where exactly would each of the listed above functions go?

1 0

[http] Formal review starts on Friday
by Bjorn Reese 05 Aug '15

05 Aug '15

This is a short notice that the formal review for the Boost.Http library starts on Friday and will last for ten days: from August 7th until August 16th. A proper announcement will be made on Friday, which will include links to the source code and the documentation to be reviewed. As a courtesy to the ASIO community we encourage your participation in the formal review as well.

2 1

[1.59] SVG's not showing up in beta
by John Maddock 05 Aug '15

05 Aug '15

SVG graphics used in documentation are still absent from the (beta) website, see for example: http://www.boost.org/doc/libs/1_59_0_b1/libs/math/doc/html/math_toolkit/sf_… I assume a script somewhere needs updating? Thanks, John.

2 2