- Boost - lists.boost.org

Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
by Brian Wood 19 Aug '14

19 Aug '14

Niall Douglas writes: > > Such a design would not make good use of hardware DMA such that use > of the CPU can be completely avoided for bulk data transfers. To > invoke hardware DMA, all i/o must be done from 4Kb aligned memory > buffers. Indeed AFIO can enforce that for you because it's so > important to performance. > > Generally if you're bothering to use async i/o, you have no interest > in *ever* copying memory. That rules out all serialisation usually :) How about calling it OS-level serialization? I don't think the need for message framing goes away. Somehow the length of a message has to be calculated and put in place. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

GSoC: Pipeline status
by Benedek Thaler 19 Aug '14

19 Aug '14

Hi, As GSoC is coming to its end, I'd like to present you the Pipeline library: code: https://github.com/erenon/pipeline documentation: http://erenon.hu/pipeline I'll continue to work on this project, the next big thing is to implement a coroutine based execution. I hope using cooperative scheduling will enable a much better throughput/latency combination over the nice and easy to use interface we currently have. Thanks, Benedek

1 0

[serialize] Noncopyable errors in the latest 'master'
by Edward Diener 19 Aug '14

19 Aug '14

In testing out libraries which use Boost PP, with clang as the compiler, I am seeing a great deal on 'master' of: > ..\..\..\boost/archive/detail/basic_serializer.hpp:35:7: error: 'operator=' is a private member of 'boost::noncopyable_::noncopyable' > class basic_serializer : Does anybody know what this is all about ? It is occuring in a number of libraries using serialization.

1 0

[GSoC] [Boost.Hana] Status update
by Louis Dionne 18 Aug '14

18 Aug '14

Dear Boost, Summer of code is coming to its end, and I think this is a good time to give an update about Hana and what's going to happen next. In early august, I asked for a review of Hana. As a result, I got many comments and questions which helped me improve the library and also take the pulse of the C++ community. Ever since the review, I've been working on improvements and modifications to the library and its documentation. Thanks to all of those who gave comments, and especially to those who experimented with the library and reported problems/thoughts. My initial (personal) objective was to push a new library in Boost by the end of the summer. I now realize that this is unlikely to happen given the amount of work that's left and the amount of time on my hands. That being said, I still think Hana solves the problem of C++ metaprogramming in a very elegant way, and I'm not giving up on its development because GSoC ends. Hence, I will continue working on the project as much as my studies allow it and I plan to ask for informal reviews during fall. Eventually, I still hope to fulfil my initial goal of making Hana available to a wide audience via Boost. I would also like to mention that I will be presenting Hana at CppCon 2014 in september; consider attending if you followed the project this summer. Finally, I would like to thank everyone that was involved with making my participation to GSoC possible; I worked hard, had a lot of fun and I think my work (or at least derivations of it) will be useful to Boost and the wider C++ community given enough time. Regards, Louis

1 0

Debugger Visualizers discussion
by Antony Polukhin 18 Aug '14

18 Aug '14

Hi all, There is project that contains a bunch of XML files. Those files can be used to improve debugging on MSVC: For example: * using this project debug view of `boost::variant<int, float> i(1);` will show `1` instead of raw memory and internals of boost::variant. * optional<boost::container::string> will show string content or `none` instead of ram memory and some unreadable internals Maybe we should embed those files into the Boost? It would be great to have some magic bjam command `b2 install-debug` after which VisualStudio becomes aware of Boost classes. Files for pretty debugging could be also written for GDB. Will it be useful? Link o the project: https://github.com/KindDragon/CPPDebuggerVisualizers Files are located at https://github.com/KindDragon/CPPDebuggerVisualizers/tree/master/VS2013/Vis… -- Best regards, Antony Polukhin

3 3

[git] [filesystem] [system] [timer...] Remove useless SVN branches?
by Beman Dawes 18 Aug '14

18 Aug '14

Boost library repos converted from Subversion are littered with branches created by the conversion process that seem to me to be quite useless. For example, Boost filesystem has 65 branches, yet only 10 or so have any usefulness I'm aware of. A lot of the useless branches have names that begin "sandbox" or "svn-". I go back to the subversion repo when I want to look at pre-git-conversion history. Is there any point in retaining these branches? Does anyone object if I remove these branches from the libraries where I am the maintainer? What are other maintainers doing about stale branches? --Beman

3 2

clang and variadic macro warnings revisited
by Edward Diener 18 Aug '14

18 Aug '14

After making pull requests for a number of Boost libraries in order to reduce the warnings from compilation from clang using the Boost PP library, John Maddock suggested a specific solution, as Niall Douglas had suggested a general one before, that changes in the Boost PP library could get rid of these extraneous warnings. Originally I thought this would be too difficult and intrusive in Boost PP but after reading John's specific suggestion I decided to try to implement it. The suggestion John made was to surround code in Boost PP which uses variadic macros with: # ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wvariadic-macros" # endif // variadic macros # ifdef __clang__ # pragma clang diagnostic pop # endif This was actually easier than expected since all code in Boost PP which uses variadic macros is surrounded by: # if BOOST_PP_VARIADICS #endif // eventually Of course there are many files changed by this but overall it is very straightforward. This technique does work for the diagnostic "-Wvariadic-macros". Hooray ! Unfortunately the second situation involving warnings, where clang warns about: warning: empty macro arguments are a C99 feature [-Wc99-extensions] coming from what I only see as a specific place in Boost PP in variadic/elem.hpp is not conducive to the same technique. In other words surrounding that one macro with: # ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wc99-extensions" # endif #define BOOST_PP_VARIADIC_ELEM(n, ...) BOOST_PP_CAT(BOOST_PP_VARIADIC_ELEM_, n)(__VA_ARGS__,) # ifdef __clang__ # pragma clang diagnostic pop # endif does not eliminate the warning at all ( I have reported this on the clang developers mailing list ). And since that macro is heavily used in Boost PP this warning occurs quite often when compiling Boost library code using Boost PP wih clang. The only other intrusive Boost PP solution to this problem is to treat clang like gcc as far as Boost PP variadic macro code is concerned: if the end-user compiles with one of the 'std=' dialects which explicitly supports variadic macros, such as 'std=c99', 'std=c++0x, 'std=c++11', then variadic macros are turned on in Boost PP for clang, else they are turned off. Do realize that both gcc and clang support variadic macros even when one of the 'std=' dialects are not chosen, and that in fact clang has always supported variadic macros. Also changing Boost PP support for clang and variadic macros would be a regression from the way it is now where it is always supported. In retrospect, when I changed Boost PP from never supporting variadic macros for clang ( Paul's original conservative choice ) to always supporting variadic macros for clang, I gave in to an outcry that clang users should have variadic macro support in Boost PP. It would have been wiser to follow the gcc method in Boost PP. But that is past and we need a good solution now. Thoughts ? Solutions ? Brickbats <g> ?

3 3

[endian] Was: [Boost-testing] All runners on develop are failing.
by Rene Rivera 18 Aug '14

18 Aug '14

---------- Forwarded message ---------- From: Tom Kent <lists(a)teeks99.com> Date: Fri, Aug 15, 2014 at 8:13 PM Subject: [Boost-testing] All runners on develop are failing. To: Running Boost regression tests <boost-testing(a)lists.boost.org> It is looking for the endian library...which I have, but is still failing. error: Unable to find file or target named error: '../libs/endian/' error: referred to from project at error: '.' I did a: git checkout develop git pull git submodule update --init on my repository, which caused the previously empty endian directory to be populated, but still getting the error. Thoughts? Tom _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[algorithm] Interface for longest_increasing_subsequence (proposal)
by Curdeius Curdeius 17 Aug '14

17 Aug '14

Hi all, I want to propose a new algorithm to Boost.Algorithm: a well-known longest increasing subsequence <https://en.wikipedia.org/wiki/Longest_increasing_subsequence> (LIS for short). Just for a short info: given a sequence like ( 7 )( 2 )( 8 )( 1 )( 3 )( 4 )( 10 )( 6 )( 9 )( 5 ), the result will be a subsequence ( 1 )( 3 )( 4 )( 6 )( 9 ). The proposed algorithm has O(n log n) time and O(n) complexity, where n - sequence length. I have created a pull request https://github.com/boostorg/algorithm/pull/7. I have however some questions. I am not sure what should be the exposed interface. For the moment, I propose (I base it on the existing interface from algorithm/searching functions): - class longest_increasing_subsequence with methods - operator() - *compute_length* (a better name may be needed) - free function longest_increasing_subsequence_length returning the length of the LIS and taking as arguments: - a pair of iterators (first, last) - or a range - and (optionally) a comparison predicate - *free function longest_increasing_subsequence_search taking the same arguments as _length function and an Output Iterator or a tag.* - free function make_longest_increasing_subsequence taking a range and optionally a comparison predicate and returning corresponding longest_increasing_subsequence object The problematic part is the underlined longest_increasing_subsequence_search function and the way in which I should return the resulting LIS. I see possibilities like the following: 1. taking an OutputIterator argument: the best for me, generic and the most flexible solution, but there is a performance hit as we cannot reserve the memory for the output LIS. 2. returning a container with the subsequence, e.g. std::vector<value_type>: no performance hit with small objects or if the user needs a vector of values. However, not really generic as the user would be obliged to use a vector (in the aforementioned example). 3. returning a container with iterators, e.g. std::vector<InputIter>: good if a container of iterators is acceptable, it has a benefit of avoiding possibly expensive copies of sequence elements. As 2., not really generic. 4. -taking a container as an argument: the worst solution in my eyes, there is no way nice way to write generic code that handles all containers. I have coded possibilities 1-3. Thank you in advance for all the comments, corrections etc. Regards, Marek Kurdej

1 0

[testing] Proposal - regression tests results display upgrade
by Adam Wulkiewicz 17 Aug '14

17 Aug '14

Hi, Currently test failures of a new feature are always marked with the yellow color and a word 'fail'. Would it make sense to use some more descriptive color/naming scheme? In particular it would be nice to distinguish between the actual failures and the situations when the compilation of a test took too much time or an output file was too big. Would it make sense to also distinguish between compilation, linking and run failure? E.g. instead of a simple 'fail' use 'fail (c)', 'fail (l)' and 'fail (r)'. E.g. the color for actual failures could be orange and for "others" could stay yellow. Furthermore, currently it's impossible to see the results of compilation if a test passed. Would it make sense to change it? This would allow us to view and fix warnings even if the test was passed. The test passed with warnings could be marked e.g. with 'pass (w)' or the color could be set to some between yellow and this light green. If you directed me where it should be done I could try to change it. I'm guessing it would require modifying some script generating the page and some CSS? Regards, Adam

6 10