- Boost - lists.boost.org

Re: [boost] [asio].[solaris].[1_33_1] Update regarding test cases compilation
by Gaurav.Jain＠iflexsolutions.com 20 Feb '07

20 Feb '07

Hi Chris, Christopher Kohlhoff <chris <at> kohlhoff.com> writes: > Hi Gaurav, > > On Sat, 17 Feb 2007 13:10:47 +0530, Gaurav.Jain <at> iflexsolutions.com said: > > Sorry Chris, IPv6 network interfaces not available on my machine. > > It's weird that it lets you create an IPv6 socket when you don't have > any IPv6 interfaces. I've made a change to the test that will > hopefully "fail" correctly if there are no IPv6 interfaces. > > Anyway, tomorrow I plan to create a new 0.3.8 release candidate so > that you can confirm whether the fixes for Solaris and AIX work. When would it be possible to download the latest 0.3.8 RC ? > > Cheers, > Chris Regards, Gaurav Jain DISCLAIMER: This message contains privileged and confidential information and is intended only for an individual named. If you are not the intended recipient, you should not disseminate, distribute, store, print, copy or deliver this message. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version.

2 1

Regressions fix.
by John Maddock 20 Feb '07

20 Feb '07

I've been looking at some of the remaining regressions, and I have a fix for the issue here: http://tinyurl.com/yq6a5o I'm a little bit dubious about this patch, because I don't believe the fix should be necessary in the first place (can't understand why the compiler's complaining in the first place!), however it does fix the issue and appears harmless for the msvc/intel/gcc/borland compilers I've tested with. OK to go ahead and apply? John. ? out.txt Index: common_factor_test.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/math/test/common_factor_test.cpp,v retrieving revision 1.9 diff -u -r1.9 common_factor_test.cpp --- common_factor_test.cpp 4 Dec 2006 07:04:33 -0000 1.9 +++ common_factor_test.cpp 16 Feb 2007 16:39:48 -0000 @@ -163,7 +163,7 @@ BOOST_STATIC_CONSTANT(bool, has_infinity = limits_type::has_infinity); BOOST_STATIC_CONSTANT(bool, has_quiet_NaN = limits_type::has_quiet_NaN); BOOST_STATIC_CONSTANT(bool, has_signaling_NaN = limits_type::has_signaling_NaN); - BOOST_STATIC_CONSTANT(float_denorm_style, has_denorm = limits_type::has_denorm); + BOOST_STATIC_CONSTANT(float_denorm_style, has_denorm = (float_denorm_style)limits_type::has_denorm); BOOST_STATIC_CONSTANT(bool, has_denorm_loss = limits_type::has_denorm_loss); static MyInt1 infinity() throw() { return limits_type::infinity(); } @@ -177,7 +177,7 @@ BOOST_STATIC_CONSTANT(bool, traps = limits_type::traps); BOOST_STATIC_CONSTANT(bool, tinyness_before = limits_type::tinyness_before); - BOOST_STATIC_CONSTANT(float_round_style, round_style = limits_type::round_style); + BOOST_STATIC_CONSTANT(float_round_style, round_style = (float_round_style)limits_type::round_style); }; // std::numeric_limits<MyInt1> @@ -210,7 +210,7 @@ BOOST_STATIC_CONSTANT(bool, has_infinity = limits_type::has_infinity); BOOST_STATIC_CONSTANT(bool, has_quiet_NaN = limits_type::has_quiet_NaN); BOOST_STATIC_CONSTANT(bool, has_signaling_NaN = limits_type::has_signaling_NaN); - BOOST_STATIC_CONSTANT(float_denorm_style, has_denorm = limits_type::has_denorm); + BOOST_STATIC_CONSTANT(float_denorm_style, has_denorm = (float_denorm_style)limits_type::has_denorm); BOOST_STATIC_CONSTANT(bool, has_denorm_loss = limits_type::has_denorm_loss); static MyUnsigned1 infinity() throw() { return limits_type::infinity(); } @@ -225,7 +225,7 @@ BOOST_STATIC_CONSTANT(bool, traps = limits_type::traps); BOOST_STATIC_CONSTANT(bool, tinyness_before = limits_type::tinyness_before); - BOOST_STATIC_CONSTANT(float_round_style, round_style = limits_type::round_style); + BOOST_STATIC_CONSTANT(float_round_style, round_style = (float_round_style)limits_type::round_style); }; // std::numeric_limits<MyUnsigned1>

3 4

[iterator] marking is_lvalue_iterator expected failure on HP-UX/aCC6
by Boris Gubenko 20 Feb '07

20 Feb '07

iterator library test is_lvalue_iterator fails to compile on HP-UX/aCC6 (this is the only failing test in iterator library on this platform). I have not had a chance to investigate the failure and, consequently, don't have a small reproducer. What I do know though is that this test compiles cleanly in strict ansi mode. Would it be possible to mark this test as expected failure for HP-UX/aCC6 (toolset "acc") in both 1.34 and HEAD with the following remark (feel free to edit it): "For some currently unknown reason, with aCC6, this test can be compiled only in strict ansi mode. Since on HP-UX/aCC6 boost testing is done in the default compilation mode, this test fails to compile on this platform." Thanks, Boris

2 2

Bad entry page to RC_1_34_0 regressions
by "JOAQUIN LOPEZ MU?Z" 20 Feb '07

20 Feb '07

Hello, I think this problem has started to happen today, the entry page to the RC_1_34_0 regressions site hosted on meta-comm.com: http://engineering.meta-comm.com/boost-regression/CVS- RC_1_34_0/developer/ has ceased to work and emits an internal server error with some Python traces. Adding an "index.html" suffix to the URL, thouhg, lands you right onto the page: http://engineering.meta-comm.com/boost-regression/CVS- RC_1_34_0/developer/index.html The link from boost.org hasn't changed, so I understand the problem lies in meta-comm.com. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[1.34.0] hash_float_test / gcc-cygwin-3.4.4
by Vladimir Prus 20 Feb '07

20 Feb '07

Looking at: http://tinyurl.com/yotd5w I see no signs of any misconfiguration -- seems like hash library problem on cygwin. Would anybody be able to look into this? Thanks, Volodya

3 4

[1.34.0] The Road to RC1
by Thomas Witt 20 Feb '07

20 Feb '07

Hi, As outlined in this post http://tinyurl.com/2qs943 the build/regression issues that came up recently are now worked out. The downside of this is that the remaining regressions should be taken seriously. That being said at some point we need to ship. For this reason I think the deadline established in the aforementioned post is a good idea. So by Mar 1st the RC_1_34_0 branch will be frozen and all remaining failures will be marked expected. I will be trying to release RC1 the following weekend. Please could everybody have a long hard look at the remaining regressions and try to clear as many issues as possible before Mar 1st. Comments? Thomas -- Thomas Witt witt(a)acm.org

1 0

Mailing list archives
by Ulrich Eckhardt 20 Feb '07

20 Feb '07

Hi! Could somebody please look at the archives mentioned on the homepage? In particular, two of them end somewhere in 2003 (because their subscription was cancelled?). I have only checked the ones for the developers' mailinglist, the others should be checked, too, and possibly have their links removed and/or their operators notified. cheers Uli

2 2

[Review results] Accumulators accepted
by John Phillips 19 Feb '07

19 Feb '07

The accumulator library submitted by Eric Niebler has been accepted into boost. Thanks, once again to all of the people who contributed to the development of the library, to everyone who contributed to the review, and to Eric for a fine submission. During the review, Eric and some of the reviewers had a useful discussion about issues for the library, and possible improvements. A condensed version of the outcomes from that discussion is included below. Also, in perusing the archives for other comments about the library, I found a couple of other issues that were discussed. I have included them below, as well. In many cases, Eric acknowledged issues and committed to a fix during the review. Those issues are included below, along with the current state of some of the more open ended discussions to provide easy reference for all interested parties. For my own organizational convenience, I have numbered the entries below. This does not indicate relative importance. 1) Prior to the review it was asked why the function that returns a histogram is called the density. Little was done at the time, as Eric suggested it should be addressed during the review. As far as I can see, it was not brought back up during the review process. This should be examined to make sure that density is the best name for the function, and changed if needed. 2) There are a number of variant implementations of some statistical functions. The documentation should clearly indicate which variants focus on quick and dirty implementations, and which provide more numeric stability. Eric has stated that this will be addressed in the revisions of the documentation. 3) The question was asked whether or not it is feasible to provide outlier rejection for some or all of the accumulators. I can find no further discussion of this question in the review, however, since this is a very important statistical technique it would be a good feature to investigate for future addition. 4) Michael Stevens expressed interest in a form of the variance that accumulates the differences squared iteratively and divides the result by n. I saw no direct response, but this is basically what the immediate_variance does. 5) Interest was expressed in making the compensated sum the default version of the sum. It could be supplimented by the quick and dirty version as an alternative. However, since there are reports that many optimizing compilers turn the compensated sum algorithm into the same compiled code as the simple sum, tests should be done to see if there is any real gain before the modification. 6) There are a number of broken links in the quickbook docs. This has been acknowledged and is in line for a fix. 7) Steven Watanabe suggested changing the structure to move away from the fusion vector dependence. After discussion it appears that fusion cons,. may be a better choice. However there may be a use case for the original library that precipitated the choice of fusion vector. This should be checked, and if Steven's idea holds up under scrutiny, it should be implemented. 8) There is a request that the user guide specifies which header each component is in. This has been acknowledged and is in line for a fix. 9) The macro BOOST_PARAMETER_NESTED_KEYWORD has no description in the docs. This has been acknowledged and is in line for a fix. 10) There were a number of requests for improvements to the reference manual, ranging from wording changes to a reorganization that reflects class structure instead of header structure. In some cases, these improvements are direct, and they are in line for fixes. In other cases there is currently no known way to do it with the boost tool chain. Eric, and many of the other members of boost would greatly appreciate anyone who has ideas and time to fix the harder problems. 11) There was a suggestion that the documentation could mention the TR1 reference_wrapper as a future solution to the accumulator_set_wrapper issues, and the implementation could be changed once there is a boost accepted implementation of the reference_wrapper. My impression was that I was not the only person who didn't realize that it could solve that problem. 12) Functions that allow a range of values to be pushed into an accumulator set all at once should be added. This could include forms that take begin and end iterators and forms that take a sequence. Eric agreed that this is a good idea. 13) Paul Bristow mentioned that the kurtosis has a confusing naming history. What the docs refer to as the kurtosis would better be called the "kurtosis excess." His suggestion was that a name change be considered and that the docs be modified to acknowledge the confusion whether the name is changed or not. Eric agreed with this suggestion. 14) Accessors for the standard deviation, the unbiased variance and the unbiased (N-1) standard deviation were requested. The fact that John Maddock fell into the trap of miscalculating the standard deviation shows that even experts can make mistakes when converting from the variance. Thus, it is a good idea for inclusion. Eric said he is interested, and he would also welcome submissions that provide these functions. 15) The docs mention "Even the extractors can accept named parameters. In a bit, we'll see a situation where that is useful," but there is no later mention. Eric has an example he intended that to refer to, but forgot to include it in the last edition of the docs. He intends to fix that. 16) The ability to "reset" and accumulator was requested. Eric pointed out that it is quite possible to make accumulators with reset methods. He also pointed out that it might be desirable to reset accumulator_sets, but this could also pose a problem. It is not clear what should happen if one of the accumulators used by an accumulator set does not have a reset method. Further thought should be given to this for possible inclusion in a later revision. 17) Autocorrelation for accumulator_sets should be explored. Matthias already plans to do this in the coming year for possible inclusion in a later revision. 18) The documentation on what to expect when one accumulator is dropped while a second accumulator that depends on the first is not dropped should be clarified. Careful thought on this may lead to a change in current behavior. 19) There is a request that the docs state more clearly what happens when more than one accumulator maps to the same feature. Eric plans to include this in documentation revisions. 20) It is not currently possible to combine accumulators. In some very common use cases, this would be an important feature. However, not all accumulators can be combined in any sensible way. A solution to this will require some study and design work, but it is a valuable addition for a future revision. One possible solution is to have a compile time check to see if the accumulators are combinable. 21) While finding newer/faster/more robust algorithms is not a bad thing, the focus of this review has been the interfaces. If the interfaces are good, improved algorithms can be worked in later. There is some minimum standard for performance, but it is not the focal point or the submission. 22) Javier and Hans submitted lists of documentation corrections that Eric acknowledged and plans to fix. 23) It is agreed that there is a need for a more gentle and thorough getting started document. This should include some compelling examples that show why this is a good design decision. 24) More of the formulas should be available in the documentation. Eric requested volunteers to make some formulas into LaTeX, and I have already contacted him to do so. 25) The docs for how to incorporate new features should be improved. This can be helped tremendously if the people who had problems doing this would send Eric descriptions of where they had problems with the docs and the process. Thanks again to everyone for your time and work. Any problems or misrepresentations in the above list are purely my fault, and I apologize for them. John

2 1

Google SoC 2007
by Hartmut Kaiser 19 Feb '07

19 Feb '07

Yeah, it's high time to think about that again! http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html Regards Hartmut

1 0

Review Request: Switch
by Steven Watanabe 19 Feb '07

19 Feb '07

AMDG I am requesting a formal review of my switch_ function template. The implementation docs and tests are available in the vault. http://tinyurl.com/yvssgx In Christ, Steven Watanabe

3 3