- Boost - lists.boost.org

Trac open bug summary mailings missing new tickets
by David Abrahams 17 Dec '07

17 Dec '07

http://svn.boost.org/trac/boost/report/9 shows that although I have accepted 9 tickets, my libraries have many more open tickets than that against them. I think the total number is more interesting than the number I've actually accepted. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

[iterator] lvalue-ness resurrection in transform_iterator?
by shunsuke 17 Dec '07

17 Dec '07

Hi, Assume a base iterator is an InputIterator with RandomAccessTraversalTag. boost::make_zip_iterator often returns such iterators. boost::transform_iterator sometimes resurrects lvalue-ness of its base iterator. For example, char & to_lvalue(boost::tuple<char &, int &> const &t) { return boost::get<0>(t); } can return a lvalue from zip_iterator dereference. Therefore, if boost::transform_iterator extracts "pure" traversal tag from its base iterator, it can be not an InputIterator but a RandomAccessIterator. The patch will be something like this: template <class UnaryFunc, class Iterator, class Reference, class Value> struct transform_iterator_base { // ... typedef iterator_adaptor< transform_iterator<UnaryFunc, Iterator, Reference, Value> , Iterator , cv_value_type - , use_default // Leave the traversal category alone + , typename pure_traversal_tag<typename iterator_traversal<Iterator>::type>::type , reference > type; }; } Is there any pitfalls? Regards, -- Shunsuke Sogame

2 5

[Announce] Boost Testing Integrated with Trac
by David Abrahams 16 Dec '07

16 Dec '07

Pursuant to the conclusions of http://lists.boost.org/Archives/boost/2007/08/125724.php that our reporting system ought to be integrated with Trac, Daniel Wallin and I have installed a modified Bitten plugin (http://bitten.edgewall.org/) on the boost-consulting Trac server. We are using it with a few slave machines to test (a mirror of) the Boost subversion repository. You can see the results at: https://boost-consulting.com/trac/projects/boost/build https://boost-consulting.com/trac/projects/boost/build/trunk https://boost-consulting.com/trac/projects/boost/build?view=inprogress and by following the obvious links on those pages. Some features (I'm probably forgetting something; please poke around and see what you can discover): * runs tests for each atomic Boost checkin. * slaves can run incremental or from-scratch tests * failure markup is processed very quickly in Python on the machine doing the testing and used to alter the effect of failures, with no horrendous and time-consuming XSLT step * no tests are run for libraries that are marked unusable on a given os/compiler * no unreliable jam log processing is involved: Boost.Build is directly generating XML which is processed by python and shipped up to the Trac server * only failed tests that aren't marked up are shown in most views * a record of each build run is kept in the Trac server's database * reorganizing the system so that several machines can contribute to a single test run with a given OS/toolset is fairly straightforward. There are obviously a few rough edges and things we could do better in the UI, but I really believe this overall approach is a winner. Daniel and I are fairly competent Trac and Bitten hackers, so we should be able to make this system do whatever Boost needs, feed back the improvements to the Bitten community, and leave us with a maintainable codebase that isn't permanently tied to one or two people. It's time to open a discussion of exactly how the system should evolve, what features we want to see in the UI, etc. I hope those of you with an interest in the quality of Boost testing tools will join us on the boost-testing list to discuss this project's future. If anyone wants to run an additional testing slave, please let me know; once you have Python on your system, it's extremely easy to set up. Regards, Dave Postscript: Quick Overview of Bitten for Boost people ===================================================== Bitten is a continuous integration system that's integrated with Trac. Testing machines (called "slaves") run a Python script (part of the Bitten distribution) that checks periodically with the server to see if anything needs to be tested. The server manages a set of testing "recipes," each of which is associated with a directory in the subversion repository and a set of slave criteria (such as "are you running Linux?"). If a recipe has criteria matching the inquiring slave and there have been changes in the associated part of the repository, the slave executes the recipe. A recipe is divided into a series of "steps," each of which is composed of commands (http://bitten.edgewall.org/wiki/Documentation/commands.html) Slaves report back to the server as they execute each step, so the server can tell you about the progress of each slave. If any step fails, the build fails and the slave stops. Recipes are expressed in XML and stored in the server's Trac database. Trac users with the right privileges can create, edit, and delete recipes. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 4

[vault] Suspicious file: madshell.phtml
by Peter Dimov 16 Dec '07

16 Dec '07

There's a file called 'madshell.phtml' in the Vault that is probably an exploit. I see a few other .phtml's as well. -- Peter Dimov http://www.pdimov.com

2 1

Suggestion to lexical_cast library
by Márcio Gil 16 Dec '07

16 Dec '07

Hello, I suggest this add on lexical_cast library: a lexical_cast_def function, which work's like the AnsiString's ToIntDef method (from Borland VCL). Reason: the use of a lexical_cast without a try ... catch block, if the source is not guaranteed to be safe. Example: string source; int x = lexical_cast_def<int>( source, 0 ); In opposite of: string source; int x; try { x = lexical_cast<int>( source ); } catch(...) { x = 0; } Soon I can write this function in my project: template<typename Target, typename Source> Target lexical_cast_def(Source arg, Target def) { Target result; try { result = lexical_cast<Target>(Source); } catch (..) { result = def; } return result; } Otherwise we can post in the library this simplest and fastest function: template<typename Target, typename Source> Target lexical_cast_def(Source arg, Target def) { detail::lexical_stream<Target, Source> interpreter; Target result; if(!(interpreter << arg && interpreter >> result)) return def; return result; } And the call-by-const reference version. Thanks, Marcio Gil. P.S.: This is my first post in this list, soon excuse my bad English, I don't speak English, is that used only for reading.

2 1

[spirit] Causes a blizzard of warning from Boost.Format under MSVC?
by John Maddock 15 Dec '07

15 Dec '07

I'm at a loss to explain this, but this program: #include <boost/math/special_functions.hpp> int main() { boost::math::erf(2); } Compiles cleaning with MSVC-8, but as soon as I add a particular spirit #include: #include <boost/math/special_functions.hpp> #include <boost/spirit/utility/distinct.hpp> int main() { boost::math::erf(2); } Then Boost.Format (used internally be Boost.Math for error message formatting) issues a whole blizzard of warnings, that I actually thought I had fixed. I've checked Spirit for mismatched #pragma push/pop declarations, but they all look OK to me. Does anyone have any ideas what may be going on here, 'cos I'm stumped and the warnings are really very annoying! Many thanks, John.

4 9

[1.35.0][conversion] Failure to merge trunk changes to release branch
by Beman Dawes 15 Dec '07

15 Dec '07

A number of failures for release branch testing of the conversion library were the result of changes to trunk that were not also merged into the release branch. Developers need to remember to merge changes into branches/release if the changes are to go in the 1.35.0 release. To speed testing, I've now done that for the conversion library. But, really, this is something individual developers need to take responsibility for. --Beman

2 2

[units] - BOOST_UNITS_STATIC_CONSTANT
by Noah Roberts 15 Dec '07

15 Dec '07

It would appear that there's something wrong with this macro. I've looked at it and I'm not sure how it happens... In a precompiled header I'm including a system of units I'm creating. Some are simply composites of fundamental dimensions that are missing, such as volumetric flow, but others are different dimensions, such as currency. Some of the files that include this precompiled header use time(), the C function. However, if I use BOOST_UNITS_STATIC_CONSTANT to instantiate the unit for currency, which I'm pasting below, with VC++ 8, it pulls the time dimension into the global namespace. This of course causes the whole project to fail since that's where time() lives. If I just create a static variable this doesn't happen. What was the problem with static variables that necessitates a BOOST_UNITS_STATIC_CONSTANT? I'm using the mcs units from the vault, has this problem been fixed or even noticed before? Is there a report of changes to mcs that I can view? #pragma once #include <boost/units/systems/si.hpp> namespace esi { namespace units { using namespace boost::units; namespace systems { namespace SI { using namespace boost::units::SI; struct currency_tag : ordinal<11> {}; // dimension tag for currency typedef fundamental_dimension<currency_tag>::type currency_type; typedef unit<currency_tag, SI::system> currency; //BOOST_UNITS_STATIC_CONSTANT(coin, currency); static currency const coin; } } } }

2 1

Boost.Math: Ignored trac patches
by Jens Seidel 15 Dec '07

15 Dec '07

Hi John, you are the maintainer of Boost.Math and very active on the list to fix bugs in many libraries. May I ask why you ignore your own bugs such as http://svn.boost.org/trac/boost/ticket/1454? Did you not recieved the bug report because both messages were (maybe) considered as SPAM or what is the reason to not apply a patch which fixes build failures and a typo (you included sinh.hpp where sin.hpp was required)? Many other patches from me are also still not applied (and are nearly 2 months old) but math is properly maintained, right? Jens

5 9

[thread] thread_specific_ptr: iterator
by Michael Gopshtein 14 Dec '07

14 Dec '07

When working with "tread local storage" I find it sometimes very useful to get an access to instances of the class of all threads from single location. For example, when each thread stores some info in its own object, and you want to be able to collect overall data. So I think it would be helpful to add some form of iterator over the instances. Do you find such functionality valuable? Michael

1 0