October 2010 - Boost - lists.preview.boost.org

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

20 Oct '10

>> > >> > Can we petition to hold up this release for some important bug fixes to >> > catch up to it? > This idea has some traction with me. ... > Ticket numbers? So far... https://svn.boost.org/trac/boost/ticket/4736 https://svn.boost.org/trac/boost/ticket/4698 https://svn.boost.org/trac/boost/ticket/4747 Less important, but would remove more yellow from the regression table... https://svn.boost.org/trac/boost/ticket/4735

7 9

svn.boost.org down?
by John Maddock 20 Oct '10

20 Oct '10

SVN seems to be working Ok, but something has taken Trac down, any ideas anyone? Cheers, John.

3 3

Thoughts for a GUI (Primitives) Library
by Gwenio 20 Oct '10

20 Oct '10

As it stands, neither Boost nor C++ has any support for GUI applications. Therefore I am suggesting a library that provides the bare minimum required to create a GUI application. My thoughts on what this library would contain are as follows: - Types for controls (contexts bound to the extent of their parent) and windows (contexts that remain separate from their parents). - An event handler class that is passed when controls and windows are created that contains all information needed to handle events for the new context. - Functions for generating events (if applicable) and (a) function(s) to initiate message handling (unless the event loop is run in its own thread like in Java). - Functions to access and manipulate the data of the contexts (size, position, z-order, ect). - Miscellaneous other types used for support (such as for screen positions). - A way to retrieve the native concept of a window/control. As you can see, there are no controls/widgets/ect defined, either from the library or using the native versions. Such things can be added later, if people can ever agree on how they should be implemented. It needs a lot of refining, but I believe this covers the *minimum* support that is needed for a GUI.

22 78

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

20 Oct '10

> Message: 5 > Date: Tue, 19 Oct 2010 15:09:50 -0700 > From: Eric Niebler <eric(a)boostpro.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [1.45] Beta final schedule > Message-ID: <4CBE172E.90602(a)boostpro.com> > Content-Type: text/plain; charset=ISO-8859-1 > >> > >> > So far... >> > >> > https://svn.boost.org/trac/boost/ticket/4736 >> > https://svn.boost.org/trac/boost/ticket/4698 >> > https://svn.boost.org/trac/boost/ticket/4747 >> > >> > Less important, but would remove more yellow from the regression table... >> > https://svn.boost.org/trac/boost/ticket/4735 > Can you comment on whether these are regressions from previous releases? 1.44 had the first three, which is what (eventually) led me to this list (and pitching in to fix them).

2 1

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