- Boost - lists.preview.boost.org

[math] Efficient polynomial multiplication
by Lakshay Garg 18 Jul '17

18 Jul '17

Hello all This is my first post to the mailing list. While looking at the source code for polynomial multiplication (boost/math/tools/polynomial.hpp) I discovered that the library used O(N^2) algorithm for multiplication. I would like to work on implementing a more efficient algorithm (complexity: O(N log(N))). I am writing this mail to get views and feedback from the community and have a healthy discussion before starting the work. Lakshay

5 8

Introducing the X++ Programming Language
by Phil Bouchard 18 Jul '17

18 Jul '17

Hello Boost / Qt, By taking advantage of the simplicity of the code of Javascript, the power of C++ and the deterministic C++ memory manager Root.Ptr, I decided to write my own programming language which takes advantage of all these powerful features. On the downside Javascript suffers from a slow garbage collector that kicks in randomly which makes it impossible to write real-time engines and C++ just doesn't have any objective memory manager up to this day. My initial attempt was to convert Javascript into C++ but then the principle of 'closures' and 'escape analysis' inlaid with Javascript just makes it impossible to get rid of the garbage collector. So if we sacrifice these principles away then we can integrate Root.Ptr and take advantage of the power of C++ and the true flexibility and run-time features of Javascript. It has to be noted that X++ is an extension of C++ and therefore everything we can do in C++ can also be done in X++. You can find the source code here: https://github.com/philippeb8/root_ptr/tree/x++/xpp2cpp And the benchmarks indicate X++ is 2.7 faster than Node.JS! Note that the language is still in a preliminary state but we can already compare it. Furthermore, in theory, is should be possible to offer a service which compiles the executables for combinations of major architecture / OS only once, cache these executables on the webserver and executing them in a specialized container on the client's desktop. Thus, in theory, we would be able to execute real-time engines from within our own browser! So I am including Boost because one day X++ could be merged with the C++ programming language and I know Boost is well used in the vast gaming industry which requires real-time engines. Regards, -Phil http://www.fornux.com http://www.finitetheory.com https://www.actatabula.com https://github.com/philippeb8/root_ptr/tree/x++/xpp2cpp

3 7

Error handling libraries and proposals
by Emil Dotchevski 17 Jul '17

17 Jul '17

Last week it was brought to my attention that there are currently 5 different libraries and proposals for dealing with the problem of reporting errors from noexcept functions, so I thought it would be useful to update the Noexcept documentation with a short section comparing all the different designs: https://zajo.github.io/boost-noexcept/#alternatives.

6 43

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