March 2015 - Boost - lists.preview.boost.org

Re: [boost] [Boost-testing] Release branch purge policy request
by Jim Bell 14 Mar '15

14 Mar '15

On 2015-03-13 12:17 PM, Rene Rivera wrote: > On Wed, Mar 11, 2015 at 11:29 AM, Jim Bell <Jim(a)jc-bell.com > <mailto:Jim@jc-bell.com>> wrote: > > Just wanted to put this out there again since it seems to have > flown under the radar... > > http://lists.boost.org/boost-testing/2015/02/7926.php > > I suggest that, for the release branch, we lengthen the 15-day > purge to > 90 days or more. > > > My immediate answer is no. At minimum because.. > > Those looking to that matrix are determining where the last boost > release works or breaks for their platform. A different audience than > maintainers. > > > I don't see how extending the purge would address that. The master > branch testing is for the *next* release. Hence it doesn't say > anything about previous release (not even the last release). > While I agree that the master branch is for the next release, I'd dispute strongly that it doesn't say "anything" about previous releases. It says just about everything for those libraries which haven't undergone revision, and still says a lot--or at least something--for the rest. My personal experience has been finding the bug I suspected in a library by looking at the matrix, sometimes with the library a couple revs out of date. Just guessing, but I'd say it's a pretty good bet statistically that a yellow mark on the master regression will still be yellow after 90 days (at least). When a boost user looks at an out-of-date matrix, what does (s)he see for his/her platform? Mostly green (hopefully!), some yellow that's been fixed (maybe!), some that hasn't. That's more valuable than seeing nothing at all. Please reconsider. (Ok, ok, 90 days is pretty long, but still...) Cross-posting with the main list since (I say) the audience is wider.

1 0

[GSoC] Enhanced vector and deque proposal
by Benedek Thaler 14 Mar '15

14 Mar '15

Hi, The initial version of my proposal to the `Enhanced vector and deque` project is ready, please check it out; feedback is welcome: https://gist.github.com/erenon/70e36f6a7d7725cf8767 Thanks, Benedek

1 0

Re: [boost] GSOC 2015 : Project on Concurrent Hash Tables
by Amarnath V A 14 Mar '15

14 Mar '15

Thanks for the prompt reply Niall. I have got a few more questions. 1. I could not make out the use of _oldbuckets in the code. What purpose does it serve? 2. I see a swap() function which is not used anywhere in the codebase. Is it dead code? 3. And I have a generic question regarding std::atomic. I was trying to code the move constructor and finally ended up failing miserably to move the reference of _bucket. I could not figure out how to do it. Could you point me to some documentation which would help me to achieve the same. To give a fair idea about my last question, let me elaborate what I was trying to do. I have got the reference of _buckets and have assigned it to new variable using store and load methods of atomic. But, I am not confident if that is the right way to go about. And secondly, I see that I am not able to reset the reference of original. Thanks, Amarnath

3 26

GSoC '15 Enhanced Vector and Deque
by Pranav Vaish 14 Mar '15

14 Mar '15

Hello, My name is Pranav. I had sent an email on this mailing list earlier regarding some doubt in the implementation of the programming competency test for this project. I have gone ahead and written some code. The code is incomplete. Iterator code has not yet been written and container methods and some error handling is left. I would appreciate it if someone could review my code and tell me what else I will need to implement. #ifndef BOOST_VECTOR #define BOOST_VECTOR #include<exception> #include<iostream> struct exception_push_back_capacity_exceed : public std::exception { const char * what () const throw () { return "Vector Capacity Exceeded"; } }; namespace boost { template<typename T> class vector { public: vector(int); ~vector(); void push_back(T); T operator[](const int& pos) { return *(mem_start+pos); } private: T* mem_start; int size; int capacity; }; template<typename T> vector<T>::vector(int capacity_constr) { size=0; capacity=capacity_constr; mem_start = new T[capacity]; } template<typename T> vector<T>::~vector() { delete [] mem_start; } template<typename T> void vector<T>::push_back(T val) { try { if(size==(this->capacity)) { throw exception_push_back_capacity_exceed(); } mem_start[size++]=val; } catch(exception_push_back_capacity_exceed& e) { std::cout<<e.what()<<std::endl; } } } #endif As I am new to contributing for Open Source, I'm not sure if sending links on this mailing list is disrespectful or not. If it is I apologize for this. Code can be found on https://github.com/vaishious/boost.vector Thanks -Pranav

2 2

[thread] Testing with Sanitisers (ASAN, TSAN, MSAN)
by Ben Pope 13 Mar '15

13 Mar '15

I'm going to be bringing up some more testers, and I wondered if the results are meaningful, or can be made meaningful. The tester is "BenPope x86_64 Ubuntu", first available results are for TSAN, and it shows some failures. I'm under the impression that some of the sanitisers may need to be taught about certain constructs in order to be effective (e.g. boost::detail::atomic_increment: http://www.boost.org/development/tests/develop/developer/output/BenPope%20x…) Other failures look legitimate at first glance (e.g. Cycle in lock order graph: http://www.boost.org/development/tests/develop/developer/output/BenPope%20x…) I shall endeavour to get nicer stack traces, I think I need to tell it about llvm-symbolizer, althouh I haven't always had success in the past, any advice or suggestions are welcome. Ben

3 8

[ GSoC 2015 ][ Vector ]
by Afonso Tinoco 12 Mar '15

12 Mar '15

Hello, I'm a student who would love to participate on GSoC 2015, in the '5. Enhanced vector and deque containers' category. First of all I'm trying to engage the community, so... hum... hello world! I'm rigth now begining to take the competency test [1], but I could not understood whether I should write a boost biased implementation or not. This is, may I write a container based on no other boost .hpp just as a PoC that will have better readability and will take (far) less time to code, or should I write something similar to the boost vector implementation [2]? [1] https://svn.boost.org/trac/boost/wiki/SoC2015#Programmingcompetencytest3 [2] https://github.com/boostorg/container/blob/master/include/boost/container/v… Best Regards, Afonso Tinoco --------------------------- Aerospace Engineering Student Instituto Superior Técnico dedos(a)tecnico.ulisboa.pt

1 0

Documentation typos. RE: Boost 1_58_0_rc1 is available for testing
by Fletcher, John P 12 Mar '15

12 Mar '15

I have found a few documentation typos and have them on develop. Is it O.K. to put them onto master as well? Thanks John

2 1

release1.58 -- Permission to merge Boost.Optional
by Andrzej Krzemienski 12 Mar '15

12 Mar '15

Hi, I have three bug fixes in Boost.Optional on branch develop waiting to be merged to master. Apparently I missed the deadline for the Beta release. Is there any chance I can still put them into 1.58 release? Can I merge the bug fixes to master? Regards, &rzej

2 1

[GSoC '15] Boost Documant Library development
by Abhinav Tripathi 12 Mar '15

12 Mar '15

Hi, I am 2nd year B.Tech Student in IIT Indore,India. I have pretty much experience (approx 7 years) with C++ and many of its libraries... I am interested in development of the Document Library for Boost. I have a rough idea on what exactly is required in the project and am quite interested in doing this one. I was looking for any suggestions/comments to help me get going in this direction. . Regards, Abhinav

1 0

Re: [boost] [Boost-maint] [context, config] Always setting address-model and architecture (Was: Conflicts when building libraries at root)
by Vladimir Prus 11 Mar '15

11 Mar '15

On 02/18/2015 05:55 PM, Jürgen Hunold wrote: > Hi Volodya, > > Am Mittwoch, 18. Februar 2015, 14:28:48 schrieb Vladimir Prus: >> On 01/05/2015 10:37 PM, Jürgen Hunold wrote: >>> >>> Unfortunately, we still have Boost.Context open. >> >> Okay, so the problem we're facing is that building master results in: >> >> error: Tried to build the target twice, with property sets having >> error: these incompatible properties: >> error: >> error: - none >> error: - <address-model>32 <architecture>x86 >> >> What happens is this: >> >> - Context library is built >> - It detects default address model and architecture of the current >> toolchain, and adds those to requirements >> - Since there's a global dependency on 'headers' target, this pretty much >> immediately rebuilds everything with new address-model and architecture >> properties. > > Not correct: Boost.Context needs Boost.System so it requires a build with > those properties. As they have currently have no defaults, the explicit values > differ from the implizit default (none) for both. Well, it my brief check, it was the headers->system path that first requested system with address-model=32. Anyway, it does not matter for the rest of this discussion. >> - We get property set clash > > Correct. > >> One way to solve this is to restructure Boost.Context setup so that added >> properties do not escape. It's doable, but probably will be fragile. > > No doubt. > >> Another way is to take libs/context/config, move it to libs/config, and make >> sure these properties are applied globally. That seems preferable. John, >> any objections? > > I thought the correct way would be to move the architecture detection upwards? That's roughly what I propose, too - but there are few further tweaks and options. > We would need something along those lines (from context/bulld/Jamfile.v2) > > alias select_asm_context_sources > : asm_context_sources > : [ architecture.architecture ] > [ architecture.address-model ] > ; > > in boostcpp.jam in order to detect the architecture everywhere. It would then > be helpfull to have sensible default values in order to shorten the generated > paths for those defaults. Right, so steps would be: 1. Move actual tests into config (we do need to have a few cpp files) 2. Move architecture.jam into either Boost.Build or boostcpp.jam 3. Make sure we don't generate extra path elements for default address model 4. Introduce a way to do these tests without requiring a bunch of .cpp files - sure Boost.Build can generate them on the fly. 5. Make these checks be automatic for all projects. It seems that 1-2 should solve the immediate problem, and 1-3 should be pretty good, although going all the way to 5 would be cool. > Another solution would be to generate a "header-only" variant of Boost.System > and use this nearly everywhere. This would solve *lots* of dependency > problems... Not sure I have an opinion on that. -- Vladimir Prus CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software/

7 13