- Boost - lists.preview.boost.org

(Fwd) Re: Thoughts on Boost v2
by Niall Douglas 21 May '14

21 May '14

Seeing as the original did not reach the mailing list. N ------- Forwarded message follows ------- Date sent: Wed, 21 May 2014 07:02:20 -0700 (PDT) From: Robert Ramey <robertmacleranramey(a)gmail.com> To: boost-devel-archive(a)googlegroups.com Copies to: boost(a)lists.boost.org, boost(a)lists.boost.org, s_sourceforge(a)nedprod.com Subject: Re: [boost] Thoughts on Boost v2 On Wednesday, May 21, 2014 4:49:37 AM UTC-7, Niall Douglas wrote: > > > > We welcome C++14 libraries and I see no problem with a submission on > > that basis alone if it is supported by at least two compilers. > > For me personally, I would vote for an instant rejection for any > library not compilable to the MSVC ABI irrespective of any other > factors. FYI a review is not a vote. Acceptance/Rejection is not a democratic process. The review manager has the authority to accept/reject based on his assessment of the quality of the library independent of the number of "votes" it receives. Long standing boost policy is that there is no explicit requirement that any code conform to any specific compiler as long as it complies with the current standard. There is no requirement that it use specific features (e.g. from more recent standards) to the exclusion of more traditional (albeit still conforming) features. Indeed, a number of libraries have been submitted and accepted that don't compile on multiple compilers. Robert Ramey ------- End of forwarded message ------- -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Boost contributing tutorial (GitHub)
by Adam Wulkiewicz 21 May '14

21 May '14

Hi, I prepared a tutorial about the contributing at GitHub/Boost describing how to create a Fork of a library, use it inside modular Boost and create a pull request. The tutorial presents examples for Boost.Geometry but could be extended to the other libraries. It has a form of a README of this repository: https://github.com/awulkiew/temp-contributing Would you be so kind and see if everything is ok wth it? In praticular I'd like to hear if this model is good for modular Boost in general? Regards, Adam

3 5

[smart_ptr] Proposal to add new memory order constants
by Andrey Semashev 21 May '14

21 May '14

Hi, I have a proposal to add new constants to the memory_order enum: memory_order_hle = 16, memory_order_hle_acquire = memory_order_hle | memory_order_acquire, memory_order_hle_release = memory_order_hle | memory_order_release These constants can be used to support Intel HLE (Hardware Lock Elision) [1] in Boost.Atomic and then reused by Boost.Sync. The meaning of these constants is Intel-specific (for now): the memory_order_hle_acquire operation has memory_order_acquire ordering and also starts a transaction; memory_order_hle_release operation has memory_order_release ordering and also commits the transaction. On other targets memory_order_hle flag is ignored and memory_order_hle_acquire and memory_order_hle_release are equivalent to memory_order_acquire and memory_order_release, respectively. The support for these constants can be implemented in the following Boost.Atomic backends: - all x86 assembler-based backends. - gcc __atomic* builtins support __ATOMIC_HLE_ACQUIRE and __ATOMIC_HLE_RELEASE flags (at least, gcc 4.8 and Intel compiler 14.0.3 for Linux). - MSVC x86_64 supports Interlocked intrinsics with _HLEAcquire and _HLERelease suffixes. There are also _Store_HLERelease, _Store64_HLERelease and _StorePointer_HLERelease. Unfortunately, these only cover 32 and 64-bit types, for other types regular atomics will be used (i.e. HLE won't be used). For 32-bit x86 asm blocks are also a possibility; all types can have HLE support. BTW, maybe Boost.Atomic is a better place for memory_order.hpp? What do you think? [1] https://software.intel.com/sites/products/documentation/doclib/stdxe/2013/c…

2 7

[filesystem] Request for comments on proposed relative() function
by Beman Dawes 20 May '14

20 May '14

There are two open tickets requesting a relative() function, and also a National Body (I.E official) comment against the Filesystem TS (which is due to finalize at the June C++ committee meeting). The committee's Library Working Group has indicated they would like to add such a function. With help from Jamie Allsop, I've put together a proposal. See attached for docs. See https://github.com/boostorg/filesystem/tree/feature/relative for a branch of filesystem with the implementation and some relative() tests added. Comments appreciated. --Beman

9 37

Viewing the group via http://post.gmane.org misbehaving again.
by Vladimir Batov 20 May '14

20 May '14

For example, Edward's thread (started May 12th) [boost] Boost review of the 'convert' library starts tomorrow May 21 shows only 2 messages in post.gmane.org. Google https://groups.google.com/forum/#!topic/boost-developers-archive/40it9qkZUhA show all 6 messages. I see the same problem -- missing messages -- in other convert-related threads that I follow.

3 2

Re: [boost] Is there any interest in a library for actor programming? serialization + uniform names
by Charousset, Dominik 20 May '14

20 May '14

The serialization and uniform name really boils down to the uniform_type_info class: Uniform names are simply a necessity if you need to identify a type based on its name. The goal is to send any kind of value to a remote machine and being able to deserialize it. If you have platofrm-independent names, you can simply prefix the binary serialized value with its type name and then get the RTTI (uniform_type_info) from the type name and deserialize the rest of the data. Boost.Actor is a bit more cleverer than that and maintains a list of type ids for each node it's connected to. Whenever you send a message with a type you didn't use beforehand, you send the type name along with its newly generated, unique ID and only use that ID going forward. But that's just an optimization. When talking about stateless communication (e.g. UDP), you can't do this and have to generate self-consistent messages. The fact that we even have to do this, is because std::type_info::name() is utterly useless. It returns a mangled name on GCC/Clang and a more sophisticated version of the type name on MSVC. The uniform name is the type name as it appears in code. So the first part of generating the uniform name is to demangle the platform-dependent name (https://github.com/Neverlord/boost.actor/blob/master/src/demangle.cpp) After that, we need to decompose the whole thing and make sure that qualifiers are always in the same order etc (https://github.com/Neverlord/boost.actor/blob/master/src/to_uniform_name.cpp) All this really is only aiming at having at type_info that is actually useful, i.e., name() returns *the exact same string* on each platform and it provides you with an interface for (1) generating values, (2) serializing and deserializing values, and (3) compare values. When generating a value through an uniform_type_info, you'll get a uniform_value, which is bascially a wrapper keeping {uniform_type_info*, void*}. Since we need a way to pass a serializer to a uniform_type_info instance, we can't use a templated approach as the archives in boost.serialization. The serialization classes in use (https://github.com/Neverlord/boost.actor/blob/master/boost/actor/serializer…) operate on sequences and primitive types. With the begin_object member function you also have a way of define serialization recursively, but I don't know if it's really needed to be honest. The write_tuple member function is probably not needed either, since you can simply just write the values one by one. However, it does give you a way of grouping values representing a single member together, which can be quite helpful when serializing to strings for instance. By the way, each announced type in Boost.Actor implicitly has a to_string(), which simply passes the value to a string serializer. There's also a from_string() that passes the input to a string deserializer, which gives you a simple way of injecting messages to the system. But the whole string serialization is not really fleshed out and the format not well defined. ________________________________________ From: Boost [boost-bounces(a)lists.boost.org] on behalf of Hartmut Kaiser [hartmut.kaiser(a)gmail.com] Sent: Tuesday, May 13, 2014 20:46 To: boost(a)lists.boost.org Subject: Re: [boost] Is there any interest in a library for actor programming? serialization + uniform names I'd be interested in hearing more details about this. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > -----Original Message----- > From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrzej > Horoszczak > Sent: Tuesday, May 13, 2014 8:16 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Is there any interest in a library for actor > programming? serialization + uniform names > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 5

Call for Review: Boost.Test documentation rewrite
by legalize+jeeves＠mail.xmission.com 19 May '14

19 May '14

[Please do not mail me a copy of your followup] Boost.Test documentation rewrite: <http://user.xmission.com/~legalize/tmp/boost.test/libs/test/doc/html/> Please post all comments to this list. I've been working on this as time permits for a number of months and I think now things are "finished" enough to warrant wider review. It is a true rewrite using quickbook; I generally used the implementation source code as the answer to my questions about things while writing the documentation. Early snapshots were reviewed by Tom Kent, Alexander Lamaison, Paul A. Bristow and Julian Gonggrijp. A special thanks to them for providing me with useful feedback and suggestions. The main thing that still remains to be added is a detailed explanation of the floating-point comparison algorithms used by BOOST_REQUIRE_CLOSE, BOOST_REQUIRE_CLOSE_FRACTION and BOOST_REQUIRE_SMALL. The corresponding examples also need to be updated. The existing online documentation has had all the math symbols stripped out of it, so it is pretty useless. I'm probably just going to typeset the formulas with LaTeX and then capture them as images that are included in the documentation. (See <https://svn.boost.org/trac/boost/ticket/9539>) I'm guessing that modular boost should allow me to clone libs/test, make all my changes there and then issue a pull request, but I'm not sure how far along things are with the git transition? -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

14 48

Trac request states - suggestion
by Neil Groves 19 May '14

19 May '14

Dear Boost Developers, While working with Trac to maintain Boost.Range I find that I frequently have solved issues but they are not ready to be merged to master due to the release schedule. I haven’t noticed a way in Trac to denote that the issue is fixed and waiting to be merged. This means that I frequently look up tickets that I have forgotten I have fixed. It also means that I have a sub-optimal process for merging to master. I wondered if we might be able to squeeze in a “fixed in branch” field. It would help me considerably. Do other developers think this would help? Do you solve this in another, perhaps better way? I’m happy to lend development time to get this done if there is consensus and we can risk me having write access to Trac code! Thanks, Neil Groves

5 5

Re: [boost] [algorithm] Review Request: edit_distance
by Ahmed Charles 19 May '14

19 May '14

Marshall will probably be busy for the next few weeks. Have you asked Ron about review manager approval? ________________________________ From: Erik Erlandson Sent: 4/14/2014 7:20 PM To: boost(a)lists.boost.org Subject: Re: [boost] [algorithm] Review Request: edit_distance ----- Original Message ----- > > > > - Have you looked at the supposedly better algorithm "An O(NP) > > > > Sequence Comparison Algorithm" by Sun Wu, Udi Manber, and Gene > > > > Myers ? > > > > > I've been doing more cross-testing and benchmarking against the current > > O(ND) > > version. The latest O(NP) prototype is passing randomized cross-testing > > and is now about 25% faster than the O(ND) baseline. My latest prototype code based on O(NP) is now running about 35% faster than O(ND) in my benchmarking: https://github.com/erikerlandson/algorithm/blob/order_np_alg/include/boost/… > > I wrote up a blog post that describes the various ideas I applied to get this > result: > > http://erikerlandson.github.io/blog/2014/02/20/a-bi-directional-variation-o… _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

think-cell is using boost
by Volker Schöch 19 May '14

19 May '14

Hi, We would like to be listed in the Shrink Wrapped Boost section on the boost.org website: http://www.boost.org/users/uses_shrink.html · The name of the Application/Product/Service. think-cell · The name of the company (where appropriate). think-cell · A paragraph describing the Application/Product/Service. think-cell was founded in 2002 in Berlin and is today the leading vendor of productivity software for professional PowerPoint users. Its product suite covers the complete process of presentation creation - from analysis and preparation of business data to the graphical rendering of qualitative and quantitative results. Most international business consulting firms, as well as a large number of the well-known industrial global leaders, are among think-cell's customers. · Any information you can provide about which parts of Boost you used, along with any comments you may have on how Boost helped your product development. C++ is a great and versatile programming language, but only with boost it is a powerful development tool that facilitates really efficient programming. Our code is beautiful, concise and easily maintainable thanks to the following boost libraries: Algorithm, Assign, Config, Conversion, CRC, Date Time, Format, Fusion, Geometry, Integer, Interprocess, Intrusive, Iostreams, Iterator, Math Common Factor, Math/Special Functions, MPL, Multi-Array, Multi-Index, Numeric Conversion, Operators, Optional, Phoenix, Preprocessor, Proto, Range, Smart Ptr, Spirit, String Algo, Swap, Tribool, Tuple, Variant If you are looking for more information on what development problems we are facing every day go to our C++ Developer job posting<http://www.think-cell.com/career/jobs/development.shtml>. · URLs to your company's home page, and the home page of the Application/Product/Service if there is one. http://www.think-cell.com/ Thanks! Volker -- Volker Schöch | vschoech(a)think-cell.com<mailto:vschoech@think-cell.com> Senior Software Engineer We are looking for C++ Developers: http://www.think-cell.com/career ________________________________ think-cell Software GmbH http://www.think-cell.com<http://www.think-cell.com/> Chausseestr. 8/E phone / fax +49 30 666473-10 / -19 10115 Berlin, Germany US phone / fax +1 800 891 8091 / +1 212 504 3039 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schödl

1 0

Crisis, What Crisis ?
by Francisco José Tapia 18 May '14

18 May '14

When , in previous days, I had read messages about the dead of Boost, I stopped to think about it. I think Boost is not dead, even , it have an excellent health, but have problems related with the growth , in the same way than when a young, pass to be adult. Many things must be done in a different way. Every day I see new developers proposing new ideas. If one day, you don't see new ideas and new developers you can certificate the death of Boost. The value of Boost compared with other libraries is that the code is tested, and a company trust in Boost and use their libraries in their internal process and applications, this is not true with many others libraries. I think we must separate the interest of the Boost users and the Boost developers. The developers, usually, are people with great level of knowledge and experience , and the users usually don't have that level. Due this , many times times, the interest of the developers and the users don't agree. Many of the new libraries proposed, in absence of a detailed explanation, are incomprehensible by the majority of the users. If you don't improve the design of the opponent, copy it. Perhaps we must learn about others web as stack overflow , and extract ideas for our web system. I think we must extend the mechanism used for the errors, to the consults of the users. Must be easy and don't need to inscribe. The actual mechanism of the list , I think is appropriate for the developers. Many of the Boost libraries are included in the C++ standards, this show the quality of the library. But I don't think that the people use a boost library, being included in the standard and provided by the compiler. I think we must design an ordered close of that libraries, and locate in a part for to provide utility to the users of old compilers. This reduce the number of libraries and help to improve the clarity and simplicity of the library. Boost had become a very big structure, and perhaps , the actual procedures for to take decisions are not appropriate, in the same way that there are people with a great knowledge and experience and other just arrived, and their opinions can have the same value. I think it is a good idea to create an executive board, elected between the Boost members, in order to take the important decisions. One of the first decisions is what to do with the libraries pending of revision, and the acceptance of new libraries without reviewer. As commented before, we can have libraries very interesting for the developers, and uninteresting for the users, and the opposite. My library COUNTERTREE,( parallel algorithms over Red-Black trees, with random access iterators) is waiting since near two years ago. It's something new, don't exist nothing similar. I had showed to companies (Intel , Google, Valve ...), universities (Stanford, Texas A&M, Carlos III , Stony Brook...) and people of the C++ environment ( Scott Meyers, P.J.Plauger , ) , with a great acceptation. But in their home, Boost, is waiting since near two years, and a good idea stopped is a dead idea. I would like to know if it is interesting in Boost, in order to continue with the development ( there are many algorithms and functionality for to do ), or if it is not interesting, spend my time in others questions, leaving frozen the code. These are only my opinions, open to discuss and new ideas. I am sorry , because the English is not my native language, and it's hard for me to express the details of my ideas. Anyway, I offer my work and my collaboration, for to improve OUR Library. If I can be useful, please, say me and I will try. Yours Francisco Tapia fjtapia(a)gmail.com You can find the code and the documentation in my web pages in dropbox https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/index.html or if you prefer in a git format https://github.com/fjtapia/countertree_2.0

1 0

Re: [boost] [Boost-users] Stability of serialization across boost versions
by Brian Wood 18 May '14

18 May '14

Sohail Somani > On 18/05/2014 4:34 AM, John Maddock wrote: >>> Any feedback or suggestions other than not using boost for serialization? >> >> It was my understanding that stuff like that should be supported, if you >> have a test case then filing a bug report would seem to be in order? > > Based on the error, it seems like what is happening is that a newer > version of Boost is attempting to communicate with an older version of > Boost. The actual exception is from the archive itself, IIUC. The > library has explicitly said this is not supported, unfortunately. > > To the OP, I'd suggest not upgrading Boost serialization or requiring > upgrading in lockstep. Upgrading multiple hosts in random order means > new communicating with old. This is an unsupported use case. I have a serialization option. It isn't a Boost library, but it has support for some Boost types and we're willing to add support for other Boost types. -- Brian Ebenezer Enterprises - "He who *refreshes* *others* will *himself* be refreshed." Proverbs 11:25 http://webEbenezer.net

1 0

Re: [boost] Community Maintenance Team and neglected libraries
by Ahmed Charles 18 May '14

18 May '14

I'll be sure to take a look at the outdated pull requests when you send them to the cmt list. ________________________________ From: Beman Dawes Sent: 5/15/2014 3:35 PM To: Boost Developers List Subject: Re: [boost] Community Maintenance Team and neglected libraries On Tue, Apr 22, 2014 at 11:36 AM, Daniela Engert <dani(a)ngrt.de> wrote: > Am 22.04.2014 18:29 schrieb Ben Pope: > > There are quite a few places where the library code is probably fine, > > but the failure is in the test itself, the fix is often simple and > > uncontroversial. > > ... > > The responses have been frustrating to say the least, we really need a > > way to move forward on this. > > > You're so true with your observation. I'm a bit disappointed too. > > I'm sitting on a pile of simple patches to cleanup the existing tests > such that I don't have to wade through a morass of level-4 msvc compiler > warnings when running the test suite. This requires both fixes to some > of the libraries themselves (thereby finding real bugs on the way) and > fixes to the test code to get the tests compiled in the first place. > It's those sanitized libraries that I supply to my colleagues for > production code because it's our policy to be absolutely clean on > level-4 warnings. Some months ago, I've prepared some of those patches > (more yet to come) for inclusion into boost mainline, and some of them > were picked up. The rest of my pull requests seems to be neglected. I > prefer to refrain from spamming the mailing lists with reminders, but is > there a better way to get the message through? Dealing with > quality-of-implementation issues and acting like a janitor might not be > the most sexy job in the universe, but I'm happy to do it (rather than > just sitting on the fence) as long as it has an effect, eventually. > This is one of the specific examples we have been discussing at C++Now in Aspen this week. * You did the right thing when you submitted pull requests. * Your should get some form of response within a reasonable period of time. It will take the CMT awhile to put a specific time on "reasonable" but certainly a month with no response is not reasonable. * Please post a message on the CMT mailing list, with links to the pull requests that you haven't heard anything about. It is their responsibility to decide how to proceed. * If you have questions about global maintenance changes touching many libraries, the CMT list is the best place to ask for guidance. The CMT folks care about maintenance so it is not spamming the list to ask them maintenance related questions. HTH, --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost iterators are not SFINAE-friendly
by pfultz2 17 May '14

17 May '14

Boost iterators aren't SFINAE-friendly. This is a problem when building traits that detect certain behavior. Heres a simple example: #include <vector> #include <type_traits> #include <boost/iterator/filter_iterator.hpp> template<class> struct holder { typedef void type; }; template<class Iterator, class=void> struct is_advanceable : std::false_type {}; template<class Iterator> struct is_advanceable<Iterator, typename holder< decltype(std::declval<Iterator>() += std::declval<int>()) >::type> : std::true_type {}; static_assert(is_advanceable<std::vector<int>::iterator>::value, "This will pass"); struct predicate { template<class T> bool operator()(T&&) const; }; static_assert(not is_advanceable<boost::filter_iterator<predicate, std::vector<int>::iterator>>::value, "This won't pass"); Although, it doesn't always lead to a compile error(rather than subtitution failure), it does lead some very erroneous errors. Thanks, Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-iterators-are-not-SFINAE-friendly-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[utility] Moving addressof out of Boost.Utility
by Glen Fernandes 17 May '14

17 May '14

I was informed the eventual plan is to get rid of Utility as a sub-module, and I observed that Assert was moved out already. If there's any interest in (and no objection to) moving boost::addressof out of it, I don't mind making that change. What would be the most appropriate home for it? A Boost.AddressOf sub-module similar to Boost.Assert? Glen

4 6

wiki/Git/GitHome should list the repo address
by Josh Juran 17 May '14

17 May '14

Hi, I websearched 'boost git', and the top result was the GitHome wiki page. It would be helpful if this page included the address of Boost's Git repository near the top. <https://svn.boost.org/trac/boost/wiki/Git/GitHome> Josh

2 1

Application need a Review Manager. Anyone is interested?
by Renato Forti 17 May '14

17 May '14

Hi All, The proposed Boost.Application, needs a Review Manager. Anyone is interested? The project: https://github.com/retf/Boost.Application Thanks

4 3

[optional] new version in master
by Andrzej Krzemienski 16 May '14

16 May '14

Hi Everyone, This might have been too hasty, but I have put a new version of Boost.Optional on branch master. Tests in 'develop' and 'master' branches pass fine, but I am not sure what it says about overall stability of the library. The changes include: - Move semantics, interoperable with std::move_if_noexcept() -- i.e., move operations are conditionally noexcept; - Using explicit operator bool() rather than custom 'safe-bool idiom' --on applicable platforms; this will break code that exploited the security hole in safe-bool idiom. - Now, you cannot bind optional<T const&> to a temporary (the constructor and assignment taking T&& is deleted);this also break some usages that are likely buggy, but there is a macro to put it back. - Comparison with boost::none does not require that T be EqualityComparable: we just forward the call to operator bool() od operator!(). - optional<T&&> is explicitly prohibited. - some operations are marked noexcept (on platforms that support the keyword). - Rewritten some portions of documentation. I encourage everyone with spare time and available resources to test the version and give us feedback. Please remember that this is supposed to be an incremental improvement over the previous version (for Boost 1.56.0), and next upgrades are planned in the future. Regards, &rzej

2 1

[context] Using Boost.Context on the BlueGene/Q
by Thomas Heller 16 May '14

16 May '14

Hi list, I was very happy to see that Boost.Context has been fixed for PPC64. Thanks a lot for that. I was able to verify that the fix worked on the BlueGene/Q. Both on the Head node, which is a POWER7 and the compute nodes which are a PowerPC A2. However, in order to build the library, I needed to manually call the assembler as the predefined commands did not work. For example, the BG/Q provided assembler doesn't know the "--64" switch and the assembler i want to use is called bgclang-as instead of plain as. For the compute nodes, I additionally want to use the -ma2 flag to have the proper assembly generated. Is there a way to have that configurable by the user? Right now, the only way i could find to fix that is to manually edit the Jamfile.v2 in the context build directory. Any advice or hints to fix it properly are highly appreciated. Thanks, Thomas -- Thomas Heller Friedrich-Alexander-Universität Erlangen-Nürnberg Department Informatik - Lehrstuhl Rechnerarchitektur Martensstr. 3 91058 Erlangen Tel.: 09131/85-27018 Fax: 09131/85-27912 Email: thomas.heller(a)cs.fau.de

2 2

Re: [boost] Community Maintenance Team and neglected libraries
by Edward Diener 16 May '14

16 May '14

On 4/22/2014 12:29 PM, Ben Pope wrote: > In case you haven't heard of the CMT: > https://svn.boost.org/trac/boost/wiki/CommunityMaintenance > > I'm also interested in getting the test results less yellow and more > green, I don't have a lot of time, I'm sure I'm not alone. > > There are quite a few places where the library code is probably fine, > but the failure is in the test itself, the fix is often simple and > uncontroversial. > > Without picking on any particular library or author, here are some > examples: > > * Link the tests with boost::system > http://thread.gmane.org/gmane.comp.lib.boost.maint/92 > * Merge existing fixes in develop to master > http://thread.gmane.org/gmane.comp.lib.boost.devel/250129 > * Fight with casts > http://thread.gmane.org/gmane.comp.lib.boost.devel/250143 > * Disambiguate a type > https://svn.boost.org/trac/boost/ticket/9540 These refer to system, MPI, utility, and assign. None of these are in the list of libraries which the community maintenance team has write acces to apply fixes. Hopefully the developers who do have write access to these libraries will look at the issues involved.

5 7

Re: [boost] Community Maintenance Team and neglected libraries
by Daniela Engert 15 May '14

15 May '14

Am 22.04.2014 18:29 schrieb Ben Pope: > There are quite a few places where the library code is probably fine, > but the failure is in the test itself, the fix is often simple and > uncontroversial. > ... > The responses have been frustrating to say the least, we really need a > way to move forward on this. > You're so true with your observation. I'm a bit disappointed too. I'm sitting on a pile of simple patches to cleanup the existing tests such that I don't have to wade through a morass of level-4 msvc compiler warnings when running the test suite. This requires both fixes to some of the libraries themselves (thereby finding real bugs on the way) and fixes to the test code to get the tests compiled in the first place. It's those sanitized libraries that I supply to my colleagues for production code because it's our policy to be absolutely clean on level-4 warnings. Some months ago, I've prepared some of those patches (more yet to come) for inclusion into boost mainline, and some of them were picked up. The rest of my pull requests seems to be neglected. I prefer to refrain from spamming the mailing lists with reminders, but is there a better way to get the message through? Dealing with quality-of-implementation issues and acting like a janitor might not be the most sexy job in the universe, but I'm happy to do it (rather than just sitting on the fence) as long as it has an effect, eventually. Ciao Dani

3 2

[GitHub] List open pull requests for all libraries? [resend]
by Beman Dawes 15 May '14

15 May '14

We need to be able to monitor the open pull requests for all Boost libraries, not just a individual library. I'm not seeing any canned way of doing that via the GitHub web site. Am I missing something? It does seem possible to access the required information via the GitHub API. Is that the best approach to take? Does anyone know how to do this? Thanks, --Beman

8 14

[test] Regression tests and boost.test merge questions
by Antony Polukhin 15 May '14

15 May '14

Hi, I'm just curious about the situation with Boost.Test. When will be the latest changes merged to master? Regression tests for master branch use develop or master version of Boost.Test? This is vital for me because TypeIndex library must be tested with RTTI off, but master version of Test fail to compile in that way. Compilation of Boost.Test in RTTI-off mode was fixed in develop branch. -- Best regards, Antony Polukhin

1 0

required toolsets
by Steven Watanabe 15 May '14

15 May '14

AMDG The list of required toolsets in explicit-failures-markup.xml is out-dated. Therefore, if no one objects, I propose setting it to the following: msvc-10.0, msvc-11.0, gcc-4.6, gcc-4.7, clang-darwin-11, clang-darwin-4.2.1, clang-linux-3.1, clang-linux-3.2, gcc-mingw-4.7, gcc-mingw-4.6 (two releases of each major compiler that appears in both the trunk and release regression tests) The sole effect of this is to determine which toolsets appear in the issues list: http://www.boost.org/development/tests/trunk/developer/issues.html In Christ, Steven Watanabe

10 32

[atomic] Support for specialized instructions
by Andrey Semashev 14 May '14

14 May '14

Hi, I've been contemplating the idea of adding support for some specialized atomic instructions to Boost.Atomic. Since I'm only familiar with x86 architecture, my current candidates are: * Increment/decrement with a check for zero result (lock inc/dec). The decrement is the most essential of the two because it would be useful for reference counters of various kinds. The increment is mostly beneficial in terms of code size, and it probably doesn't need the check for zero in most cases. * In-place logical operations (lock and/or/xor). These are useful in cases when the code needs to operate on flags or bit sets but doesn't need the result of the operation. Optional variants can be provided with a test for zero result. * Bit set/reset operations (lock bts/btr). The use cases are similar to the logical operations but the advantage is that the previous value of the altered bit can be returned. BTW, these operations are needed in Boost.Sync to implement mutexes on Windows. All these operations can be implemented through the standard atomic<> interface, and that's what would be done on platforms without support for the specialized instructions. For now the idea is to add special member functions to atomic<>, when used with arithmetic types. I was thinking about providing free functions as well, although I think that the complete set of the standard atomic functions would be required for that. Comments? Opinions?

4 6