- Boost - lists.boost.org

Re: [boost] Proposal for radically altered approach to releases
by Sohail Somani 11 May '06

11 May '06

> > Beman Dawes <bdawes <at> acm.org> writes: > > > > > > http://mysite.verizon.net/beman/release_overview.html. This is awesome. > SVN maintains a global revision number. Does anyone know a > good way of making > this number available via a header file (e.g. > boost/svn_revision_stable.hpp)? > I.e. each time any file in the stable branch changes the > header file should > automatically be updated. You can run trigger scripts server side on checkins. I don't know if sf.net allows this though (that is the boost repo right?)

1 0

[PATCH][Wave] Fix some wave/cpp.cpp compile problems
by Richard Guenther 11 May '06

11 May '06

This is the set of fixes that have accumulated for CVS version of wave/cpp.cpp. It still fails to build for me with gcc 4.1.0 with gcc-C++-action ../../../bin/boost/tools/wave/build/wave/gcc/release/cpp.o ../cpp.cpp: In function 'void<unnamed>::save_state(const boost::program_options::variables_map&, const Context&) [with Context = context_type]': ../cpp.cpp:882: instantiated from here ../cpp.cpp:483: error: no match for 'operator<<' in 'oa << std::basic_string<char, std::char_traits<char>, std::allocator<char> >(((const char*)"0x010204"), ((const std::allocator<char>&)((const std::allocator<char>*)(& std::allocator<char>()))))' /abuild/rguenther/boost/boost/boost/archive/detail/interface_oarchive.hpp:78: note: candidates are: Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = std::string, Archive = boost::archive::binary_oarchive] Thanks, Richard. Index: tools/wave/cpp.cpp =================================================================== RCS file: /cvsroot/boost/boost/tools/wave/cpp.cpp,v retrieving revision 1.25 diff -u -r1.25 cpp.cpp --- tools/wave/cpp.cpp 21 Mar 2006 15:31:42 -0000 1.25 +++ tools/wave/cpp.cpp 11 May 2006 14:54:08 -0000 @@ -146,7 +146,7 @@ /////////////////////////////////////////////////////////////////////////////// // forward declarations only -namespace cmd_line_utils +namespace cmd_line_util { class include_paths; } @@ -154,7 +154,7 @@ namespace boost { namespace program_options { void validate(boost::any &v, std::vector<std::string> const &s, - cmd_line_utils::include_paths *, int); + cmd_line_util::include_paths *, long); }} // boost::program_options @@ -273,7 +273,7 @@ namespace boost { namespace program_options { void validate(boost::any &v, std::vector<std::string> const &s, - cmd_line_util::include_paths *, int) + cmd_line_util::include_paths *, long) { cmd_line_util::include_paths::validate(v, s); } @@ -422,11 +422,11 @@ if (state_file == "-") state_file = fs::path("wave.state", fs::native); - using std::ios_base::openmode; - openmode mode = ios_base::in; + typedef std::ios_base::openmode openmode; + openmode mode = std::ios_base::in; #if BOOST_WAVE_BINARY_SERIALIZATION != 0 - mode = (openmode)(mode | ios_base::binary); + mode = (openmode)(mode | std::ios_base::binary); #endif ifstream ifs (state_file.string().c_str(), mode); if (ifs.is_open()) { @@ -466,13 +466,13 @@ if (state_file == "-") state_file = fs::path("wave.state", fs::native); - using std::ios_base::openmode; - openmode mode = ios_base::out; + typedef std::ios_base::openmode openmode; + openmode mode = std::ios_base::out; #if BOOST_WAVE_BINARY_SERIALIZATION != 0 - mode = (openmode)(mode | ios_base::binary); + mode = (openmode)(mode | std::ios_base::binary); #endif - ofstream ofs(state_file.string().c_str(), mode); + std::ofstream ofs(state_file.string().c_str(), mode); if (!ofs.is_open()) { cerr << "wave: could not open state file for writing: " << state_file.string() << endl; @@ -848,7 +848,7 @@ // print out the current token value if (allow_output) { - if (output.rdstate() & (ios::badbit | ios::failbit | ios::eofbit)) + if (output.rdstate() & (std::ios::badbit | std::ios::failbit | std::ios::eofbit)) { cerr << "wave: problem writing to the current " << "output file" << endl;

2 2

[PATCH] Fix tools/wave compilation
by Richard Guenther 11 May '06

11 May '06

I have problems building the wave preprocessor for the 1.33.1 release due to some typos in cpp.cpp (which are corrected by the patch below, CVS needs the same patch but that doesn't suffice and it fails in more interesting ways). This leads me to the question on the state of tools/wave - is it considered dead or obsolete? Preprocessing sources with the 1.33.1 release of wave causes spurious errors like /abuild/rguenther/boost/tramp3d-v4.cpp(4611): error: generic lexing error: '\000' in input stream if built with gcc 4.1.0 or the gcc trunk. Any ideas? Thanks, Richard. -- Richard Guenther <rguenther(a)suse.de> Novell / SUSE Labs --- tools/wave/cpp.cpp.orig 2005-05-16 11:36:01.000000000 +0200 +++ tools/wave/cpp.cpp 2006-05-11 16:14:31.000000000 +0200 @@ -108,7 +108,7 @@ /////////////////////////////////////////////////////////////////////////////// // forward declarations only -namespace cmd_line_utils +namespace cmd_line_util { class include_paths; } @@ -116,7 +116,7 @@ namespace boost { namespace program_options { void validate(boost::any &v, std::vector<std::string> const &s, - cmd_line_utils::include_paths *, int); + cmd_line_util::include_paths *, long); }} // boost::program_options /////////////////////////////////////////////////////////////////////////////// @@ -234,7 +234,7 @@ namespace boost { namespace program_options { void validate(boost::any &v, std::vector<std::string> const &s, - cmd_line_util::include_paths *, int) + cmd_line_util::include_paths *, long) { cmd_line_util::include_paths::validate(v, s); }

2 1

RNC7 More Digits friendly Competition
by Hervé Brönnimann 11 May '06

11 May '06

Dear boosters: This might be of interest to the persons doing the Google SoC project about bigints/bigfloats, although perhaps a bit too early. Some others may also be interested on their own. I apologize if this is a bit off-topic for others, this is a one-time email though. Best. -- Hervé Brönnimann CIS, Polytechnic University hbr(a)poly.edu More info available at http://rnc7.loria.fr/competition.html 7th Conference on Real Numbers and Computers (RNC 7) LORIA, Nancy, France July 10–12, 2006 More Digits friendly Competition Presentation A friendly competition of exact real arithmetic software will be held in Nancy during the RNC7 conference. The goal is to measure the performance of various numerical computing packages on a set of challenging problems, with a strong emphasis on accuracy. All packages with arbitrary precision capabilities are welcome to compete, with no restriction on the programming language of implementation, as long as you can run it on our competition machine (a 32-bit Pentium-4 3GHz processor running GNU/Linux). If you develop, maintain, or just use such a software, don't hesitate to take part in the friendly competition, telling us which software you intend to use. The competition will consist of 20 problems. The main emphasis will be on the correctness of the results, not the timings. Nevertheless, during the competition there will be just one hour of time for each participant to solve all the problems together.

1 0

[filesystem] introduce wide-only mode?
by Michael Fink 11 May '06

11 May '06

Hi, while porting Boost to evc4 I noticed that Boost.Filesystem makes heavy use of the Ansi Win32-API functions such as CreateFileA etc. There is a mode that can be enabled with the define BOOST_FILESYSTEM_NARROW_ONLY so that only Ansi APIs are used. Is it thinkable to introduce a BOOST_FILESYSTEM_WIDE_ONLY mode, e.g. when BOOST_NO_ANSI_APIS is defined? Should I try to implement such a mode, or is it too complicated? bye Michael

5 5

[Boost-bugs] [ boost-Bugs-1486232 ] memry leak with boost::gregorian::date_facet
by SourceForge.net 11 May '06

11 May '06

Bugs item #1486232, was opened at 2006-05-11 06:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1486232&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Serge (mandryka000) Assigned to: Jeff Garland (az_sw_dude) Summary: memry leak with boost::gregorian::date_facet Initial Comment: the following snippet causes a segmentation fault: using namespace boost::gregorian; date_facet * facet = new date_facet("%D"); //OK delete facet; //sergmentation error, here! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1486232&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Range] patched: boost/range/iterator.hpp
by David Abrahams 11 May '06

11 May '06

Hi Thorsten, I took the liberty of checking this patch into the HEAD: Please let me know if you have any objections. -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 14

Re: [boost] Building and testing filesystem library on AIX
by chris.grayson＠database-brothers.com 10 May '06

10 May '06

Beman, thanks for the reply. > Boost.Filesystem doesn't directly do any multi-threading, but it does use > shared_ptr. Are the shared_ptr tests working for you? If not, you need to > resolve those problems before trying Boost.Filesystem. I ran the tests in libs/smart_ptr/test, including the longer test of "shared_ptr_alloc_test", and they passed with flying colors (except the two intentional compile failures; those threw me for a minute :-). >> ../../../bin/boost/libs/filesystem/test/path_test.test/gcc/debug/path_test.run >> ====== BEGIN OUTPUT ====== >> Platform is POSIX >> /data2/cgrayson/boost_1_33_1/boost/test/minimal.hpp(122): exception >> "signal: SIGABRT (application abort requested)" caught in function: >> 'int main(int, >> char**)' >> >> **** Testing aborted. >> **** 1 error detected >> >> EXIT STATUS: 201 >> ====== END OUTPUT ====== > > Any chance of getting a call stack trace at time of abort? > The crash is happening when running the "path_test.cpp" test, in particular in the call to "path::default_name_check(fs::no_check);" in the try block below: 77 BOOST_CHECK( path::default_name_check_writable() ); 78 BOOST_CHECK( path::default_name_check() == fs::portable_name ); 79 BOOST_CHECK( !path::default_name_check_writable() ); 80 bool default_name_check_threw = false; 81 try { path::default_name_check( fs::no_check ); } 82 catch ( const fs::filesystem_error & ) { default_name_check_threw = true; } 83 BOOST_CHECK( default_name_check_threw ); Execution never reaches the catch, or the last BOOST_CHECK listed. Thanks, Chris

1 0

Building and testing filesystem library on AIX
by chris.grayson＠database-brothers.com 10 May '06

10 May '06

I'm trying to build and test Boost on AIX 5.3, with gcc 3.3.2, but not getting very far. I'm focusing on the filesystem library, using the following build command: $ bjam "-sTOOLS=gcc" "-sBUILD=release debug <threading>single/multi <runtime-link>static/dynamic <linkflags>-pthread" --without-python --with-filesystem stage Without "<linkflags>-pthread", it fails with errors like "Undefined symbol: .pthread_mutex_lock". So, this command seems to work okay, although I do get the following linker warnings for all four .so links: ld: 0711-224 WARNING: Duplicate symbol: _GLOBAL__F_thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: ._GLOBAL__I_thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: ._GLOBAL__D_thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: _GLOBAL__I_thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: _GLOBAL__D_thread_creds_t Then I want to verify the build, so I cd down into libs/filesystem/test, and try to run the test there by executing the following (the <linkflags>-pthread still seems to be required): $ bjam "-sBUILD=<linkflags>-pthread" The first problem I run into is this: ld: 0706-006 Cannot find or open library file: -l boost_filesystem-gcc-d-1_33_1 In the only "-L" directory listed in the g++ command line printed out after that ("../../../bin/boost/libs/filesystem/build/libboost_filesystem.so/gcc/debug/shared-linkable-true"), there is a libboost_filesystem-gcc-d-1_33_1.so, but no libboost_filesystem-gcc-d-1_33_1.a. So I manually copy the built libboost_filesystem-gcc-d-1_33_1.a from "../../../stage/lib", and try the same bjam command again. This time, the build part seems to work, though it gives the same linker warnings shown above for 2 of the 7 links ("../../../bin/boost/libs/filesystem/test/path_test_dll.test/gcc/debug/path_test_dll" and "../../../bin/boost/libs/filesystem/test/operations_test_dll.test/gcc/debug/operations_test_dll"). Then it tries to run the first test, but immediately crashes: execute-test ../../../bin/boost/libs/filesystem/test/path_test.test/gcc/debug/path_test.run ====== BEGIN OUTPUT ====== Platform is POSIX /data2/cgrayson/boost_1_33_1/boost/test/minimal.hpp(122): exception "signal: SIGABRT (application abort requested)" caught in function: 'int main(int, char**)' **** Testing aborted. **** 1 error detected EXIT STATUS: 201 ====== END OUTPUT ====== Any help would be greatly appreciated - thanks. Chris Grayson Database-Brothers, Inc. Austin, TX

2 1

Re: [boost] [filesystem][program_options][serialization][test] from comp.lang.c++.moderated
by Ames Andreas 10 May '06

10 May '06

Hello, > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams > Sent: Tuesday, May 09, 2006 1:18 PM > > I agree with that; no question about it. I think a few more degrees > of classification than you've outlined could be useful: > > core vs. optional > > I hate "optional" but can't think of a better term right now. > This is the distinction between, e.g., type traits and > serialization I think, the distinction between 'boost.core' and 'boost.optional' (or 'dependent' or sth.) could also be useful to release the strong requirements concerning dependencies between boost libs. While core could still be (almost) free of lib interdependencies, 'optional' libs could freely link to others (possibly even third party, i.e. XML parsers etc.). IIRC, property tree was critisised because of its dependencies, but when libs get more complex (and more directly related to applications), such dependencies may be inevitable and even useful, while it's still nice to have a core of independent libs. > fluidity > > "frozen" == Only bugfixes, in principle. A library can move out > of "frozen" to stable at the whim of its maintainer. > > "stable" == Only bugfixes and extensions. > > "active" == backwards-incompatible changes avoided with extreme > prejudice, and made only after one release of deprecation. A > strong bias is given towards preserving availability of old > interfaces under the same name, even if they've been superceded by > newer ones. > > "fluid" == whether we should have such a category is open to > debate. Sounds like a lot of work for the maintainers and the release managers. Maybe it would be sufficient to let every lib have ist own version (aside from the boost version) and use the usual versioning scheme, where changes of the minor version denote downward compatible APIs while new majors indicate API breakage (versionwise). Just my 0.02EUR as a lurker. cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya . com

3 2