- Boost - lists.preview.boost.org

[android][regression] bjam failed
by Dmitry Moskalchuk 30 Aug '15

30 Aug '15

Hello, Today I've experienced problems with Android regression tests on 'develop' ('master' is OK, and 'develop' was OK too for long time): ERROR: Bjam failed (see /home/cislave/.crystax/ci-boost/regression/android-21-armeabi-v7a-hard-develop/test/develop/regression/armeabi-v7a-hard/test/results/bjam.log for full details): - BOOST_OS_LINUX == 0 : yes - BOOST_COMP_GNUC >= 4.7.4 : no - BOOST_COMP_GNUC >= 4.3.0 : no - BOOST_COMP_GNUC >= 4.3 : no - BOOST_OS_QNX == 0 : yes - zlib : yes warn: Unable to construct ../libs/predef/test/info_as_objcpp warn: Unable to construct ../libs/predef/test/info_as_objc error: Name clash for '<p/home/cislave/.crystax/ci-boost/regression/android-21-armeabi-v7a-hard-develop/test/develop/regression/armeabi-v7a-hard/test/boost_root/bin.v2/libs/dll/test>libtest_library.so.1.59.0' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <cxxflags>-Wall -Wextra -pedantic -Wno-long-long <library>object(file-target)@57008 <library>object(file-target)@57040 <toolset-gcc:version>4.9 <toolset>gcc <xdll-path>/home/cislave/.crystax/ci-boost/regression/android-21-armeabi-v7a-hard-develop/test/develop/regression/armeabi-v7a-hard/test/results/boost/bin.v2/libs/filesystem/build/gcc-4.9/release/abi-aapcs/target-os-android/threading-multi <xdll-path>/home/cislave/.crystax/ci-boost/regression/android-21-armeabi-v7a-hard-develop/test/develop/regression/armeabi-v7a-hard/test/results/boost/bin.v2/libs/system/build/gcc-4.9/release/abi-aapcs/target-os-android/threading-multi error: - <library>object(file-target)@332654 <library>object(file-target)@332686 <toolset-clang:platform>linux <toolset-clang:version>3.6 <toolset>clang <xdll-path>/home/cislave/.crystax/ci-boost/regression/android-21-armeabi-v7a-hard-develop/test/develop/regression/armeabi-v7a-hard/test/results/boost/bin.v2/libs/filesystem/build/clang-linux-3.6/release/abi-aapcs/target-os-android/threading-multi <xdll-path>/home/cislave/.crystax/ci-boost/regression/android-21-armeabi-v7a-hard-develop/test/develop/regression/armeabi-v7a-hard/test/results/boost/bin.v2/libs/system/build/clang-linux-3.6/release/abi-aapcs/target-os-android/threading-multi error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. Does anyone know what that means and how to fix it? I suspect this is result of recent update related to Boost.Dll, but I don't know if that's error in our scripts, preparing testing environment, or error in Boost itself. -- Dmitry Moskalchuk

1 0

[Proposal] BOOST_NO_GLOBAL_FILESYSTEM_NAMESPACE
by Ed Schouten 30 Aug '15

30 Aug '15

Hi there, I'm currently in the process of porting the Boost libraries to a new platform called CloudABI. CloudABI is a POSIX-like runtime environment that is purely built on the concept of capability-based security. In a nutshell, it means that actions that have side-effects outside of a process can only be performed if the process owns a capability (a file descriptor). In other words, open() is missing, but openat() is still there. There are only local filesystem namespaces. CloudABI allows you to reduce the impact of security exploits through sandboxing, but also makes it possible to safely run untrusted third-party applications without requiring any virtualization, containers, etc. Be sure to check out the GitHub page for more details: https://github.com/NuxiNL/cloudlibc The other day I started experimenting with getting Boost working on CloudABI and I noticed that most of the Boost sources already build on CloudABI. I somewhat expected this, because Boost sources tend to be written in a loosely coupled, testable way. But still, hats off to the Boost developers! The biggest showstopper -- as expected -- is boost::filesystem, which will likely never work on CloudABI: https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/q1F0KDEBtf… But in many cases there are also classes that can optionally access the filesystem through utility functions (boost::locale::gnu_gettext, boost::program_options::parse_config_file(), etc). The reason why I'm sending this email is because I want to propose adding a new configuration option, BOOST_NO_GLOBAL_FILESYSTEM_NAMESPACE, that I can use to conditionally disable such utility functions. I've attached a patch for Boost.Config to this email. Does this approach seem reasonable? Do we like the name of this build option? Does the patch look all right? It seems as if generate.cpp also made some unnecessary changes to these files. What's up with that? Best regards, -- Ed Schouten <ed(a)nuxi.nl> Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717

1 1

Re: [boost] [afio] AFIO review postponed till Monday
by Glen Fernandes 29 Aug '15

29 Aug '15

Did the review start yesterday? Glen

18 84

Request for help in porting colony to boost from experienced container boost dev
by Soul Studios 29 Aug '15

29 Aug '15

Hi all- I require help in adapting colony to the boost framework, as colony is light on dependencies, as per the boost recommendations, whereas the boost containers are extremely dependency-heavy - which is somewhat confusing. I need somebody who has some experience with writing or editing the boost containers, to help me sort this from that, wrong practice from right practice in this area. It is, perhaps, something I could spend half a year trying to understand, but unfortunately I do not have that luxury. Whoever helps me will of course get credit for their involvement, with my gratitude. If yourself or anyone you know can help, please get them or yourself in touch. If anyone is interested, my initial port of colony to boost is at the following github repository: https://github.com/mattreecebentley/boost_colony It is an incomplete port but functional. I posted to the boost-users list about colony previously, if anyone is unsure about what it is please see the website (plflib.org) for benchmarks, overview reasoning and code- Thanks, Matt

3 16

Merging pull requests in boostorg/boost
by Antony Polukhin 28 Aug '15

28 Aug '15

Hi, Could someone review and merge the following pull request https://github.com/boostorg/boost/pull/94 ? I do hope to see Boost.DLL in next release, but that requires a lot of testing on different platforms (and that requires the pull request merged). There are also some pending Boost.Compute pull requests, please take a look at them too. -- Best regards, Antony Polukhin

1 0

Feature macro for putting things in the std namespace
by Mathias Gaunard 28 Aug '15

28 Aug '15

Hi all, I'm working on providing support in Boost for a new standard library provider, which happens to put some but not all of its symbols in the 'std' namespace. As a result, opening the 'std' namespace and forward-declaring or specializing things would not work. It seems a number of Boost libraries do this (most notably Boost.Container), with special code to deal with libc++ (since libc++ puts everything under an inline namespace). I think it would make more sense to have a BOOST_HAS_SYMBOLS_IN_STD_NAMESPACE feature macro that one could check to tell whether it is possible or not to do that. In the case of forward-declarations, the library would have to fall back to including the appropriate headers if that feature macro is not set. Is everyone on board with this? Any recommendation for the name?

4 8

Interest in adding support for the Bloomberg Standard Library
by Mathias Gaunard 28 Aug '15

28 Aug '15

Bloomberg has its own C++ standard library, BSL, which sits on top of another standard library but replaces containers with their own versions. The BSL containers are somewhat similar to Boost.Container's: they provide stateful allocators, as well as backport some C++11 extensions to C++03. Before I make all the necessary changes and do a pull request, I would like to make sure the Boost community would be ok in including support for this in Boost.Config. This library is fairly specific to one company and not used much elsewhere, despite being open-source (<https://github.com/bloomberg/bde>). We are also trying to phase out usage of this library with the 'std' namespace (it can be configured to use the 'bsl' namespace instead), but that's likely not going to happen anytime soon. As part as providing support for this in Boost, we would also be providing testers, mostly on big iron unix (AIX-powerpc, SunOS-sparc). Any interest?

3 4

Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
by Niall Douglas 28 Aug '15

28 Aug '15

On 25 Aug 2015 at 8:17, Robert Ramey wrote: > > Please answer the following questions: > > > > 1. Should Boost.AFIO be accepted into Boost? Please state all > > conditions for acceptance explicity. > > > > Provisionally, yes. > > > > Requirements: > <snip> > > This list of requirements constitutes much more than a "a few changes". > It's impossible to know what what the library would like like after > all these changes and and their repercussions were addressed. I don't > think we can realistically expect the review manager to verify that and > library with all these changes is sufficiently close the current one to > take responsibility for signing off on the final version. I read the provisional yes as meaning yes to how the library is roadmapped to look like in the future, and he recommends an additional mini-review at that point which could introduce yet another mini-review after again. In other words, he's saying fundamentally it's good, but needs a lot more work yet. Paul please do correct me if I am wrong in this interpretation. There is precedent for this: Boost.Fiber was provisionally approved here as a C++ 98 library with condition of a mini-review before entry. Boost.Fiber is now a C++ 14 library and sufficiently different from the library originally reviewed it may require a second mini-review if during its first mini-review it is felt still lacking. I think this pattern of repeated mini-reviews caused by changes to the common implementations of the C++ standard rather than the libraries themselves is going to be very common next few years. All these changes to AFIO are almost entirely driven by changes since 2012 to the various WG21 technical standards. If they hadn't changed and C++ compilers (specifically MSVC) hadn't changed, AFIO wouldn't have changed. It's very similar for Fiber, which had to be refactored in the face of substantial changes in C++ 14. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

7 16

[http] Formal review of Boost.Http
by Bjorn Reese 28 Aug '15

28 Aug '15

Dear Boost and ASIO communities. The formal review of Vinícius dos Santos Oliveira's Boost.Http library starts today, August 7th and ends on Sunday August 16th. Boost.Http is designed for various forms of modern HTTP interaction, from normal HTTP request, over HTTP chunking and pipelining, to upgrading to other web protocols like WebSocket. This library builds on top of Boost.ASIO, and follows the threading model of ASIO. The two basic building-blocks are http::socket, which is socket that talks HTTP, and http::message with contains HTTP meta-data and body information. You can use these building-blocks to build a HTTP server that fits your exact needs; for instance, an embedded HTTP server for a ReST API. Boost.Http comes with a light-weight HTTP server and a static file server. Currently, Boost.Http is limited to server-side interaction, but the design principles used extends to client-side as well. Boost.Http was originally developed as part of GSoC 2014 and Vinícius has continued to develop and improve the library since then. The documentation can be found here: http://boostgsoc14.github.io/boost.http/ The source code can be found here: https://github.com/BoostGSoC14/boost.http The source code is build using CMake, but Boost.Build is in the pipeline (already done for documentation.) Please answer the following questions: 1. Should Boost.Http be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain?

17 58

[http] Boost.Http review report
by Bjorn Reese 28 Aug '15

28 Aug '15

The outcome of the formal review of Boost.Http is that the library is NOT accepted for inclusion into Boost this time. Below I will first summarize the main themes running through the review, and afterwards I will make some recommendations about how to proceed from here. The following reviews were posted: - Antony Polukhin: No - Darren Cook: No - David Sankel: No - Lee Clagett: No - Niall Douglas: Yes, conditionally - Roland Bock: No - Tom Kent: No The discussions were constructive and offered much valuable feedback. There was a general consensus that Boost ought have a HTTP library, but that Boost.Http was too incomplete in its present state. Many reviewers mentioned the disconnect between their expectations and what the library offered. There were several suggestions for alternative names for the library to better reflect the feature-set it offers. Boost.Http currently only provides a server-side API, but the reviewers felt that a client-side API would be usable to more users. There was also a recurring request for Boost.Http to be a header-only library. The HTTP parser currently used is not header-only and that is the main obstacle towards a header-only Boost.Http library. Some of the discussion revolved around what level of abstraction would be appropriate for Boost.Http. The views ranged from wanting higher- level APIs all the way down to simply wanting a HTTP parser/generator and then leave all the socket and buffer management up to the user. Regarding the HTTP parser/generator, there is no reason why it cannot be a separate Boost library. However, Vinicius correctly pointed out that this is insufficient for a HTTP server framework that handles multipleback-ends (e.g. HTTP/2, FastCGI, or WebSocket). By implication it cannot handle HTTP upgrade requests either. Some reviewers also felt that HTTP/2 should be part of Boost.Http, partly because that would demonstrate the extensibility of the current design, and partly because the library would be in a stronger position to attract users if it offers more than its competitors. There was concern about whether or not the Boost.Http API can be extended to HTTP/2. The main challenge with HTTP/2 is fitting multiplexing into the API. Vinicius suggested that there should be a http::socket per multiplexed channel, so it will be transparent to the user if several of his http::sockets to the same remote endpoint are transported via the same TCP socket. This will keep the API clean when extended to HTTP/2. Boost.Http currently creates an associative array for all header fields. One reviewer explored the idea of using an incremental (push or pull) HTTP parser as part of the API to let users decide which header fields to copy and which to discard. There was a general consensus that more examples are needed, and that the tutorial should have smaller examples. The Boost.Http code base currently builds with CMake. This must be converted into Boost.Build before being integrated into the Boost code base. Several other third-party tools were suggested, but as these are not requirements for inclusion into Boost I will leave the decision to the author. As for the future, I hope that Vinicius is not too discourage by the current rejection, and that he will consider re-submitting the library at a later stage. Judging from the reviews, the following additions will make a future submission more likely to succeed: 1. Involve the community more during the development. This will both solicit earlier feedback on the design, and help to align community expectation. 2. Provide a client-side API. 3. Design higher-level APIs on top of the low-level APIs. 4. Better documentation and more examples. I also hope that people in the community will consider contributing to the library. For example, a good opportunity is to help creating the higher-level APIs. Another opportunity is to help with the (header- only, possibly incremental) HTTP parser/generator, which could be a separate library.

4 3