October 2016 - Boost - lists.stage.boost.cppalliance.org

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

[beast] Request for Discussion
by Vinnie Falco 12 Jun '17

12 Jun '17

Beast provides low level HTTP and WebSocket interfaces built on Boost.Asio, the project is here: https://github.com/vinniefalco/Beast The plan is to solicit feedback from the Boost community before submitting a request for a formal review. First a brief update: I have attended CppCon 2016 and provided a 15 minute Lightning Talk on the library. There should be a video up at some point with all the talks, including mine. I spread the word about Beast and discovered that there are several folks in the wild already using the library and happy with it. There are also a couple of commercial products that are using it. One point brought up during the conference is that Beast does not offer sufficient higher level HTTP functionality. This omission is intentional. It is my idea to offer the building blocks (serializing and deserializing HTTP/1 messages, in synchronous and asynchronous flavors, and a universal HTTP message model), upon which other developers more knowledgeable than me could build those interfaces. The higher level pubic operations requested were: 1. Perform HTTP GET or POST and receive the response. Presumably this would handle both plain and TLS connections, handle redirects, and handle HEAD requests. Not sure about traversing proxies. 2. Expose an asynchronous HTTP server class which callers can instantiate with some sort of handler that returns the HTTP response given a request. It should be possible, in a minimal number of lines, to quickly get a server up and running. The requestor informed me that this functionality did not need to provide every possible feature or handle every use case. It just needed to handle the common use-cases. For the record, I am against this higher level functionality for a number of reasons. The higher the level of functionality, the more contentious the feature becomes, and the harder it is to satisfy a quorum of reviewers. No one would dispute that we need the ability to read a complete HTTP message from a socket. But not everyone will agree that a HTTP server needs an option to allow multiple listening sockets with different level of permissions. Another problem with offering higher level functionality is that it could be less likely to be approved for standardization in the C++ standard library. For example, the attributes of ease of use and fully functional oppose each other. If the functionality offered by a hypothetical std::http::client is not sufficient, a developer would be forced to write their own with little possibility to reuse parts of the implementation from the stdlib. I doubt the committee would approve of such a thing. I know I wouldn't. Admittedly I have little experience or knowledge on what would or would not get approved. A point was raised that a low-level-only HTTP implementation in Boost has the potential to discourage new users that need to perform simple operations like HTTP GET from using Boost in the future, given that robustly handling such operations would require the developer to write a significant amount of code. I can see some validity here. On the other hand, if Boost.Asio was submitted for a formal review today, would those same points be raised? Would Asio get rejected because it doesn't offer public interfaces for doing simple tasks like requesting an object from a web server? I wonder if perhaps the Boost formal review process has become defective. For reference here is what the current API offers: Example program that performs HTTP GET, then receives and prints the response: https://github.com/vinniefalco/Beast/blob/master/examples/http_example.cpp This is a high performance asynchronous HTTP server that serves local files as static pages. It is not an official API, it is part of the examples. Users who want a server need to copy the source code and modify it to suit their needs: https://github.com/vinniefalco/Beast/blob/master/examples/http_async_server… My initial purpose for requesting this discussion is two-fold: 1. Determine the level of consensus on the issue that Beast needs to do more for HTTP than the lowest level of functionality (reading and writing messages). I'm open to hearing all arguments for and against. 2. Get feedback on what official public interfaces to higher level functionality might look like. Specifically, a client that handles GET and POST, and a generic asynchronous server. And what features those interfaces would support. For example, is traversing a proxy a necessary feature for an official client interface? The best answers would provide function signatures or class declarations using the existing Beast HTTP types. In case its not clear, I am asking stakeholders and reviewers to help design the library. I'll open a discourse on the HTTP client to illustrate the proposed style of discussion: We want to provide a HTTP client implementation that lets users perform simple tasks like fetch a resource from a remote host. Calling code should be compact, letting people get their job done without getting mired in boilerplate. Here's a possible signature with example use: response_v1<string_body> get(std::string const& url, error_code& ec); error_code ec; auto res = get("http://boost.org", ec); if(! ec) std::cout << res; else std::cerr << ec.message() << '\n'; The get function would automatically perform the name resolution, connect the socket, request the resource with uri "/", and return the result. There's a problem here though, the caller is forced to use a message with std::string as the container for the body. An obvious fix is to add a template parameter: template<class Body = string_body> response_v1<Body> get(std::string const& url, error_code& ec); Better, but what if the body is not DefaultConstructible? We can add some parameters to forward to the Body constructor: template<class Body = string_body, Args&&... args> response_v1<Body> get(std::string const& url, error_code& ec, Args&&... args); We're getting somewhere now. Most users will use the default body, while an option exists for advanced users. But the implementation of get now has a complication. If an error occurs, it still has to construct a return value. This problem is likely surmountable but lets table it and start a new line of reasoning. What if the URI indicates https, e.g. "https://boost.org"? We can hide that under the hood by using a separate code path that uses asio::ssl::stream instead of ip::tcp::socket. But how does the caller provide the root CA certificates? How does the caller provide a client certificate? We are left with a client that satisfies two thirds of users but is unusable for the remaining one third. Is this Boost worthy? Is this std-lib worthy? I think not. Lets revisit the SSL issues later and think about a new problem. What happens to the socket when the request is done? In the proposed interface, the socket is destroyed. This means you can only make one request on a connection. At this point, I think its clear that the current interface is a non-starter. Here's a better idea. Lets define a class called client and make get a member function. Now we can have state, including configurable settings with reasonable defaults. class client { public: template<class Option> void set_option(Option&&); template<class Body = string_body, Args&&... args> response_v1<Body> get(std::string const& url, error_code& ec, Args&&... args); }; client c; error_code ec; auto res = c.get("http://boost.org", ec); if(! ec) std::cout << res; else std::cerr << ec.message() << '\n'; We still have some of the original problems, but other problems are solved. The class can keep the socket around, so that a subsequent call to get with the same server will use the already-open socket. The caller can set options on the client object instance before invoking get, such as any TLS certificates. Unfortunately we have new problems. Where is the io_service? If the class creates it for you, how many threads? How do I use my existing io_service, or is that even necessary? The class interface allows the connection to be kept alive but what if now the caller wants to close it (i.e. specify "Connection: close" in the request)? And there are some problems which are applicable to any interface. How does the caller adjust the parser options, for example change the limit on the size of the body? What if the caller wants the request made using a specific HTTP version? How does this handle basic authentication? How can the caller adjust the headers in the request? etc... This is why I think that offering a HTTP client is a rabbit hole which can only lead to a rejected formal review. Or maybe I am overthinking this? I'd love to hear proposed solutions to the issues (which could be just to say "forget about those features"). Despite my objection I have started work on these features anyway. Here are the beginnings of a HTTP client: https://github.com/vinniefalco/Beast/blob/88b485df7e6216282842f40cf99cc75de… Here is some work on a generic server: https://github.com/vinniefalco/Beast/blob/server/extras/beast/http/async_se… Please reply to this thread instead of starting a new thread, and keep the subject line prefix (e.g. "Re: [boost] [beast] ...") Thank you

21 58

[msm] [statechart] unmerged PRs
by András Kucsma 23 May '17

23 May '17

Hi Everyone, There are a couple of PRs for msm and statechart by me and others, which didn't get any attention for many months now. Can the maintainers please take a look at them? https://github.com/boostorg/msm/pulls https://github.com/boostorg/statechart/pulls Thank you, Andras

2 2

[clang] clang-cl expansion of macros
by Edward Diener 29 Apr '17

29 Apr '17

You can get clang-cl ( clang-win ) to show its VC++ emulated expansion of macros somewhat by passing the c++ option '-fmacro-backtrace-limit=0' to the compiler. It is still blessedly difficult to see the what and the why of clang's error messages when expanding macro using clang-cl, but at least it gives you a better chance of understanding where clang's emulation of VC++ has gone wrong. I have posted bug 27380 to the llvm/clang bug tracker at https://llvm.org/bugs/show_bug.cgi?id=27380 showing the main failure in VC++ emulation which I see when testing Boost PP with clang-cl.

3 8

[container] moving a pre-built vector into a flat_set
by Sam Kellett 12 Mar '17

12 Mar '17

a common problem i encounter is that i have two stage's w/r/t to a large collection of data: building and querying. vector is obviously the king of building. flat_set is the king of querying. so what i often tend to do is build up a very large vector, sort it then create a flat_set using the flat_set(ordered_unique_t) constructor. however this still copies the entire vector into the flat_set, right? what i would like to be able to do is move the vector straight into the flat_set, something like: std::vector<T> data; flat_set data_set1(std::move(data)) // move vector in and sort it // or: std::sort(data.begin(), data.end()); // sort vector flat_set data_set2(ordered_unique_t, std::move(data)) // and move it in is this doable (am i just being blind?) or is there plans/interest for this?

8 19

[nowide] Library Updates
by Artyom Beilis 04 Mar '17

04 Mar '17

Hello, Disclaimer: --------------- I recently discovered that virtually all e-mails sent from Yahoo account to any mailing lists go to user's spam due to recent Yahoo's DMARC policy. So I'm sending some important stuff from GMail account that almost certainly was missed: What is Boost.Nowide: -------------------------------- Boost.Nowide is a library that make cross platform Unicode aware programming easier. The library provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. It was inspiration and inspired by http://utf8everywhere.org/ development ideas and policy. Some updates regarding Boost.Nowide ------------------------------- 1. Library moved to github and its format is converted to modular boost layout: https://github.com/artyom-beilis/nowide 2. Fixed unsupported std::ios::ate flag by boost::nowide::fstream 3. Added some C++11 interfaces to boost::nowide::fstream 4. Added integration functionality with boost::filesystem: https://github.com/artyom-beilis/nowide/blob/master/include/boost/nowide/in… Note: that the links to the source code on review schedule aren't relevant, it should be: - Code: https://github.com/artyom-beilis/nowide - Documentation: http://cppcms.com/files/nowide/html/ Also the library is still looking for review manager. Artyom Beilis P.S.: I'm sorry if you are getting this as "duplicate"

2 1

[teeks] Missing winerror.h for MSVC-9
by Andrey Semashev 17 Feb '17

17 Feb '17

Hi, I see lots of tests failing on teeks99-09b-win2012R2-64on64, MSVC-9.0 because winerror.h is missing. Here's an example: http://www.boost.org/development/tests/develop/developer/output/teeks99-09b… I can see that the file is present in Windows SDK 6.0A, which is supposed to be used with this compiler. The tests are passing on my machine. Could this be a tester configuration issue? Also, all MSVC-15 tests are failing on teeks99-09o-win2012R2-64on64 with the error of 'cl' not being found.

3 14

Why is this message in Spam?
by Olaf van der Spek 26 Jan '17

26 Jan '17

Hi, > Why is this message in Spam? It has a from address in microsoft.com but has failed microsoft.com's required tests for authentication. Learn more I think this list isn't configured properly.. and this causes some messages to end up in Spam consistently.. Who's responsible for the mailing list infrastructure? Gr, -- Olaf

7 12

Generating Boost documentation with pandoc
by Vinícius dos Santos Oliveira 18 Jan '17

18 Jan '17

Has anyone tried to generate Boost-styled documentation using pandoc? I never fully liked PDF documentation because I never actually print documentation. However, a few weeks ago I got an ebook reader and I've been fascinated by the ePUB format. I'm using it to read even the IETF's RFCs and it's very pleasant. I'm using ePUB to read files even on my usual laptop. Anyway, I was wondering how nice would be to have an ePUB file containing the whole Boost documentation. pandoc has docbook support as one of its input formats and is capable of generating great ePUB output. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 27

Re: [boost] [process] Formal Review starts today, 27 October
by Bjorn Reese 04 Dec '16

04 Dec '16

On 10/27/2016 08:26 AM, Antony Polukhin wrote: > - Whether you believe the library should be accepted into Boost > * Conditions for acceptance I withhold judgement for now to give the author an opportunity to respond. At the moment I am unsure whether to vote for conditional acceptance or rejection. > - Your knowledge of the problem domain Advanced on Unix. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design I have a couple of serious concerns. My first concern is about the use of tagged arguments, and especially the redirection operators, in constructors. Instead I propose that the library uses the Named Parameter idiom (see [1], not to be confused with what Niall labelled "tagged name parameter" idiom.) The bp::child object should not execute in the constructor, but rather via operator(). That way we can use the named parameter idiom to build up redirections and similar modifications. For example: auto compile = bp::child("c++").output(bp::null); compile("main.cpp"); // Executes My second concern is about deadlocking. The FAQ shows two ways of deadlocking. I would expect the latter (the ls example) to work without further ado because that is how any newcomer would write their code. My third concern is about the chaining of pipes between processes. The tutorial shows an example where the output of the nm command is forwarded to the c++filt command. However, the forwarding is not done directly from the nm process to the c++filt process, but goes via the parent process. This can incur a performance degradation when nm generates much output. Is it possible to chain them directly? Besides "nm myfile | c++filt" that is. I also have the following minor comments / questions. Is it possible to redirect stderr to stdout? (like 2>&1). The reference documentation only mentions this under asynchronous pipe output. The bp::starting_dir should be renamed to bp::current_path to be consistent with Boost.Filesystem. Consider renaming bp::spawn to avoid confusion with boost::asio::spawn which is how you launch coroutines with Boost.Asio. I am missing a this_process::get_id() function to return the current process identifier. > * Implementation My major concern with the implementation is that the library is only header-only, so I cannot compile it as a static library if I wish to. There are several Boost header-only libraries that allows you to do that. The reason why I find this important for Boost.Process is because I want to avoid getting platform-specific C header files included into my project when I include a Boost.Process header. The library should throw its own process_error exception which inherits from system_error, similar to Boost.Filesystem. I did not investigate the implementation in greater detail. > * Documentation The documentation is lacking an entire chapter with an overall description of the library and the concepts used. For instance: * What are processes and pipes? * What are the possible invocation mechanisms? Some of this is mentioned in the Design Rationale, but that is not the place where developers seek their information. * How to set search paths or the current working directory. * How to use environment variables. * this_process Tutorial / Synchronous I/O: What is the default behaviour when I/O redirections are not specified? Tutorial / Asynchronous I/O: Consider including an example with boost::asio::spawn as a way to obtain the yield context. Reference / child: Does not mention how the life-time of the object and the child process are related. For instance, the documentation on the destructor only mentions that it is a destructor. Reference / cmd: bp::cmd will parse the input string as a sequence of space-separated arguments. Is it spaces or whitespaces? Is it possible to have escapes for arguments that do contain spaces? > * Tests Did not investigate. > * Usefulness A process library is a very useful addition to Boost. > - Did you attempt to use the library? If so: > * Which compiler(s) > * What was the experience? Any problems? Did not try. > - How much effort did you put into your evaluation of the review? About 4-5 hours (one of which was gratuitously donated by daylight saving time.) [1] https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Named_Parameter

11 49