- Boost - lists.boost.org

[test] boost.test owner unresponsive to persistent problems for multiple years
by legalize+jeeves＠mail.xmission.com 18 Mar '15

18 Mar '15

[Please do not mail me a copy of your followup] See <https://svn.boost.org/trac/boost/ticket/10888> and <http://stackoverflow.com/questions/5209625/boost-test-error-messages-are-no…> Both contain a fix for this. On stack overflow the proposed fix is literally a single line change. This has been a problem for about 5 years and these simple fixes don't make it into the library. I'm sorry, but IMO this just isn't acceptable behavior for an owner of a library. Four years ago the maintainer made a comment on stack overflow thread to file a ticket on trac and then simply dropped the issue there as far as I can tell. That isn't proactive behavior, particularly when the stack overflow thread contains the fix. I know what you're going to say "the trac ticket was just filed a few days ago", but that's simply me pushing hard on something that should have been fixed around 2010. The problem has been known FOR FIVE YEARS and is EASY TO FIX. -- "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>

24 77

Re: [boost] Better late than never - command line interface to on line code generator
by Brian Wood 18 Mar '15

18 Mar '15

Rob Stewart writes: > On March 17, 2015 4:04:39 PM EDT, Brian Wood <woodbrian77(a)gmail.com> wrote: >> In 2007 there was some discussion here about on line >> code generation: > > Online generation of what kinds of code from what kinds of inputs? > The output is C++ serialization/middleware code. One thing it does is automate (and maintain) the creation of serialization functions. There are three kinds of input: 1. C++ header files. It doesn't support template definitions, but it can handle a lot of container classes. Here's an example of a header it can handle: http://webEbenezer.net/misc/account_info.hh . 2. Something called "middle" files. These describe the messages that you want to send and receive. Here's some middle code from a file called remote.mdl: middle_messages_back @out (messageid_t, std::vector<cmw_account_info>) @out (messageid_t, cmw::marshalling_integer, cui_generator) @out (messageid_t) } ----------------------- end of middle code ----------------------------------- The name, "middle_messages_back," is used as the name of a namespace in the generated output. @out means you want code generated to send a message. 3. Something called a request file that ties the first two types of input together. Here's an example: Header account_info.hh Header cui_generator.hh Middle-File remote.mdl Type-Used-for-Constants int16_t ------------------------ end of request file ------------------------------------- Header files are optional. One middle file is required in a request file. And here's the output that's generated from those inputs: http://webEbenezer.net/misc/zz.middle_messages_back.hh >> >> http://webEbenezer.net/build_integration.html > > That jumps right into the middle of the topic and assumes prior knowledge of the > context. > >> So now I would like to ask for further thoughts and >> feedback. How can it be improved? It has support for some >> Boost types and I'm open to adding support for more. Tia. > > You might start by clarifying the purpose of the tool. Ok, thanks for your comments. -- Brian Ebenezer Enterprises http://webEbenezer.net

1 0

Better late than never - command line interface to on line code generator
by Brian Wood 17 Mar '15

17 Mar '15

In 2007 there was some discussion here about on line code generation: http://lists.boost.org/Archives/boost/2007/02/116997.php One thing I said back then was: "There isn't a library to download." That's changed and now there's an archive that can be downloaded: http://webEbenezer.net/build_integration.html Martin Slater, commenting on the fact that the only way to use the code generator was through a web interface, said: "the fact that it cannot be integrated into the build process easily ... would deter many from using it" I agreed with him on that point at the time and have spent a lot of time since then developing a command line interface to make it easy to integrate on line code generation into build processes. The archive mentioned above is the result of that work. So now I would like to ask for further thoughts and feedback. How can it be improved? It has support for some Boost types and I'm open to adding support for more. Tia. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

2 1

Running b2 on develop needs asynch-exceptions=on
by Paul A. Bristow 17 Mar '15

17 Mar '15

After a recent pull of develop branch, I found that I also need to add asynch-exceptions=on to avoid a failure to build error: Tried to build the target twice, with property sets having error: these incompatible properties: > error: - <asynch-exceptions>off > error: - <asynch-exceptions>on (This is in addition to needing address-model=32 architecture=x86) b2 address-model=32 architecture=x86 asynch-exceptions=on I wasn't clear if this thread had come to a conclusion? [boost] [test] Re: Conflicts when building libraries at root http://lists.boost.org/Archives/boost/2015/03/220552.php looks as though a fix is still needed? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

11 24

Boost release 1.58.0 beta 1 is now available from SourceForge
by Marshall Clow 17 Mar '15

17 Mar '15

Boost release 1.58.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost/1.58.0.beta.1/ <http://sourceforge.net/projects/boost/files/boost/1.58.0.beta.1/> This release contains three new libraries: • Endian: Types and conversion functions for correct byte ordering and more regardless of processor endianness. • Sort: includes spreadsort, a general-case hybrid radix sort that is faster than O(n*log(n)) • WinAPI: For details of what's in the release, see http://www.boost.org/users/history/version_1_58_0.html <http://www.boost.org/users/history/version_1_58_0.html>. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. IMPORTANT NOTE: There is a bug with the build scripts; you have to specify the address-mode and architecture to b2. I used: ./b2 address-model=64 architecture=x86 (this will be fixed before the final release) Thanks, -- The Boost Release Team

3 4

Re: [boost] Boost 1_58_0_b1_rc2 is available for testing
by Aparna Kumta 17 Mar '15

17 Mar '15

I have few GitHub PR's that have been merged into the develop branch but not made it into the rc2 candidate. What would be the procedure to get them in? Thanks, Aparna ----- Original Message ----- From: mclow.lists(a)gmail.com To: boost(a)lists.boost.org Sent: Friday, March 13, 2015 9:51:58 AM GMT -08:00 US/Canada Pacific Subject: [boost] Boost 1_58_0_b1_rc2 is available for testing Release candidate files for 1.58.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Changes since rc1: * Added the new libraries endian, sort, and winapi. IMPORTANT NOTE: There is a bug with the build scripts; you have to specify the address-mode and architecture to b2. I used: ./b2 address-model=64 architecture=x86 to test this. The files (and associated md5s) are: MD5 (boost_1_58_0_b1_rc2.7z) = c58623e8c3d48154bdb1fa2ee5cdbfab MD5 (boost_1_58_0_b1_rc2.tar.bz2) = 94480c2d9de3804a1a4b626a7828bec0 MD5 (boost_1_58_0_b1_rc2.tar.gz) = f7d4b398388c13ca30960c92b8d6342f MD5 (boost_1_58_0_b1_rc2.zip) = 2e9bdfd8dab269a69e4ea4e5ae5b6d47 Thanks! -- The release managers _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[mpl] multiset
by Bruno Dutra 16 Mar '15

16 Mar '15

Hi Folks, Anyone knows what's up with this so called "multiset" I just found fiddling with the source code? The poor thing seems to have been left unfinished :( Any reasons anyone would not just go ahead and try bringing it to life? I would definitely be up to take the first step, I just don't know whether not I should carry on with it, I mean, isn't the whole purpose of all this is encouraging people like myself to take the step ahead and just do it? Anyways, MPL seems to have seen better days of activity back in the day, there's lots of opportunities for improvement still and I for one would be glad to help developing some fancier features. I'd be glad to hear what you guys have to say. Best regards, *Bruno C. O. Dutra*

23 93

Concurrent Unordered Map
by Petrisor Cosmin-ioan 16 Mar '15

16 Mar '15

Hello, My name is Cosmin Petrisor and I'm currently enrolled in the 3rd year of study (junior year) of the Computer Science program, at University Politehnica of Bucharest.I posted on boost g+ community, but no one replied. I am currently implementing the copy and move constructors. I managed to figure out how rehash is working and the copy constructor is almost done. On the other hand, is ok to use the copy constructor in the implementation of the move constructor? Something like: concurrent_unordered_map(concurrent_unordered_map &&old) BOOST_NOEXCEPT :concurrent_unordered_map((const concurrent_unordered_map &)old){ old.clear(); } or would be better to implement the copy and move assignment operators and define the copy and move constructors like: concurrent_unordered_map(const concurrent_unordered_map &old){ *this = old; } concurrent_unordered_map(concurrent_unordered_map &&old) BOOST_NOEXCEPT : { *this = std::move(old); } Best regards,Cosmin - Ioan Petrisor

2 1

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