October 2004 - Boost - lists.boost.org

Minimal test - unnecessarily hard to compile
by Alan Stokes 06 Oct '04

06 Oct '04

I've just tried to start using the minimal test facility. Unfortunately it fails to compile, and there's no way I can fix that without radically changing my build configuration. My code has #include "boost/test/minimal.hpp" in it; my include path includes a directory which has a boost directory within it containing all the boost headers, so this works fine. But minimal.hpp includes the line #include <libs/test/src/execution_monitor.cpp> which fails to compile - because my include path doesn't have a directory with the boost libs directory in it. And nor should it. This is unfortunate, and arguably a violation of the header policy (libs as a sub-directory name is highly likely to clash with other libraries, unlike boost). Header files should not be including implementation files. This is especially the case with the minimal test facility, whose whole point is to be usable without requiring linking with implementation files. Changing to textual inclusion of implementation files is not a great improvement. Could the necessary implementation detail not be moved into some header files, which can then be included as necessary by both the cpp files and minimal.hpp? (Note that this is not a new issue - see also http://lists.boost.org/MailArchives/boost/msg05435.php) - Alan

5 5

RFC: Extending boost::escaped_list_separator<> with an empty_token_policy.
by Eddy L O Jansson 06 Oct '04

06 Oct '04

Boost / Tokenizer / Escaped List Separator - empty_token_policy patch What? This url[0]/archive[1] contains a trivial patch to Boost 1.31.0 which extends the default escaped_list_separator<> tokenizer function with an optional empty_token_policy. In addition, a patch to update the documentation to reflect this change as well as a new example program demonstrating its use, is included also. The patch implements the safe default of boost::keep_empty_tokens such that a patched version of this library behaves exactly as the old one, unless specifically instructed not to. This is done by setting empty_tokens to boost::drop_empty_tokens in the constructor. Why? This gives you the usual benefits of "Escaped List Separator" -- the ability to specify and use escape and quote characters -- but without the downside of always having to deal with empty tokens by hand. This simplifies client code. The "empty tokens" policy is already available in the less sexy char_separator<> implementation, I simply brought it forward to escaped_list_separator<> too. Why not? It might be redundant. I might have fubared the implementation. Where? [0] http://klopper.net/~eddy/src/boost-tokenizer/ [1] http://gazonk.org/~eloj/files/temp/eloj-boost-tokenizer-policy-patch.rar -- "IBM clearly did contribute a lot of the Unix-related information into Linux. We just don't know what it is." -- Kevin McBride, legal mastermind. Eddy L O Jansson | http://gazonk.org/~eloj

1 0

[Boost-bugs] [ boost-Support Requests-1041059 ] Building Boost on mac os10
by SourceForge.net 06 Oct '04

06 Oct '04

Support Requests item #1041059, was opened at 2004-10-05 15:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1041059&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Building Boost on mac os10 Initial Comment: My name is Justin Heisler and i'm trying to build boost on my mac. I seem to have problems when I try the actual bjam -sTOOL=darwin command. It runs everything fine except fails on 6 targets. It says something about the -shared command not being recongized. Is there any way I can get help or work arounds? Thanks Justin heislerj(a)purdue.edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1041059&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Status of Boost.Python docs?
by Christoph Ludwig 06 Oct '04

06 Oct '04

Hi, I tried to become acquainted with Boost.Python. But even the examples in the documentation won't compile. The examples leave the impression as if they are untested because they contain quite obvious errors. For instance, from libs/python/doc/v2/operators.html (current CVS): [...] struct number : boost::integer_arithmetic<number> { number(long x_) : x(x_) {} operator long() const { return x; } number& operator+=(number const& rhs) { x += rhs } number& operator-=(number const& rhs); { x -= rhs } number& operator*=(number const& rhs) { x *= rhs } number& operator/=(number const& rhs); { x /= rhs } number& operator%=(number const& rhs); { x %= rhs } long x; }; [...] There are spurious semicolons after the argument list of operators -=, /=, and %=. On the other hand, there are semicolons missing in the bodies of the in-place operators... OK, it was no problem to fix this. But if run on the complete operators example, the compiler (gcc 3.4.2 on 686-pc-linux-gnu) chokes nevertheless. And this time I can't make much sense out of the error messages. (In case someone is interested, the compiler output is online at <URL:http://tinyurl.com/5u3rr>.) The regression test table at <URL:http://boost.sourceforge.net/regression-logs/cs-Linux.html> shows a runtime failure of the operators test for gcc 3.4.2. So the corresponding C++ module could be compiled, in contrast to the example from the docs. The user-level report at the meta-comm site <URL:http://tinyurl.com/4ebxv> (last updated on Aug 11) shows that the operators test passed with gcc 3.4.1. Since the regression tests show some problems with gcc 3.4.2, I can't be completey sure whether the errors I see are due to a compiler / platform problem or to a erroneous example. Since the example contained errors that had nothing to do with Boost.Python and the compiler and since examples from the tutorial also failed I suspect the latter. Can someone explain how this particular example needs to be changed so it can be compiled? Will the examples in the docs be checked before the upcoming release? Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

3 5

re: size_t*size_t is not size_t
by Michael Stevens 05 Oct '04

05 Oct '04

On Tuesday 05 October 2004 15:19, Kasper Peeters <kasper.peeters(a)aei.mpg.de wrote: > I need to handle extremely large sparse matrices, of approximately > half a million square elements (with, typically, on the order of 5 > million non-zero entries). > > The following, however, fails on a machine where std::size_t is 4 > bytes long: > > #include <boost/numeric/ublas/matrix_sparse.hpp> > > int main () { > using namespace boost::numeric::ublas; > sparse_matrix<double> m(400000, 400000); > } I assume this is uBLAS from Boost 1.31.0 If that is the case the short answer is that you need a more recent uBLAS. The current Boost CVS HEAD will do. These overflow problem have been fix for a few months. Longer answer. Don't forget that uBLAS has several sparse format to choose from. You may find coordinate_matrix or compress_matrix more suitable then sparse_matrix. Your problem is very large and to get efficient solutions you may need to exploit any structure it has! > It fails with > > Assertion failed in file > boost/numeric/ublas/functional.hpp at line 1345: The overflow test BOOST_UBLAS_CHECK ((size1 * size2) / size1 == size2, bad_size ()); is quite amusing. It actually checks if the calculation has not already overflowed, with a small chance of a false positive. Michael -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

RE: [boost] Re: Graph broken for vc7.1 after 1.31?
by Christian Wahlgren 05 Oct '04

05 Oct '04

Hi again, I still can't compile the graph library after the last change on the 29:th of Sept. Strangely I see regression tests been run on vc7.1 since then and I wonder how that could be possible? http://www.meta-comm.com/engineering/boost-regression/developer/graph.html Regards, Christian -----Original Message----- From: Christian Wahlgren on behalf of Christian Wahlgren Sent: Thu 2004-09-30 09:06 To: boost(a)lists.boost.org Cc: Subject: RE: [boost] Re: Graph broken for vc7.1 after 1.31? Hi, Perhaps my fault - It wasn't that easy to just define YY_NO_UNISTD_H to make graph compile with vc7.1. The problem is that two non-ANSI C functions is called: b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0; A little documentation search on Win32 gives: <io.h> int _isatty(int); <stdio.h> int _fileno(FILE*); As for how to solve these non-portable stuff with perhaps some BOOST defines, I think you all know better than I do. Kindest Regards, Christian -----Original Message----- From: Doug Gregor [mailto:dgregor@cs.indiana.edu] Sent: Wed 2004-09-29 17:45 To: boost(a)lists.boost.org Cc: Subject: Re: [boost] Re: Graph broken for vc7.1 after 1.31? On Sep 29, 2004, at 9:25 AM, Vladimir Prus wrote: >> Were you able to check it on VC 7.1? > > No. I'd appreciate if you could try there. I'll try to do so later. > >>>> We'll deprecate it in 1.32.0 (when, hopefully, we will >>>> have a new GraphViz parser that works well) and remove it >>>> afterwards. >>> >>> How the new parser will be implemented? >> >> Spirit. > > Is it written yet? Would be interesting to see. I think the parser is written but the semantic actions are not, so it isn't functional yet. We're trying to unify on some kind of system for dynamic properties, so that we can deal with reading in arbitrary vertex/node attributes. I have a GraphML parser that handles dynamic properties, which hopefully will also work well in the new GraphViz parser. If I get some time post-1.32.0 (hah!), we'll try to get all those bits in. >> Granted, they've dropped support for older, broken compilers, >> so someone will still be getting hurt by this. > > Right. OTOH, I start to wonder if BGL should drop support for old > compilers > as well. (borland and vc6 are marked unusable already). There seem to > be a > lot of workaround inside BGL which means even reading the code hard. We promised to keep the parts of the BGL needed for the Python lib in working order. But I've marked borland and vc6 unusable because they've never really been usable and are a huge maintenance burden. Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

[1.32 Release] Fixing long filenames (continued)
by Aleksey Gurtovoy 05 Oct '04

05 Oct '04

First of all, thanks to everybody who responded to my original request. Things are looking better now, but we still have some way to go -- http://www.meta-comm.com/engineering/boost/long_names.html. I'm reciting the issues below with some comments/requests. archive ------- boost/archive/polymorphic_binary_wiarchive.hpp: filename > 31 chars boost/archive/polymorphic_binary_woarchive.hpp: filename > 31 chars Robert, could you please fix these? build ----- tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam: filename > 31 chars tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam: filename > 31 chars I'll take care of these two myself, but somebody from the Boost.Build camp needs to look/comment on these: tools/build/v2/test/railsys/libx/include/libx/test_libx.h: file's directory depth exceeds 8 levels tools/build/v2/test/startup/boost-root/tools/build/boost-build.jam: file's directory depth exceeds 8 levels tools/build/v2/test/startup/boost-root/tools/build/bootstrap.jam: file's directory depth exceeds 8 levels mpl --- libs/mpl/doc/ref/Extensible_Associative_Sequence.html: filename > 31 chars libs/mpl/doc/ref/Reference/BOOST_MPL_AUX_LAMBDA_SUPPORT.html: filename > 31 chars Obviously my department. property_map ------------ libs/property_map/const_associative_property_map.html: filename > 31 chars I can take care of it, but wouldn't mind delegating it either. Anybody? serialization ------------- libs/serialization/example/demo_portable_binary_archive.cpp: filename > 31 chars libs/serialization/test/test_demo_fast_binary_archive.cpp: filename > 31 chars libs/serialization/test/test_demo_portable_binary_archive.cpp: filename > 31 chars libs/serialization/test/test_polymorphic_archive_data.cpp: filename > 31 chars libs/serialization/test/test_polymorphic_archive_data.hpp: filename > 31 chars libs/serialization/vc6ide/demo_portable_binary_archive.dsp: filename > 31 chars libs/serialization/vc7ide/demo_portable_binary_archive.vcproj: filename > 31 chars libs/serialization/vc7ide/test_level_class_info_load.vcproj: filename > 31 chars libs/serialization/vc7ide/test_level_class_info_save.vcproj: filename > 31 chars libs/serialization/vc7ide/test_level_not_serializable.vcproj: filename > 31 chars libs/serialization/vc7ide/test_simple_derived_class.vcproj: filename > 31 chars Robert, again, this is your domain. spirit ------ libs/spirit/phoenix/doc/lazy_construction_and_conversions.html: filename > 31 chars Joel, Hartmut? test ---- libs/test/build/msvc71_proj/ifstream_line_iterator_test.vcproj: filename > 31 chars libs/test/build/msvc71_proj/test_case_template_example.vcproj: filename > 31 chars libs/test/doc/components/test_tools/reference/BOOST_CHECK_EQUAL_COLLECTIONS.html: filename > 31 chars libs/test/doc/components/unit_test_framework/components/test_case/abstract_interface.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_case/auto_register_facility.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_case/boost_function_test_case.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_case/function_test_case.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_case/parameterized_boost_function_test_case.html: file path is > 100 chars, filename > 31 chars libs/test/doc/components/unit_test_framework/components/test_case/parameterized_class_test_case.html: file path is > 100 chars, filename > 31 chars libs/test/doc/components/unit_test_framework/components/test_case/parameterized_function_test_case.html: file path is > 100 chars, filename > 31 chars libs/test/doc/components/unit_test_framework/components/test_case/test_case_template.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_log/custom_log_formatter.html: file path is > 100 chars libs/test/test/test_files/errors_handling_test.pattern.gcc: filename > 31 chars Gennady, I realize this can be a bit of pain, but could you please take care of this? utility ------- libs/utility/enable_if_dummy_arg_disambiguation.cpp: filename > 31 chars libs/utility/enable_if_namespace_disambiguation.cpp: filename > 31 chars libs/utility/enable_if_partial_specializations.cpp: filename > 31 chars I'll deal with these myself. -- Aleksey Gurtovoy MetaCommunications Engineering

4 6

RE: [boost] RE: Re: Graph broken for vc7.1 after 1.31?
by Christian Wahlgren 05 Oct '04

05 Oct '04

Hi Vladimir, Thanks, it compiles now. Regression tests - yes, I see that now that the graphviz utility part isn't tested. Whish list: Since the graphviz utility code is part of the library it should preferably be tested also? Regards, Christian -----Original Message----- From: Vladimir Prus [mailto:ghost@cs.msu.su] Sent: Tue 2004-10-05 11:54 To: boost(a)lists.boost.org Cc: Subject: [boost] RE: Re: Graph broken for vc7.1 after 1.31? Hi Christian, > I still can't compile the graph library after the last change on the 29:th > of Sept. I've removed the calls to 'isatty', let me know if it works now. > Strangely I see regression tests been run on vc7.1 since then and > I wonder how that could be possible? > > http://www.meta-comm.com/engineering/boost-regression/developer/graph.html Because the regression tests do not build the graphviz parser? - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: JavaScript index?
by Jonathan Turkanis 05 Oct '04

05 Oct '04

"David Abrahams" <dave(a)boost-consulting.com> wrote in message news:uvfdwx3pm.fsf@boost-consulting.com... > > As long as we're tweaking the BoostBook look-and-feel, I'd like to > know the status of the "portable JavaScript index tree" project we > were discussing recently. I've even forgotten who was working on it > (shame on me). That would be me. :-) The docs are here: http://tinyurl.com/6tdvy. It's essentially finished, except for two points: 1. If it's integrated into Boost.Book, the documentation can be self-synchronizing, eliminating most need for the [link to this page] button. I think Reece Dunne did some work in this direction. 2. I'm planning to write a perl script which will make documentation writtenwith the tree control self-synchronizing even if it's not generated by Boost.Book. To understand what I mean by synchronization, see http://tinyurl.com/49hwe. Also note that the docs look better when the boost logo appears directly over the table of contents, as it does here: http://tinyurl.com/3p79x. Best Regards, Jonathan

9 22

size_t*size_t is not size_t
by Kasper Peeters 05 Oct '04

05 Oct '04

Hi, I need to handle extremely large sparse matrices, of approximately half a million square elements (with, typically, on the order of 5 million non-zero entries). The following, however, fails on a machine where std::size_t is 4 bytes long: #include <boost/numeric/ublas/matrix_sparse.hpp> int main () { using namespace boost::numeric::ublas; sparse_matrix<double> m(400000, 400000); } It fails with Assertion failed in file boost/numeric/ublas/functional.hpp at line 1345: (size1 * size2) / size1 == size2 Obviously, while both size1 and size2 fit in a 4-byte integer, the product does not, the calculation overflows, and this check fails. Can this problem be circumvented without modifying boost? Kasper

1 0