- Boost - lists.boost.org

Regression testing: too many runners?
by Dmitry Moskalchuk 09 Feb '15

09 Feb '15

Guys, As you may know, I'm working on automatic regression testing of Boost on Android. I spent several weeks debugging it and now it seems to be close to the finish - i.e. we'll have soon fully automatic 24x7 regression testing with uploading all results to the Boost public FTP. As you can see, some results are already uploading on a regular basis - http://www.boost.org/development/tests/master/developer/summary.html (there are results of just few libraries at the current moment since I've limited testing by only those libraries to save time needed for debugging testing scripts; as far as I finish with my debugging, I'll enable testing of all libraries). However, I've realized that for thorough testing matrix of the variants become really big. Look, right now there are nine runners for Android, and this number is in fact very limited. They differs by target ABI (three arm variants, x86 and x86_64) and version of Android (API level 19 - Android 4.4 and 21 - Android 5.0). However, it has sense to test also on Android 4.0, 4.1, 4.2 and 4.3 since theirs market share is still large (see https://developer.android.com/about/dashboards/index.html) Add to that MIPS target ABI (not yet included to the testing) and multiple by two to have tests running with both default settings and with -std=c++11 - and you'll get really big total number of runners. I'm asking for advice from community. It's not the big problem for us to run all such tests in all variants, but I'm unsure if it will be acceptable for Boost community to see such wide table of runners. I'm afraid it will look like a flood. We also publish Android-only results on https://boost.crystax.net/master/developer/summary.html and we'll definitely display all results from all runners there. Please let me know if the same approach would work for http://www.boost.org/development/tests/master/developer/summary.html or should I limit somehow runners to be uploaded to the Boost FTP. -- Dmitry Moskalchuk

4 5

[githelp] Relative submodule paths..
by Rene Rivera 09 Feb '15

09 Feb '15

I've been trying to clean out the pull requests for the boost super-project and I ran into this one <https://github.com/boostorg/boost/pull/33>. And I don't really know if it makes sense, as I have personally not done a fork of the super-project. Is it a real problem? Should we change all the sub-project references? If yes, what are the likely impacts on others and existing release processes? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 5

[polygon] voronoi diagram in a bounding box
by Dan Chen 08 Feb '15

08 Feb '15

Hi all, I am not sure whether this is the right place to ask this question. Basically, I want to compute the the voronoi diagram of a set of points in a bounding box, and output the voronoi cells. My idea is, after getting the voronoi diagram vd of the point set, for each voronoi cell in vd, compute the intersection of the cell and the bounding box. I am wondering whether this can be done in a better way with the boost libraries. Thanks,Dan

2 1

[voronoi] Issue with boost::polygon::voronoi_diagram<> as class variable
by duke 08 Feb '15

08 Feb '15

For some reason when I have a voronoi_diagram as a class variable (which it needs to be in this case), I get this error on compile: Error 49 error C2248: 'boost::polygon::voronoi_diagram<T>::operator =' : cannot access private member declared in class 'boost::polygon::voronoi_diagram<T>' I'm new to C# so it may be something obvious. - George

2 1

[MPL] Advice on how to proceed with a bugfix pull request
by Bruno Dutra 08 Feb '15

08 Feb '15

Hello everyone, I've found a fix to this bug <https://svn.boost.org/trac/boost/ticket/7769#no3>, which is based on BOOST PP library and thus should be supported across the various platforms, even though I just tested for a specific set up as I mentioned on my comment there. I've added some code snippets, from which it is straightforward to develop a patch, but I guess it would be best if I just issued a pull request myself. Since this is my first time contributing to MPL and to BOOST itself for all that matters, I'd like to first hear some advice on how to do this properly. For instance, to which branch should I issue the pull request? By the way, is this indeed the best way to proceed at all? Kind regards, *Bruno C. O. Dutra*

2 2

A proposal
by Mudit Sharma 08 Feb '15

08 Feb '15

After creating QR,LU and Cholesky for Boost..can we develop algorithms for determining which of QR,LU,Cholesky..etc. should be used in solving linear equations based on analyzing the running time and numerical stability specific to the problem. Is it feasible? Thanks!

2 1

Re: [boost] A proposal
by Ganesh Prasad 08 Feb '15

08 Feb '15

LU is already implemented in UBLAS. As of QR, SVD and Cholesky you might want to spend more time in debugging and testing for any one or two of the algorithms. https://github.com/GnsP/viennacl-dev/tree/master/viennacl/linalg you can find some useful sources here. Best wishes Ganesh

1 0

[c++11] MSVC does not define __cplusplus?
by Oliver Kowalke 07 Feb '15

07 Feb '15

Hi, I encountered that '__cplusplus < 201103L' evaluates on MSVC (14.0 ...) to true?! At least on GCC + CLANG this test works - what about MSVC? best regards, Oliver

4 4

[new libraries] [sort] New Library Check list updated
by Beman Dawes 07 Feb '15

07 Feb '15

As we started through the process of adding the sort library as a module, it became obvious the docs for how to do this were quite out-of-date. The best document for adding new libraries is https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList#New…, and that section has now been updated. Although this document is written from the perspective of release managers, the New Library Checklist section serves as a roadmap for what is expected as a new library goes through the stages of being added to a Boost distribution. Comments and corrections welcome, --Beman

5 6

Serialisation: Is is_trivial<T> a sufficient precondition to bypass serialisation?
by Niall Douglas 06 Feb '15

06 Feb '15

A library user has raised an interesting question at: https://github.com/BoostGSoC13/boost.afio/commit/ac32ebfceb9a08b133e8c d47000d3b4807bc3e42#commitcomment-9574522 Basically, AFIO v1.3 has new pre-serialisation metaprogramming in response to Robert's comments on his Incubator about it being too hard to serialise and deserialise data with AFIO. AFIO will now consume any STL container and will implicitly auto expand to ASIO scatter gather buffers any: 1. Trivial type T 2. C array of trivial type T 3. STL container of trivial type T, including initializer_list. A free function, to_asio_buffers(T), can be specialised by external code to extend this with custom ASIO scatter gather buffers generation. Note that AFIO explicitly and intentionally expects that anyone interested in async file i/o will be doing their serialisation and endian conversion far away from AFIO code, so to_asio_buffers(T) is really for marking extra types to be treated as implicit auto expand. The user asks the question: Is is_trivial<T> a sufficient precondition for this auto expansion to be safe, or should is_standard_layout<T> also be required? The user notes that is_trivial<T> && is_standard_layout<T> == is_pod<T> which seems a little overkill to me. There is also the possibility that is_trivial<T> is too conservative. Some may argue that is_trivially_copyable<T> would be sufficient. Thoughts? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

5 7