- Boost - lists.boost.org

Re: [boost] Outcome v2
by Groke, Paul 17 Jul '17

17 Jul '17

> From: Emil DotchevskiSent: Freitag, 14. Juli 2017 18:37 > To: boost(a)lists.boost.org > > Ah, now I get it, thanks for the explanation. There *might* even be a > way to get this to work even without memory allocation in the end > (without exception_ptr), but I think this is perhaps missing the point > of returning an error object, which is to be able to interact with it. > Also, reasonably if you could fit the things you need to create the > object into a "small object optimized" buffer, you can probably fit the > object itself into the same buffer. Noexcept already has that, it's the > result<T> object, however it might be too heavy to return up the call > chain one level at a time (it is instead designed for capturing the TLS- > stored object to postpone its handling, perhaps after moving it to > another thread). The question is: how do you interact with a return value of unknown type? For exceptions it's much easier. There is at least the common practice to derive your exception from std::exception, so if nothing else, you can at least get an error message. And you can catch base classes, which can also come in quite handy.

3 2

Boost libraries and Travis CI
by Edward Diener 16 Jul '17

16 Jul '17

Evidently to turn on Travis CI testing for a Boost library in Github you need to be the Administrator for that library, and not just a team member for that library. Is an Admin request the way to get Travis CI testing turned on for a library ? If not what is the proper way to turn on Travis CI testing for a Boost library once the .travis.yml file is added to the library ?

2 1

Regression tests on 'develop'
by Edward Diener 16 Jul '17

16 Jul '17

A number of regression tests on 'develop' have not been run for a long time. These includes Linux tests by 'Sandia' and 'teeks'. Does anyone know why these regression tests have not run for quite a while ?

1 0

Preprocessor directive for a sequence that differs only in datatype
by Rishabh Arora 16 Jul '17

16 Jul '17

Hello Everyone, I was trying to use the boost.preprocessor to write some code which otherwise needs to be written for all the cases. Here's the code: https://github.com/BoostGSoC17/dataframe/blob/master/include/df.cpp (line no. 430 and 431). But on compilation it gives the error: error: macro "BOOST_PP_SEQ_ELEM_III" requires 2 arguments, but only 1 given print_column <BOOST_PP_SEQ_ELEM(type, INNER_TYPE) >(i); I didn't understand the reason as when I wrote: print_column <BOOST_PP_SEQ_ELEM(any_numerical_value(0, 1, ...), INNER_TYPE) >(i); it works fine. Can anyone help me understand the error or provide an alternative way to do the same thing? Thanks in advance, Best Regards, Rishabh

3 6

[stacktrace][1.65 beta1] Problem with reference docs
by Joaquin M López Muñoz 16 Jul '17

16 Jul '17

The following http://www.boost.org/doc/libs/1_65_0_beta1/doc/html/reference.html displays BoostBook-related garbage rather than the real reference for the lib, unlike http://boostorg.github.io/stacktrace/reference.html Best, Joaquín M López Muñoz

4 5

[review][beast] Late review
by Christopher Kohlhoff 16 Jul '17

16 Jul '17

I realise this is quite late, but Vinnie asked for my opinion, so I asked for special dispensation from the review manager. Hopefully that is ok! In a nutshell, I think Beast should be accepted. Background: Although I may have some use for websockets in the future, my use case right now requires only HTTP (sorry Vinnie!). The use case involves incorporating HTTP protocol support into network applications whose primary purpose is something otherwise unrelated to HTTP. HTTP is used to support monitoring, configuration, and debugging facilities. Unlike typical HTTP use, the protocol is implemented not just over TCP sockets but also over local (UNIX domain) sockets. It is essential that the HTTP implementation minimises runtime overhead to avoid negatively impacting the quality of service for the other protocols. - What is your evaluation of the design? Overall the design is good. The library seems to be structured into several layers: 1. low level stateful parsers and serializers 2. operations to send/receive partial messages (*_some operations) 3. operations to send/receive header 4. operations to send/receive complete messages, using parser/serializer supplied by me 5. operations to send/receive complete messages This is a good thing, because it lets me select the appropriate layer for a particular use case. Whichever of layers 2 - 4 I choose, the best thing is that they all follow the same model for asynchronous operations as in Asio. All four of those layers work with arbitrary Asio streams, which was a requirement of my use case. This made using the library seamless, easily replacing my otherwise quick and dirty HTTP encoding and decoding approaches. The benefit of course is that someone else is taking care of ensuring the messages are well-formed, and doing a much better job of it. Layer 5 is good for simplicity and clarity. Based on my benchmarking, layer 4 seems to be the sweet spot for performance sensitive use cases, as it gives sufficient control of the placement of the "transient" objects used by the asynchronous operations. I use HTTP/1.0 almost exclusively, and one reason for this is that HTTP/1.0 allows the response to be sent without a Content-Length, with the end of content delimited by stream closure. One use for this is an infinite stream of data (e.g. monitoring output). Another use case is the ability to use the file descriptor as stdout for a child process. In both these cases, layer 3 fits the bill where I can send just the response header, and then take over the socket for my own needs. As for layer 2, the documentation for these functions still refers in places to a return value (or additional size_t argument to the completion handler), which is no longer in the code: synchronous read_some has a void return and async_read_some has a void(error_code) handler. Although this is probably vestigial documentation, actually I would prefer it if these lower level operations *did* return something, like the number of bytes transferred in the operation. This would assist in detecting badly behaved or pathological clients (like ones doing everything one byte at a time), and this is probably the main reason I would consider using the layer 2 operations. I haven't yet needed layer 1, but I can imagine how it might be used in transport agnostic code. I guess my main point is that by supplying all these layers, Beast is both powerful and flexible, and meets pretty much all of my likely needs. The body/reader/writer design feels a little awkward, and it seems like there is a more elegant design struggling to get out. However, my primary reason for looking at implementing a custom body was to support serving static files. As Vinnie now plans to include file support in the library itself, I have little reason to work directly with body/reader/writer directly any longer. Consequently, I am less concerned about the design here. However, I'd encourage Vinnie to keep exploring this. On a related note, once file body was added I was pleased to see how straightforward it was to incorporate platform-specific file transmission (TransmitFile, sendfile, etc) in a way that was transparent to the library user. There are some minor inconsistencies in template parameters, e.g.: parser has Allocator where serializer has Fields. I would have expected some symmetry here. The library includes reimplementations of a number of facilities from the networking TS. However, now the TS is done I plan to update Boost.Asio to match. If Beast is accepted then hopefully by the time it is incorporated, it will no longer need to include these at all. I'm not a huge fan of the library including typedefs for names from other boost libraries as part of the documented public interface, e.g. beast::error_code, beast::string_view. However, if it is to retain these, I'd at least like to see them given their own section in the documentation quick reference to make it clear that they are just aliases for external functionality. (Note: I'm just fine with the aliases themselves as a convenience for the library implementer.) - What is your evaluation of the implementation? The implementation is high quality. I do wonder about the implementation approach taken in the basic_fields storage. It uses a set, which is great asymptotically, but does mean allocation of a lot of small objects. In my experience (and in a totally unscientific survey of commonly used websites) the number of headers is usually small -- a dozen or two. In addition, when constructing or decoding a message, one would normally construct the set of fields in one go. Deletion of a field seems like it would be rare. Thus I wonder whether basic_fields could use a storage strategy geared towards the common case, e.g. a single storage blob for the fields themselves (vector<char>) plus an index (vector<size_t> of offsets to each field's beginning) for quick iteration. I don't think this would impact the API, so it's not essential. - What is your evaluation of the documentation? The documentation appears to be comprehensive. As mentioned above I did spot a few stray things that seemed to be left over from previous design iterations. There's also the occasional incomplete specification, e.g. basic_fields::at doesn't way what it does with multiple fields. Probably best to just raise these as issues. - What is your evaluation of the potential usefulness of the library? Very useful. It fits very well with my use cases. - Did you try to use the library? With which compiler(s)? Did you have any problems? Using gcc 6.1 on linux, I spent some time writing and rewriting several small http servers to evaluate the library, and Vinnie has now incorporated some of these into the beast repository as examples. Along the way I did discover some minor opportunities for improvement in the library, and Vinnie was quick to respond. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent many hours examining the library over a period of a few weeks, both before and during the review period. I gave the implementation and examples in-depth study, less so the documentation. - Are you knowledgeable about the problem domain? I hope Vinnie asked me to review Beast because I know a thing or two. However, I must qualify that: my experience in HTTP is almost entirely 1.0 and I only have a passing knowledge of websockets. Many thanks to Vinnie for creating Beast and proposing it for inclusion in boost. It is nice to see the addition of protocol implementations that build on top of Asio's asynchronous model so seamlessly. Cheers, Chris

1 0

Re: [boost] [Boost-users] Boost 1.65.0 Beta 1 [boost.python] issue
by Rene Rivera 15 Jul '17

15 Jul '17

On Fri, Jul 14, 2017 at 7:23 AM, Raffi Enficiaud via Boost-users < boost-users(a)lists.boost.org> wrote: > As I said in a previous post, I cannot get boost.python to build on > Windows: the target is just ignored (see stack trace below). > Missed that post :-( > I think there is a bug in .\tools\build\src\tools\python.jam A highly probable statement all on its own :-) > concerning the version computation: the variable "major-minor" is not set > properly if "version" is optional. > > In this block: > > ============= ("rule configure") > if $(version) > { > if ! $(version) in [ feature.values python ] > { > feature.extend python : $(version) ; > py$(major-minor[1])-version ?= $(version) ; > ============= > > The variable "major-minor" is empty. > > The "if" in the following block prevents from computing major-minor as > "version" is optional and is not set: > > ============= > local major-minor ; > if $(version) > { > major-minor = [ split-version $(version) ] ; > version = $(major-minor:J=.) ; > } > ============= > > I believe this can be fixed by recomputing "major-minor" in this block, > after "version" has been inferred. > > ============= > if $(cmd) > { > debug-message ...requested configuration matched! ; > > exec-prefix = $(sys.exec_prefix) ; > > compute-default-paths $(target-os) : $(sys.version) : > $(sys.prefix) : $(sys.exec_prefix) ; > > version = $(sys.version) ; > interpreter-cmd ?= $(cmd) ; > cmds-to-try = ; # All done. > } > ============= > Seems reasonable.. Can you put up a PR for that? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

Re: [boost] [fiber] PR: Replace #include "Windows.h" by "windows.h"
by Frédéric Bron 14 Jul '17

14 Jul '17

>> I have just checked and both mingw and mingw-w64 have only fully lower >> case >> headers. I just checked all includes files from boost (1.65.0 beta2) that have upper case character in their names and are present in mingw or mingw-w64 in lower case. Here is what I found: 3 files, Activation.h, Memory.h, Windows.h. Those are in the following files: ./libs/thread/src/win32/thread.cpp:36:#include <Activation.h> ./libs/iostreams/test/windows_pipe_test.cpp:9:#include <Windows.h> ./libs/process/test/bind_stderr.cpp:32:# include <Windows.h> ./libs/process/test/bind_stdin.cpp:34:# include <Windows.h> ./libs/process/test/sparring_partner.cpp:31:# include <Windows.h> ./libs/process/test/bind_stdout_stderr.cpp:30:# include <Windows.h> ./libs/process/test/exit_code.cpp:21:# include <Windows.h> ./libs/process/test/bind_stdout.cpp:32:# include <Windows.h> ./libs/process/test/group.cpp:32:# include <Windows.h> ./libs/process/test/spawn.cpp:33:# include <Windows.h> ./libs/process/test/spawn_fail.cpp:29:# include <Windows.h> ./libs/process/test/system_test1.cpp:38:# include <Windows.h> ./tools/build/src/engine/boehm_gc/MacOS.c:19:#include <Memory.h> ./boost/fiber/detail/futex.hpp:21:#include <Windows.h> ./boost/fiber/detail/cpu_relax.hpp:19:# include <Windows.h> So that is not a lot. For Memory.h, it seems related to MacOS, not Windows. If people really want to keep the upper case letter, we could then have #ifdef __MINGW32__ #include "windows.h" #else #include "Windows.h" #endif Frédéric Frédéric

1 0

[beast] Version 80: code review opportunity
by Vinnie Falco 14 Jul '17

14 Jul '17

Beast version 80 is sitting in the pull request queue if anyone is interested in providing a code review. This contains changes motivated by Bjorne's desire for more control over chunk-encoded output. <https://github.com/vinniefalco/Beast/pull/641> List of changes since beginning of the formal review: -------------------------------------------------------------------------------- * Javadoc tidying * Add basic_dynamic_body.hpp * Shrink buffer_prefix_view * Remove unused file_path * Add basic_file_body.hpp * buffers_ref is Assignable * Shrink chunk header buffer sequence size * Refactor chunked-encoding serialization * Remove spurious fallthrough guidance * Add span * Documentation work * Use make_unique_noinit * Fix warning in zlib * Header file tidying * Tidy up FieldsReader doc * Add Boost.Locale utf8 benchmark comparison * Tidy up dstream for existing Boost versions * Tidy up file_posix unused variable * Fix warning in root ca declaration * Tidy up basic_string_body * Add vector_body * span, string, vector bodies are public * Fix spurious uninitialized warning * fields temp string uses allocator * Add message::keep_alive() * Add message::chunked() and message::content_length() * Remove string_view_body * file_posix works without large file support * Always go through write_some * Use Boost.Config * BodyReader may construct from a non-const message * Add serializer::get * Add serializer::chunked * Serializer members are not const * serializing file_body is not const * Add file_body_win32 * Fix parse illegal characters in obs-fold * Disable SSE4.2 optimizations * Rename to serializer::keep_alive * BodyReader, BodyWriter use two-phase init * Use file_body for valid requests, string_body otherwise. * Construct buffer_prefix_view in-place * Shrink serializer buffers using buffers_ref * Tidy up BEAST_NO_BIG_VARIANTS * Shrink serializer buffers using buffers_ref * Add serializer::limit * file_body tests * Using SSE4.2 intrinsics in basic_parser if available * Add file_stdio and File concept * Add file_win32 * Add file_body * Remove common/file_body.hpp * Add file_posix * Fix Beast include directories for cmake targets * remove redundant flush() from example * Jamroot tweak * Verify certificates in SSL clients * Adjust benchmarks * Initialize local variable in basic_parser * Fixes for gcc-4.8 * basic_parser optimizations * Add basic_parser tests * Refactor header and message constructors * serializer::next replaces serializer::get * Tidy up set payload in http-server-fast * Refine Body::size specification * Newly constructed responses have a 200 OK result * Refactor file_body for best practices * Add http-server-threaded example * Documentation tidying * Various improvements to http_server_fast.cpp * Add websocket-server-async example * Fix extra ; warning * Documentation revision * Fix spurious on_chunk invocation * Call prepare_payload in HTTP example * Check trailers in test * Fix buffer overflow handling for string_body and mutable_body * Concept check in basic_dynamic_body * Tidy up http_sync_port error check * Tidy up Jamroot /permissive- * Fine tune websocket op asserts * Refactor websocket composed ops * Allow close, ping, and write to happen concurrently * Fix race in websocket read op * Fix websocket write op * Add cmake options for examples and tests * Return `std::size_t` from `Body::writer::put` Thanks

3 4

Re: [boost] [fiber] PR: Replace #include "Windows.h" by "windows.h"
by Frédéric Bron 14 Jul '17

14 Jul '17

>> Maybe we could use lower case windows.h only if __MINGW32__ is defined? > > It's still a fudge that might break. Isn't it better to get to the bottom of > the (MinGW-)problem (other headers are affected as well, as Windows.h is not > the only header starting with a capital)? That's right, we could look at all #includes in boost. I have just checked and both mingw and mingw-w64 have only fully lower case headers. Frédéric

1 0