- Boost - lists.boost.org

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

05 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

[test] problem in boost/test/detail/class_properties.hpp?
by Joaquín Mª López Muñoz 05 Oct '04

05 Oct '04

A recent update in boost/test/detail/class_properties.hpp replaces line 163: #ifndef __IBMCPP__ with #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) I guess this is an error, since the checks are just the opposite. BTW, this change seems to be producing many regressions in Visual Age, all of them reported for boost/test/test_tools.hpp. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[multi_index] volunteer needed for small test with VC 7.0
by Joaquín Mª López Muñoz 04 Oct '04

04 Oct '04

Hi, recent changes in the CVS result in failures in Boost.MultiIndex for MSVC 7.0, see for instance: http://tinyurl.com/5nqv7 The problem seems to be ETI-related, and maybe I can apply the same patch already in effect for MSVC 6.0. If anyone with local access to MSVC 7.0 could help me try this, I'd be eternally grateful: * Update the CVS (the whole tree, please) * Change line 35 of boost/multi_index/detail/node_type.hpp #if BOOST_WORKAROUND(BOOST_MSVC,<1300) to #if BOOST_WORKAROUND(BOOST_MSVC,<1310) (note the change in VC version) * Change line 36 of boost/multi_index/detail/base_type.hpp #if BOOST_WORKAROUND(BOOST_MSVC,<1300) to #if BOOST_WORKAROUND(BOOST_MSVC,<1310) * run the tests for multi_index and report the results. Thank you very much in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

re: [Thread] The last step
by Michael Stevens 04 Oct '04

04 Oct '04

On Friday 01 October 2004 15:32, "Aleksey Gurtovoy" <agurtovoy(a)meta-comm.com> wrote: > You can probably guess what I'm about to ask -- can we do something > about Intel 8.0/Linux failures? Looking at the output below (from > http://tinyurl.com/6mnzn) it seems to me that the test was attempted > to be linked against *both* GCC and Intel runtimes: I think the problem is that the compiler is running on a platform where the version of glibc is unsupported (too recent). I have come across the same problem myself. After much research I found the only workaround was to rename strol in the compilers libcprts.a This is a big hack but gets things compiling. I have a already manipulated libcprts.a but it is 1M. I can post it to whoever needs it however. Michael

3 3