August 2007 - Boost - lists.preview.boost.org

Development and Release Practices
by Beman Dawes 14 Sep '07

14 Sep '07

A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_… Comments welcomed! The proposed process refinements are meant to complement the parallel ongoing efforts to improve our tools, but don't depend on any tool improvements. Thus we can get started as soon as we reach sufficient consensus. That said, I think tools are very important, and hope we can rapidly make improvements in both process and tools. --Beman

16 36

Release Tools Analysis Part I: Build systems
by David Abrahams 13 Sep '07

13 Sep '07

This is part 1 of my analysis of our prospects for improving the Boost release process by improving the tools. I'll post something based on this to the wiki after y'all give me an earful about what I got wrong or overlooked. Build System ============ I'm only considering BBv2 and cmake here, because we currently use the former and Doug and Troy have been putting lots of effort into the latter, and Kitware has volunteered to support it for us. Cmake has lots of advantages over BBv2 for developers (e.g. instant build startup time, use favorite development environment) and packagers (e.g. one-line installer target declaration), but these factors are more important for day-to-day development than they are for testing. Instant build startup time would improve test turnaround time, of course, but build startup does not dominate our testing time yet. BBv2 also has overall speed/memory-consumption problems. These might be addressable using the Boehm GC, but the last attempt resulted in crashes (more investigation needed). BBv2 has a few advantages over Cmake for testing. 1. BBv2 can build with multiple toolsets and/or variants in one invocation. That, however, is trivially overcome by using a wrapper script over cmake. 2. BBv2 serializes the output of simultaneous tests, which makes it possible to run tests in parallel with -jN. This is really important for test turnaround time. Even uniprocessors benefit from a low N (like 2) IME, due to disk/cpu tradeoffs. The IBM testers are currently using -j16 to great effect on their big iron. However, output serialization is only important because both Boost's process_jam_log and ctest/dart currently use a parse-the-build-log strategy to assemble the test results. This approach is hopelessly fragile in my opinion. Instead, each build step in a test should generate an additional target that contains the fragment of XML pertaining to that test, and the complete result should be an XML file that is the catenation of all the fragments. Rene is working on that feature for BBv2. I don't expect it would take more than a couple of days to add this feature to either build system, so the advantage of serialization may be easily neutralized. 3. Platform/compiler-independent build specification. This one seems pretty important on the face of it. If library authors' tests won't run on platforms to which they don't have direct access, we'll need to find people to port and maintain test specifications for the other platforms. On the other hand, very few tests are doing anything fancy when it comes to build configuration. To understand the real impact of this BBv2 feature, someone would have to objectively analyze the cmake build specifications Doug and Troy have been working on for complexity and portability. If either of those guys can be objective, it would be fastest if they'd do the analysis. 4. Cmake's built-in programming language is even more horrible, IMO, than bjam's. I bet you get used to it, like anything else, but it does present a barrier to entry. On the other hand, it's my impression that most programming jobs can be done more simply and directly under Cmake because it lacks BBv2's multiple-toolset/variant builds, and so has no need for virtual targets. Neither systems can trace #include dependencies through macros (e.g. #include SOME_MACRO(xyz)), which occasionally leads to inaccurate results from incremental testing. This is an important problem that should be fixed. Based on the above points, I'd say either build system has the potential to work for Boost's testing needs and neither one is substantially closer to being ideal for us (for testing). Since our systems use BBv2 now, it makes sense to concentrate effort there. However, if cmake were to suddenly acquire the XML fragment generation and the analysis of point 3 above showed that portable build specification is easily accomplished in cmake or not very important to our testing needs, I'd probably be vote the other way. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com

18 68

[date_time, asio, range] Unused argument warning fixes
by Caleb Epstein 12 Sep '07

12 Sep '07

Attached is a patch against the SVN trunk that fixes several unused argument warnings from gcc. With one exception the changes are just commenting out the argument name in the function definition. but there is a more ugly fix in <asio/detail/strand_service.hpp> that is only required when building with NDEBUG defined (e.g. when assert is a noop). Can the owners of the code take a look and either commit the appropriate fixes or give me the go-ahead to do it myself. I don't want to step on any toes. -- Caleb Epstein

1 1

asio forcing the use of handlers?
by Roland Schwarz 11 Sep '07

11 Sep '07

I am just about to find out how I could make use of the asio library, and am wondering if async io also can be done without using handler functions. I recognize that it is possible to use it in a blocked manner as follows: assuming we have an open socket: sock read(sock, buf); ... use the buffer contents ... Now I am wondering if I could also accomplish something like: cp = async_read(sock, buf); ... do something useful ... cp.wait(); .. use the buffer contents ... Thank you, Roland aka speedsnail

2 4

[proto] Calculator Arity Transform and function varargs
by Felipe Magno de Almeida 08 Sep '07

08 Sep '07

Hi, I can't make it out how to do the arity transformation for proto::functions varargs too. Could anybody shed some light? Thanks and best regards, -- Felipe Magno de Almeida

2 3

[test] BOOST_CHECK_NOT_EQUAL wanted
by Kevin Sopp 08 Sep '07

08 Sep '07

Hello, I found this old thread http://lists.boost.org/boost-users/2006/06/20028.php where it said bring up the issue again after 1.34 is released. I intuitively expected a BOOST_CHECK_NOT_EQUAL to exist and typed it in, but it wasn't there! So, here's one more person requesting macros for all comparison operators for the test tools. regards, Kevin Sopp

6 9

Updated Development and Release Practices for 1.35.0
by Beman Dawes 07 Sep '07

07 Sep '07

The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users. I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0. Comments appreciated. --Beman

18 83

1.34 boost::filesystem::size() issues on OSX PPC (works on OSX Intel though)
by John Zorko 07 Sep '07

07 Sep '07

Hello, all ... When I use v1.34s boost::filesystem::size() implementation on Mac OSX (10.4.10, Intel and PPC), I get different results. It appears to be a byte-ordering issue (since on little-endian machines (I tested on Windows and OSX Intel) it returns the correct result, while on big- endian machines (I tested on OSX PPC) it does not). While this is easy enough to code around, I don't recall reading anything about byte-ordering issues in the boost::filesystem portability guide, so i'm wondering if this is intentional? Regards, John Falling You - exploring the beauty of voice and sound http://www.fallingyou.com

5 6

Can SVN Check for too long and CamelCase file names?
by Paul A Bristow 06 Sep '07

06 Sep '07

I have recently had my wrist slapped by John Maddock, not once, but twice :-(( My offences were committing both Too long filenames, and CamelCaseFileNames. Are either of these crimes that could be prevented by SVN pre-commit rules? Paul PS I have submiited a Trac ticket for Quickbook documentaiton update http://svn.boost.org/trac/boost/ticket/1221 --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com

8 17

[thread] RFC standard proposed mutex, read-write mutex, condition
by Howard Hinnant 06 Sep '07

06 Sep '07

Here is a link to a reference implementation and a FAQ for mutexes, locks and condition variables I am currently anticipating proposing for C++ standardization (or subsequent TR). http://home.twcny.rr.com/hinnant/cpp_extensions/concurrency_rationale.html I am posting this link here because this work draws heavily on the boost experience, and I believe feedback from boost users would be valuable. The documentation is scant, chiefly consisting of a "FAQ" which largely centers around questions regarding design decisions that differ from the boost threads package. I'm looking for both agreement and disagreement (and why) on these design decisions from users of the boost threading package. One big difference between this threading package and the boost threading package is the ability to use C++0X language features such as rvalue reference and variadic templates. The rvalue reference is used to make lock types movable but non-copyable. This comes in especially handy with the "upgrade" mutex/locks (see faq). Variadic templates are used for generic locking algorithms which can take an arbitrary number of locks. This code is compiled using Doug Gregor's conceptgcc. So far, only mutexes (including read/write mutexes), locks and conditions are addressed. Yes, C++0X will have a std::thread. It isn't covered in the link above. Any further questions you may supply, I may add to the FAQ (unless there are objections). Anyone is welcome to "boostize" any and all of this code. The reference implementation is intended to be freely shared. However it is currently only addressing POSIX systems. No problems are anticipated in porting to Windows, largely due to the existing boost thread libraries (for which I am extremely grateful to all of those who have worked in this area). Thank you for your time and comments. -Howard

16 139