- Boost - lists.boost.org

[Root Pointer] Ultimate test - Neural Network
by Phil Bouchard 25 Mar '16

25 Mar '16

Hi, I wrote a small utility that reads PDFs over the Internet and converts the text into a tree of regular expressions. The goal here is to test root_ptr<> and see if it will stand up to this complexity. The code is very simple for the moment as you can see: https://github.com/philippeb8/root_ptr/blob/master/example/t100_test1.cpp Because it makes use of Bash utilities. I am also using libpstreams and "indent_facet.hpp". So anyway apparently it works fine and please let me know if you do not think the code is clean enough. Regards, -Phil

3 14

Boost libraries cannot yet be trusted
by Michael Witten 23 Mar '16

23 Mar '16

In short, I request that the maintainers start publishing cryptographically signed, strong hashes of: * downloadable files. * git objects (tags, and even commits). A cryptographic signature should probably be a personal signature of a relevant maintainer (rather than some generic project-level signature for which nobody has a sufficiently strong incentive to maintain the trustworthiness). Perhaps, each repository should include a collection of relevant public keys, so as to compound trustworthiness and ease dissemination. ------------------------------------------------------------------------ I'm new to this community, so forgive my ignorance if I've missed an existing solution. With each release, there should be included conspicuously (and widely) published means by which to check the authenticity of the relevant content. As far as I can tell, this is not yet the case. At the very least, within an email that announces a release, there should be a list of suitably safe (e.g., SHA-256) hashes for the downloadable files in question, including the hash of the relevant git commit object[s]. Now, SourceForge does indeed list SHA-1 and MD5 hashes of each file it offers for download, but they are not conspicuous; the user must know to click on an `i' symbol that sits next to each link (the `i' presumably stands for `information', but I wouldn't be surprised if it actually stood for `ignore me'). To make matters worse, that very icon and its associated functionality is only available when JavaScript is enabled, which is absurd. Furthermore, it's important that this list of hashes appear in as many independent places as possible, so that it becomes increasingly difficult to alter the association; for instance, if Gmane picks up an announcement email that includes such hashes, then an attacker will also have to compromise Gmane's servers in order to forge a new record of the intended payload. That is, widely published integrity information strongly suggests a [reasonable] means by which to calculate authenticity; certainly, the converse is true: Authenticity implies integrity. Of course, it's irritating (and unlikely) for a user to take the time to check multiple publishers for such integrity information every time a new release is made. Thus, it makes more sense to abstract away this process into a one-time dissemination of integrity information with which a user may determine the authenticity of other, related data that is provided by any publisher. Such an abstraction is provided by cryptographic signatures. By widely publishing a public key, a maintainer provides a [reasonable] means by which a user may calculate the authenticity (and thus also the integrity) of any other data that is signed by the associated private key. Now, that calculation is only as trustworthy as the private key itself, so it's important that there be a strong incentive to keep that private key trustworthy; this possibly implies that the private key in question should be intimately associated with the individual who uses it; this suggests that, as a matter of explicit policy, there should not be some generic project-level private key shared by multiple individuals across space or time. The easiest solution is to require that some *individual* maintainer of data be responsible for signing that data with his own personal signature. Of course, not every user has the machinery or desire to work with cryptographic signatures; some people are satisifed with merely checking that the hash of data matches the result provided by a trusted publisher. Fortunately, all parties can be satisfied simultaneously and cheaply: Provide the list of hashes as a cryptographically signed message. Furthermore, the source-control management tool `git' (which this project already uses) provides support for integrating cryptographic signatures; not only can a tag object be cryptographically signed, but every commit object can also be cryptographically signed. It's probably enough just to sign tags (those of releases, at the very least), but perhaps it would be worthwhile to sign a commit object that sits some sufficient number of commits ahead of the object last signed, so as to give users a kind of checkpoint of authenticity. It might be worthwhile to include in every repository the public key of each relevant maintainer (say, one file for each maintainer); this kind of publication would allow for compounding a key's trustworthiness with each new commit, and it would make dissemination of that information both easier and more specialized to its purpose. In any case, something must be done; this project sits at the core of much critical software, and its integrity should be ensured with greater zeal. Sincerely, Michael Witten

10 18

[Fit] formal review ends 20th March.
by Vicente J. Botet Escriba 23 Mar '16

23 Mar '16

Hi, There have been some that would be able to write a review next week-end. Others said that they had not enough time. Maybe having an additional week can help. I have not received confirmation from the review withards, but as there is no planned reviews for this week, I propose to continue with the review until 20th. Please take the time to do a review and share your point of view. Best, Vicente Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects. Fit is: - Modern: Fit takes advantages of modern C++11/C++14 features. It support both `constexpr` initialization and `constexpr` evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. - Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. - Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: * Function Adaptors and Decorators: These enhance functions with additional capability. * Functions: These return functions that achieve a specific purpose. * Utilities: These are general utilities that are useful when defining or using functions Fit has been tested on gcc 4.6-4.9, clang 3.4-3.7, and Visual Studio 2015. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Documentation:http://pfultz2.github.io/Fit/doc/html/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? More information about the review process can be found here:http://www.boost.org/community/reviews.html

8 16

[http] Design ideas for a request router
by Vinícius dos Santos Oliveira 23 Mar '16

23 Mar '16

Hi list, I've been designing a HTTP library for Boost inclusion for the last two years. First it was funded as a GSoC 2014 project. Then I continued to polish the implemented bits on my own and the library was peer reviewed (and rejected) last year. I'm currently addressing the requests made during last year's review and one of the requested items was a higher-level interface built on top the current building blocks that would be easier to use. One of such abstractions would be an HTTP request router. I usually do my research and check what others have done (not only in C++), read a lot of spec and do a design on my own (sometimes I ask for feedback of a few chosen ones). I rarely ask for public feedback because I usually can solve the interface issues on my own. However, Boost.Http is a new thing and I'm exploring an unexplored ground. I've been facing an issue for the last months and I'd like to have "open" feedback of anyone interested in this topic. Maybe it'll speed me up. The issue I'm facing is that (1) I haven't found enough diversity of HTTP request routers and (2) Boost.Http is a new thing and problems must be approached differently (what other HTTP library will let you do HTTP over uTP using Boost.Asio threading/async model?). Detailing the problem a little more: I categorize current HTTP request routers into two styles. The "tree style" is the style where you declare some paths to be handled and each request will be routed to at most one handler. You'll find this style usually when the author advertise a ReST support library (e.g.crow[1]). The "chained style" is the style where you declare a chain of <rule,handler> pairs (or anything in these lines) and one handler can "give up" and pass the route to the next in line. Rules in the "chained side" can overlap and an order exists (and must be explicit). You can find this style being used frequently in the Node.JS frameworks (e.g. connectjs[2]). You could reimplement these NodeJS APIs in C++ keeping a lot of the same look'n'feel. For instance, take a look at node.native[3]. I thought I could combine and allow both styles. Actually, Boost.Http don't force you to use any style and both could be used. However I wanted to implement both allowing some kind of interoperability and communication between them. There are a lot of open questions right now and I decided to implement both individually and only then come back trying to unify them. So, for now, my problem is designing the "chained style". Even implementing only "one style" I had open questions and I decided to draft an implementation to maybe give some light to my own mind. One thing that I was trying to address would be the "next" function. If you take a look at the connectjs library[2], you'll see that the "next" function is an argument passed to the handler and, if the handler wants to give up and pass the route to the next handler, it only needs to call "next". This behaviour could be emulated in C++ using std::function<>. An alternative design would be to make the handler return a bool. This is actually the design I've chose in Tufão[4] and I regret this decision to this date. The bad thing about this approach is the too-much-sync minded. If you need to communicate with a database to know whether you'll be able to handle the route then you need to block the whole thread under this approach. Knowing this is Boost and Boost is about serious C++ users I know I must be concerned about performance. Therefore, many may not like the std::function<> approach. It can imply some hidden allocation that you pay even if the handler is not going to give up on the route. Another approach would be to turn the handlers into template functors. However, this would be too much burden on the user. And if I chose this route, what would be the type of "next"? The approach I've chose was to encode the "next" function into the "request object". In Boost.Http, there is no "request object" like you'd be used to when using other APIs. Boost.Http exposes a socket and the socket will fill a message object of your choice (let's call it the input message) and later you pass it another message object to execute the reply (let's call it the output message). So the "next" function is really encoded in the input message. Other APIs use a passive style and constantly check if there is network activity and schedule new socket reads. Boost.Asio is more explicit and Boost.Http follows along. An active style is useful because it'll allow you to defer new operations to later when your server is under heavy load. Anyway, I felt that maybe I'll need a "done" function and I've added an empty one for now. I'll see if I'll really need it later when I integrate everything together. For now, just know that the "done" function does nothing. Anyway, this is my draft and I'd like to know your opinion: https://github.com/vinipsmaker/asiohttpserver/blob/router/example/router.cp… You can see that I'm declaring a static router because most of the time you don't change the rules at runtime. This router is actually more difficult to design and it'll be easier to add a "dynamic router" later on. I also want to mention that I'm aware of another effort by another developer (Uisleandro) trying to add a router to Boost.Http: https://github.com/uisleandro/Router_for_Boost.Http I also want to mention that performance of the implementation isn't really something I care about for the draft. If it were at another place it could mean that I'm not interested in implementation feedback. However it doesn't mean that I know the best way to implement these APIs and I'm still interested in implementation feedback (even more because I don't remember if I ever implemented much TMP before). Some points that I'll tackle LATER will be: - A router is a handler too, then you can have nested routers. - The router doesn't take the rule, only the handler. Later, I'll make algorithms that adapts rules and conditionally call your handler or pass the route to the next handler. This design is more flexible and I wish I could also use it in "tree style too". - How to create Message types more easily? I've read about component-based architectures before, but I never really understood them. Is there any library that was proposed to Boost in these lines that I could take a look at? [1] https://github.com/ipkn/crow [2] https://github.com/senchalabs/connect#mount-middleware [3] https://github.com/d5/node.native [4] http://vinipsmaker.github.io/tufao/ref/1.x/class_tufao_1_1_http_server_requ… -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 20

Sean Parent to Keynote C++Now 2016
by Jon Kalb 22 Mar '16

22 Mar '16

Boost Developers, C++Now is announcing that the keynote speaker for our tenth conference will be the keynote that started us off, Sean Parent. http://cppnow.org/2016-conference/announcements/2016/03/22/keynote-announced .html Jon

2 1

[Fit] Formal review / Kris
by Krzysztof Jusiak 22 Mar '16

22 Mar '16

Hi, Firstly, sorry for submitting my review so late. > - Whether you believe the library should be accepted into Boost Yes. Although the submission is not perfect, I prefer boolean logic, and, therefore Fit a 1 for me. > - Your name Krzysztof Jusiak > - Your knowledge of the problem domain. I have been implementing similar solutions myself when experimenting with lambdas. I have also checked out functional part of Hana library. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design IMHO design is decent. Functionality is loosely coupled and really easy to follow. There are a few inconsistencies here and there but there were pointed out already and they don't have a huge impact on the overall solution. > * Implementation Quite a lot of macros but most of these are due to lack of language features or compilers bugs. Besides that, it looks alright. Moreover, I do agree with most issues pointed out already. > * Documentation Motivation could have been much better. Examples showing how much pain might be saved using Fit in comparison to writing the same things by hand would be great. Moreover, ready to copy examples would simplify testing the library. Personally, I would also add disassembled code for these examples showing how well-optimized code Fit can produce. Maybe, it's worth to add try-it-online functionality too? > * Tests Tests are short and easy to follow. I can't see coverage but it seems like most things are tested. Travis addition with each push make me confident that the library is always in a good shape. I would like to see performance tests though for both compilation times and run times. > * Usefulness IMHO Fit is defo a library to have in Boost for modern C++ development. I find the solutions provided by Fit very useful as I have been writing similar functionality myself. Nevertheless, documentation needs improving (as it was stated already) in order to state the purpose more clearly with clean examples. I have been worrying that there will be a clash with Hana. Having 2 modern libraries providing similar functionality would be confusing, however, my concerns were already clarified by Louis. > - Did you attempt to use the library? If so: > * Which compiler(s) Clang 3.7/3.8/HEAD, MSVC 2015 > * What was the experience? Any problems? No issues. > - How much effort did you put into your evaluation of the review? A few hours for the review, however, I have been looking and trying Fit for a while. Cheers, Kris

4 8

[test] Not using Boost.Test for an official Boost library
by Vinícius dos Santos Oliveira 22 Mar '16

22 Mar '16

Hi list, I'd like to know if it's mandatory to use Boost.Test if you intend to contribute a library to Boost. After facing an issue trying to enable compiler santizers on my tests[1] for long enough, I'd like to use a different test library. According to a survey done by Niall concerning new libs[2], everybody avoids Boost.Test, favouring assert/static_assert. I've been interested in using Catch[3], which is header-only and can be embedded, posing no problem to users (it'd be transparent). I've seen Boost.AFIO (which is not an official Boost library) already uses it. I've seen lightweight_test is also used within Boost[4]. If Boost.Test ever fix its integration problem with compiler sanitizers[1], I'd have no problem migrating everything back again to Boost.Test. However, it's more important for me to have this issue solved now so I can jump to the next task (valgrind and fuzz testing). I've also seen that some header-only libraries use a different build system for the test target[5] and using a header-only test library would be a lesser demand that should be okay. [1] https://svn.boost.org/trac/boost/ticket/11425 [2] https://raw.githubusercontent.com/boostcon/cppnow_presentations_2015/master… [3] https://github.com/philsquared/Catch [4] http://www.boost.org/doc/libs/1_60_0/libs/core/doc/html/core/lightweight_te… [5] https://github.com/boostorg/hana/blob/63c5f87dfdadd07e496cefefc63c3ea9968d3… -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

6 5

Boost 1.61.0 Beta 1 Release Candidate 1
by Vladimir Prus 22 Mar '16

22 Mar '16

Release candidates for 1.61.0 beta 1 are now available: http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.zip http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.gz http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.7z 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. These packages were generated by the CI system that Rene has put together, and one user-visible change is that the directory inside archive is named after git commit hash. This will be changed for the final release. Otherwise, these were smoke-tested on Windows and Linux, and should be functionally identical to usual packages. The SHA1 checksums are as follows: b8314cff39908e6d6221bdad01ce1f1468546419 boost_1_61_0_b1_rc1.zip cd916da1aa5ed812e538975171069506ecc4560c boost_1_61_0_b1_rc1.tar.bz2 ca18da298d739ef70145b29e3bd2c8d903067075 boost_1_61_0_b1_rc1.tar.gz 2fb4b8cf9112f59aa1c4b61f2ea0c66cbbe3ffd0 boost_1_61_0_b1_rc1.7z The SHA256 checksums are as follows: 3668b868d3f883327e2ff1324e09899cbb033087147d4dd268424a7729791f94 boost_1_61_0_b1_rc1.zip e07784e9770193ff1e68cfe05c6fd08ca05913afedaedf1aca33f6da30d49b17 boost_1_61_0_b1_rc1.tar.bz2 2344369b6859ed151589286d05b38764a902884c10a4dac9c67b133c6c046130 boost_1_61_0_b1_rc1.tar.gz 9ab80608c9ec70ec7afee25f2213f803ed3d15a71ade2c6ae184c48f33fd9d29 boost_1_61_0_b1_rc1.7z Thanks! -- The release managers

10 18

[Fit] formal review starts today
by Vicente J. Botet Escriba 21 Mar '16

21 Mar '16

Dear Boost community, sorry for the late anounce The formal review of Paul Fultz II's Fit library starts today, 2nd March and ends on 13th March. Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects. Fit is: - Modern: Fit takes advantages of modern C++11/C++14 features. It support both `constexpr` initialization and `constexpr` evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. - Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. - Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: * Function Adaptors and Decorators: These enhance functions with additional capability. * Functions: These return functions that achieve a specific purpose. * Utilities: These are general utilities that are useful when defining or using functions Fit has been tested on gcc 4.6-4.9, clang 3.4-3.7, and Visual Studio 2015. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Documentation:http://pfultz2.github.io/Fit/doc/html/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? More information about the review process can be found here:http://www.boost.org/community/reviews.html We await your feedback! Best regards, Vicente J. Botet Escriba

10 64

[Fit] formal review is over
by Vicente J. Botet Escriba 21 Mar '16

21 Mar '16

Hi, The review of the Fit library finished yesterday 20 March. Thanks to all the people who participated in the review, as a reviewer or commenting the threads. I hope to announce the result soon ;-) Best, Vicente P.S. Of course you/we can continue with the discussion and add issues in github that would help to improve the library. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Documentation:http://pfultz2.github.io/Fit/doc/html/

1 0