February 2011 - Boost - lists.boost.org

[1.46.0] Release schedule?
by Beman Dawes 04 Feb '11

04 Feb '11

John Maddock recently complained that "beta's are too short". I agree, since we end up not having time to do more that a few high priority fixes. How long should we allow between the time the beta actually becomes available and closing branches/release prior to release? Should we adjust the 1.46.0 schedule accordingly? --Beman

4 7

Open-MPI with Boost.MPI
by Arpan Sen 04 Feb '11

04 Feb '11

Hi, I would like to know if there is any recommended version of Open-MPI to be used with Boost.MPI. I was looking for existing libraries for Boost.MPI for download but could not find any -- if anyone has any pointers to the same that would be really very appreciated. Currently, I have Open-MPI v1.5.1 in my XP box. Thanks and Regards, Arpan

1 0

Re: [boost] [Git] Moving beyond arm waving?
by Brian Wood 04 Feb '11

04 Feb '11

Belcourt, K. Noel: On Feb 3, 2011, at 1:48 PM, John Wiegley wrote: > >> Part of the reason we're putting this much effort into it is that we >> want a >> process which split Boost up into submodules during the migration >> process, >> while preserving as much history within each separate submodule as >> possible. >> There's just no tool out there that does that right now. So since >> we needed >> to write a tool anyway, why not solve the whole problem. > > > I haven't been following this closely so ignore if you've already > discussed / decided this. > > I'd much prefer to leave the repo structure unchanged and migrate > directly into git "as is". Restructure the repo into submodules after > we've made the transition to git. It will be much easier to > restructure the repo with everything already in git. There's two > upsides, we lose no commit history and it only perturbs one aspect at > a time (first give people chance to use same repo layout using new > tool, followed by a restructure of the repo into submodules using the > new tool). I worry about perturbing too many variables at once. I agree. Attempting what's being proposed is much harder than if it were broken up like this. I hope there will be a patient and experimental spirit regarding these proposals. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

Re: [boost] Patch to make code_converter flushable
by Eddie Carle 04 Feb '11

04 Feb '11

Argh, I just submitted this but realized that I left a debug line in the code before submitting the patch. Here is everything all over again proper. Terribly sorry for the confusion. I've attached a little patch that makes iostreams::code_converter flushable. It seems like it really should be. Is there any chance someone could look at this? I've included some test code as well that outputs the following. ********** OUTPUT BEFORE PATCH ********** main(): Sending 24 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Calling a sync on the output stream main(): Sending 21 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Asking for 24 characters of data from input stream SourceDev::read(): Sending 16 characters. SourceDev::read(): Sending 16 characters. main(): Calling a sync on the input stream main(): Asking for 9 characters of data from input stream SourceDev::read(): Sending 16 characters. main(): At end of test case SinkDev::write(): Recieved 13 characters. ********** OUTPUT AFTER PATCH ********** main(): Sending 24 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Calling a sync on the output stream SinkDev::write(): Recieved 8 characters. main(): Sending 21 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Asking for 24 characters of data from input stream SourceDev::read(): Sending 16 characters. SourceDev::read(): Sending 16 characters. main(): Calling a sync on the input stream main(): Asking for 9 characters of data from input stream SourceDev::read(): Sending 16 characters. main(): At end of test case SinkDev::write(): Recieved 5 characters. SinkDev::write(): Recieved 0 characters. SinkDev::write(): Recieved 0 characters. SinkDev::write(): Recieved 0 characters. ********** END ********** Notice that input functionality doesn't change but the output functionality does. The one cause for concern to me is that for some reason upon deconstruction the new flush() function is called a bunch of extras times. I'm not entirely sure why this is happening. -- Eddie Carle

1 0

Patch to make code_converter flushable
by Eddie Carle 04 Feb '11

04 Feb '11

I've attached a little patch that makes iostreams::code_converter flushable. It seems like it really should be. Is there any chance someone could look at this? I've included some test code as well that outputs the following. ********** OUTPUT BEFORE PATCH ********** main(): Sending 24 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Calling a sync on the output stream main(): Sending 21 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Asking for 24 characters of data from input stream SourceDev::read(): Sending 16 characters. SourceDev::read(): Sending 16 characters. main(): Calling a sync on the input stream main(): Asking for 9 characters of data from input stream SourceDev::read(): Sending 16 characters. main(): At end of test case SinkDev::write(): Recieved 13 characters. ********** OUTPUT AFTER PATCH ********** main(): Sending 24 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Calling a sync on the output stream SinkDev::write(): Recieved 8 characters. main(): Sending 21 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Asking for 24 characters of data from input stream SourceDev::read(): Sending 16 characters. SourceDev::read(): Sending 16 characters. main(): Calling a sync on the input stream main(): Asking for 9 characters of data from input stream SourceDev::read(): Sending 16 characters. main(): At end of test case SinkDev::write(): Recieved 5 characters. SinkDev::write(): Recieved 0 characters. SinkDev::write(): Recieved 0 characters. SinkDev::write(): Recieved 0 characters. ********** END ********** Notice that input functionality doesn't change but the output functionality does. The one cause for concern to me is that for some reason upon deconstruction the new flush() function is called a bunch of extras times. I'm not entirely sure why this is happening. -- Eddie Carle

1 0

[1.46.0][units] Tests failing on all non-Windows platforms
by Beman Dawes 03 Feb '11

03 Feb '11

http://beta.boost.org/development/tests/release/developer/summary.html Please fix or markup immediately. Thanks, --Beman

2 2

Is anyone besides me having trouble uploading to the vault?
by Marshall Clow 03 Feb '11

03 Feb '11

I have been unable to do so for almost a month. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

3 3

Nonstandard instantiation of std::initializer_list
by Matus Chochlik 03 Feb '11

03 Feb '11

Hi, I'm working on a factory generator tool and I would like to support types with initializer-list constructors, typically containers. There are several possibilities how to do this, but the otherwise most straightforward and generic way, requires non-standard construction of std::initializer_list<T> instances. I have the following working implementation for GCC (a complete, very simplified example showing the usage that can be compiled with g++ 4.5 with --std=c++0x is in the attachment): template <typename Element> class initializer_list_holder { private: typename std::initializer_list<Element>::iterator data; typename std::initializer_list<Element>::size_type size; std::vector<Element> elems; void init(void) { data = elems.data(); size = elems.size(); } public: initializer_list_holder(std::vector<Element>&& tmp) : elems(std::move(tmp)) { init(); } template <typename StdRange> initializer_list_holder(const StdRange& src) : elems(src.begin(), src.end()) { init(); } operator std::initializer_list<Element>() const { return reinterpret_cast< std::initializer_list<Element> const & >(*this); } }; The template above stores the elements to be traversed by the initializer-list's iterators in a vector and depends on the GCC's implementation of the initializer_list. The plan is to do something similar for other implementations of initializer_list by other compilers and switch between them via the preprocessor. (Yes, I know that vector<T>::data() is a non-standard extension, and on platforms where it is not available the array of elements would be managed directly by the initializer_list_holder) My questions are: Is this is good idea ? Do you foresee some reason for any compiler to use another implementation of std::initializer_list, besides the "obvious" listed in n2672 (pair of pointers / pointer + size), that wouldn't work with the reinterpret_cast in the conversion operator ? Should I look at the other possibilities to implement the factory? TIA for your insights. Best, Matus

2 2

[build] Regression tests failing across the board
by Beman Dawes 03 Feb '11

03 Feb '11

The build regression tests are still failing across the board. http://beta.boost.org/development/tests/trunk/developer/summary.html http://beta.boost.org/development/tests/release/developer/summary.html This is not acceptable. Having tests that always fail requires viewers to make an unwanted mental exception and sends the wrong message to other developers. The tests should either be fixed or marked up. If they aren't really tests at all, but are just informational like some in the config library, they should be changed to return 0 and "<test-info>always_show_run_output" should be added to the Jamfile. If the build test failures can't be cleared from the reporting, the tests themselves should be removed. --Beman

2 3

async messaging
by Scott Woods 03 Feb '11

03 Feb '11

Hi, This is a slightly different post. I am hoping for some contact details for a handful of Boosters that showed some interest in a previous thread I started with the same subject line. I have taken that same work and developed it a lot further. I am quite confident that Boost will not be interested and I did not wish to pollute the list with something already rejected. But this list is also the only way to those few that might be interested. If those folks are out there (and its ok with the Boost moderators) and still listening I can be contacted at "scott dot suzuki at gmail dot com". Keywords: zeroconf, auto-detection, advanced connection models, specification language, network APIs, network protocols, state machine dispatch. Regards, Scott

1 0