- Boost - lists.boost.org

Re: [boost] Understanding the test matrix
by Jim Bell 20 Oct '10

20 Oct '10

> The release test matrix seems to be telling me that there are many failures > on different platforms, and in fact > that there is no platform with no failures on all libraries, or libraries > with no failures on all platforms. We just > live with that, is that right? > > Do all the failures get fixed before an actual release is made, or noted in > the release notes? I think the original philosophy was that it should work on mainstream, modern compilers/platforms, but not necessarily on your old/outlier, and here's a matrix of what's been tested. I'm okay with that. Also, a single unexpected regression failure marks the whole library as fail/yellow on the main matrix. And something like serialization not linking cascades to several other libraries showing failed (e.g., date_time on mingw32). It should be that way, but it shakes the casual observer's confidence in all of boost. All this to say, maximizing the green on that regression matrix is worth the work, and worth holding up a release, IMHO. Also, many fixes are not as simple as just looking at the test results for a compiler/platform you have little experience with and can't test first-hand. (E.g., Ticket # 4736 -- it's clear the author was looking for the failure, but the only thing that made progress was my running it in gdb on that particular platform.)

1 0

Understanding the test matrix
by Robert Jones 20 Oct '10

20 Oct '10

Following on from some recent posts I had a look at the development area on the site, and would appreciate some clarification that I'm understanding it correctly. Firstly, I'm assuming that releases are made from area summarised under "Development -> Testing -> Release Summary" and development is carried out on trunk, so the release area is supposed to stable-ish and trunk not particularly? Is it correct that in some areas there are substantial divergence between trunk and release, sometimes reaching far back in time? The release test matrix seems to be telling me that there are many failures on different platforms, and in fact that there is no platform with no failures on all libraries, or libraries with no failures on all platforms. We just live with that, is that right? Do all the failures get fixed before an actual release is made, or noted in the release notes? Thx - Rob.

1 0

[system] Undocumented deprecated throws variable
by vicente.botet 20 Oct '10

20 Oct '10

Hi Beman, The documentation doesn't states explicitly that the throws variable is deprecated (see section "Deprecated names"). In addition the section "Semantics of throws object" explaining how this variable should be used must be rewritten to show the usage of the function throws(). Could this be changed for 1.45? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 2

Re: [boost] [1.45] Beta final schedule
by Jim Bell 19 Oct '10

19 Oct '10

Can we petition to hold up this release for some important bug fixes to catch up to it? I think gcc-mingw-4.x is an important platform (Qt SDK for Win32 ships with it), and it needs a few key ones.

2 1

Re: [boost] [exception] ostringstream like
by Fabien Castan 19 Oct '10

19 Oct '10

> No, I mean that if you do advanced string manipulation in the exception > itself, you may screw up, adn cause a bad_alloc beign thrown and masking > your own exception. Create an error sentence with some values inside is not really an advanced string manipulation. You can have 2 kinds of errors: bug inside a custom operator<< or a memory problem. There is no particular reason to not have sufficient memory to create an error sentence when throwing something like a logic_error. > Just make your own, informative exception type deriving from logic_error. The problem is not really the kind of exception, but an easy way to create message with boost exception tag system. The idea is to create a new base class for tags allowing to use an ostringstream with tags, which is not possible. typedef ::boost::error_info<struct tag_message,std::ostringstream> message; This little class only remap operator+ call to operator<< on an internal ostringstream. typedef ::boost::error_info<struct tag_message,::boost::error_info_sstream> message; I use it in my code, but I ask here if we can hope to see such things in boost exception. I would prefer to use a standard boost object rather than a custom class.

4 3

[regex] Regex does not build current release branch with GCC
by Jeremiah Willcock 19 Oct '10

19 Oct '10

I am using GCC 4.1.2 (toolset "gcc"), and the current release branch produces the error: Performing configuration checks - has_icu builds : yes /dev/shm/release/tools/build/v2/build/feature.jam:485: in validate-value-string from module feature error: "msvc:<linkflags>delayimp.lib" is not a known value of feature <toolset> error: legal values: "gcc" (then a long backtrace) Removing the delayimp.lib line from libs/regex/build/Jamfile.v2 works around the problem but probably would cause problems on VC++. -- Jeremiah Willcock

1 0

[1.45] Beta final schedule
by Beman Dawes 19 Oct '10

19 Oct '10

Major changes should already have been merged to trunk. Last minute bug fixes should be merged to trunk by the end of Monday, October 25th. The beta will go out as soon after that as most release branch tests have cycled, typically three or four days later. --Beman

2 1

Re: [boost] What's so cool about Boost.MPI?
by Thorsten Ottosen 19 Oct '10

19 Oct '10

Den 19-10-2010 14:59, Mathias Gaunard skrev: > On 18/10/10 23:41, David Abrahams wrote: >> >> Just wanted to call some attention to this article I wrote about >> Boost.MPI: >> >> http://daveabrahams.com/2010/09/03/whats-so-cool-about-boost-mpi/ >> >> I think it might be useful to link that from the Boost.MPI docs, too. > > While the library seems nice (it bridges serialization with MPI), I > don't really see anything in there that makes me think it's "so cool". > > So after reading it, I felt a bit like the question "What's so cool > about Boost.MPI?" remained unanswered. The semi-automatic, but very easy to maintain, way of creating/maintaining the MPI type maps (via Boost.Serialization), IIUC. -Thorsten

3 2

Re: [boost] [review result] mini-review of update to Boost.Assign
by Thorsten Ottosen 19 Oct '10

19 Oct '10

Den 18-10-2010 21:01, Mathias Gaunard skrev: > On 18/10/10 19:38, Thorsten Ottosen wrote: >> I would like to thank Erwann for his hard work so far, and hope he >> submits a Boost.Assign v2 in the near future. > > I have a possibly silly question: > > Does it use Boost.Proto? I don't suspect it, but only Erwan can answer that. -Thorsten

1 0

Re: [boost] [review result] mini-review of update to Boost.Assign
by Thorsten Ottosen 19 Oct '10

19 Oct '10

Den 18-10-2010 21:01, Mathias Gaunard skrev: > On 18/10/10 19:38, Thorsten Ottosen wrote: >> I would like to thank Erwann for his hard work so far, and hope he >> submits a Boost.Assign v2 in the near future. > > I have a possibly silly question: > > Does it use Boost.Proto? I don't suspect it, but only Erwan can answer that. -Thorsten

1 0