December 2008 - Boost - lists.preview.boost.org

Improving Boostbook's Output
by John Maddock 04 Dec '08

04 Dec '08

Currently the Boostbook XSL stylesheets generate a lot of verbose output when run: to put this in perspective a complete build of the docs under boost-root/doc/ generates 3.1 Mb of messages, quite a large proportion of which are from Boostbook. Consequently at present it's impossible to figure out what represents a real issue, and what's just "chaff". So I'm proposing changing the Boostbook stylesheets as follows: * Add a new xsl:param "boostbook.verbose" which defaults to 0. * For each occurrence of xsl:message in the style sheets, we will either: * Terminate with an error if the message looks like it's a possible genuine error. * Otherwise emit a warning *only* if boostbook.verbose=1 I'm prepared to invest some time to make this work, but any comments or possible issues anyone foresees from this change? Cheers, John.

1 0

Mailing list configuration
by Vladimir Prus 04 Dec '08

04 Dec '08

Hi, it seems that the way most Boost mailing list are configure is fairly inconvenient, especially for newcomers. Here's a typical chain of events: 1. Somebody reads Boost mailing list via Gmane and wants to post. 2. He posts. 3. Gmane responds, asking the user to prove that he exists. Somewhere in the body of the message, Gmane suggest that user subscribes to the mailing list, but it's very easy to miss, and furthermore, those instructions do no work for Boost mailing lists. 4. User replies, and Gmane forwards the message to the list. 5. The list is configured to reject email messages from non-subscribers. When using Gmane, this results in *no notification at all*. 6. User posts directly, and gets bound message saying, literally: allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at boost-docs-owner(a)lists.boost.org and [email address] This message does not even hint that the user has to subscribe. 7. User subscribes. His post in the held for moderation. I have personally was fairly confused by (6) -- where my messages disappear silently, and by (7) -- where the message seem to say my messages are specifically rejected. I suspect many users might not make it to the point (7) at all. Can we configure all mailing list to not reject posts from non-subscribes, instead holding them for moderation. This will also require talking to mailing list admins to enable at least some spam filtering -- presently, messages written in the languages I don't understand seem to freely hit boost-build mailing list moderation queue, and for boost-devel this will be impossible to handle. Comments? - Volodya

2 1

Re: [boost] [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today
by raindog＠macrohmasheen.com 04 Dec '08

04 Dec '08

Another example: 6 represents june. 6 + 3 is then 3 months after june, otherwise september. 6 + 12 is the next june. ------Original Message------ From: Edward Diener Sender: boost-users-bounces(a)lists.boost.org To: boost-users(a)lists.boost.org Cc: boost(a)lists.boost.org ReplyTo: boost-users(a)lists.boost.org Sent: Dec 3, 2008 8:03 PM Subject: Re: [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today Deane Yang wrote: > Edward Diener wrote: >> Deane Yang wrote: >>> >>> I have an even more extreme view on this. I don't believe any >>> arithmetic operations should be permitted for constrained numbers. >>> They just don't make sense (would you ever want to add two different >>> days of a month?). >> >> You have chosen a particular type for which arithmetic operations >> sometimes make little sense. In many other situations this is not the >> case. > > > Could you give an example? An example of what ? Of a constraint where arithmetic operations make sense ? If we take a constraint representing a percentage between 0 and 100, I think it is perfectly valid to add a percent to what is already there. That is just one of innumerable cases where arithmetic operations of contraints seem perfectly valid to me. Why would you even want to consider limiting constraints by removing arithmetic operations if the underlying type supports such operations ? _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Sent from my Verizon Wireless BlackBerry

2 1

regression in math
by frederic.bron＠alcan.com 04 Dec '08

04 Dec '08

Very strange: nearly all regression tests failed on my linux platform with g++: http://www.boost.org/development/tests/trunk/developer/math.html (look at linux_x86_64, bronf) The reason is the always the same but is strange to me: "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -mfpmath=sse -mieee-fp -march=nocona -fPIC -Wno-missing-braces -DBOOST_ALL_NO_LIB=1 -DBOOST_REGEX_DYN_LINK=1 -DBOOST_UBLAS_UNSUPPORTED_COMPILER=0 -I".." -c -o "/soft/bal/usr/builds/boost_test/results/boost/bin.v2/libs/math/test/dist_bernoulli_incl_test.test/gcc-3.4.6/debug/dist_bernoulli_incl_test.o" "../libs/math/test/compile_test/dist_bernoulli_incl_test.cpp" In file included from ../boost/math/distributions/detail/common_error_handling.hpp:13, from ../boost/math/distributions/bernoulli.hpp:33, from ../libs/math/test/compile_test/dist_bernoulli_incl_test.cpp:9: ../boost/math/special_functions/fpclassify.hpp:170: error: expected unqualified-id before '&&' token This line has been modified recently and seems not to work now with g++: Index: boost/math/special_functions/fpclassify.hpp =================================================================== --- boost/math/special_functions/fpclassify.hpp (revision 50010) +++ boost/math/special_functions/fpclassify.hpp (working copy) @@ -165,7 +165,9 @@ { return BOOST_FPCLASSIFY_PREFIX fpclassify(t); } -#if !defined(__CYGWIN__) && !defined(__HP_aCC) && !defined(BOOST_INTEL) && !defined(BOOST_NO_NATIVE_LONG_DOUBLE_FP_CLASSIFY) +#if !defined(__CYGWIN__) && !defined(__HP_aCC) && !defined(BOOST_INTEL) \ + && !defined(BOOST_NO_NATIVE_LONG_DOUBLE_FP_CLASSIFY) \ + && !(defined(__GNUC__) && !defined(BOOST_MATH_USE_C99)) // The native fpclassify broken for long doubles with aCC // use portable one instead.... F. Bron ___________________________________ Frédéric Bron (frederic.bron(a)alcan.com) Unité ALT, Alcan CRV, BP 27, 38341 Voreppe +33 4 76 57 81 72, +33 6 07 48 56 67 Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

2 1

[config] BOOST_NO_INITIALIZER_LISTS patch
by Daniel James 04 Dec '08

04 Dec '08

Hi John, I've attached a patch for adding BOOST_NO_INITIALIZER_LISTS to config. Is it okay to commit? thanks, Daniel

2 1

[shared_ptr] make_shared and enable_shared_from_this with boost 1.36
by Michael Marcin 04 Dec '08

04 Dec '08

The following code throws boost::bad_weak_ptr using boost 1.36. #include <boost/shared_ptr.hpp> #include <boost/enable_shared_from_this.hpp> #include <boost/make_shared.hpp> class Test : public boost::enable_shared_from_this<Test> {}; int main() { boost::shared_ptr<Test> test = boost::make_shared<Test>(); test->shared_from_this(); } -- Michael Marcin

2 1

Re: [boost] [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today
by raindog＠macrohmasheen.com 04 Dec '08

04 Dec '08

I totally agree. Pre contstraining a value for assignment to constrained_value seems to defeat the purpose of the library all together. ------Original Message------ From: Edward Diener Sender: boost-users-bounces(a)lists.boost.org To: boost-users(a)lists.boost.org Cc: boost(a)lists.boost.org ReplyTo: boost-users(a)lists.boost.org Sent: Dec 3, 2008 7:58 PM Subject: Re: [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today Mathias Gaunard wrote: > Edward Diener wrote: > >> I disagree with your analysis. The '26' value could be a run-time >> calculation and not just a compile-time constant. In which case you >> are saying that the assignment of a run-time calculation should assert >> only when run in debug mode and otherwise should be ignored. I can not >> agree with that idea. > > I say it is up to the programmer to ensure valid values are provided. > If the value is only known at runtime, there should be explicit checking > in the code prior to assignment. Suppose the value is provided by the end user of the program. Do you still feel such a value, when used in a constraint, should assert only in debug mode rather than throw an exception ? A large part of the constrained value concept is that the constraint provides the necessary checking, in the form of a policy, which alleviates specific pre-checking by the programmer. I like that, else the constraint library serves less purpose than it could. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Sent from my Verizon Wireless BlackBerry

1 0

[review][constrained_value] Bounded value
by Edward Diener 04 Dec '08

04 Dec '08

This is not a full review of the constrained_value library but rather a comment on one of the concepts of the library. I hope to give a full review by December 10 if I have the time. I believe the bounded objects are actually a subset of a larger concept, which is the set of valid values for an object. Ideally what one could have is a set of bounded values which define the valid values. Each member of the set could be a pair ( or two-element tuple ) defining a lower and upper value inclusive, and of course a single value in the set would have its lower and upper value be the same. In this way one could define, as an example, a constrained object whose integer value could be between 0 and 20 and between 50 and 70. Currently the bounded object concept only allows one "bounds". With the larger concept I mention, a bounded object can have any number of bounds. While the single bounds bounded object can still be supported, I would like to see the constrained value library implement a multi-bound concept, in which case the current bounded object concept is just a subset of the multi-bound with a single bound.

2 4

[vault] trojan in vault?
by Eric Niebler 03 Dec '08

03 Dec '08

Looks like someone uploaded a trojan or something to the boost file vault. Can someone with permissions please delete shell.php4 here: http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=eric_… Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] [unicode] Interest Check / Proof of
by Graham 03 Dec '08

03 Dec '08

Hi, I have taken a different approach and distilled the Unicode character rules down into a library as the rules are too complex to be defined algorithmically. This library gives full Unicode support for iterators for the full Unicode set of characters. It just needs the string wrapper round it. Please see the Unicode character library at: http://www.boostpro.com/vault/ Unicode_lib.zip. Good Luck. Yours, Graham

1 0