- Boost - lists.preview.boost.org

[iostreams] Review Results -- Iostreams Accepted
by Jeff Garland 06 Oct '04

06 Oct '04

Jonathan Turkanis's Iostreams library has been accepted into boost. Final vote tally from reviewers was: 14 accepts 1 reject 1 abstain There were many issues brought up and resolved during the review. I won't even attempt to repeat all those here. There were also many interesting suggestions about enhanced approaches. Most reviewers recommended acceptance regardless of the resolution of these, so I leave it to Jonathan's capable hands to deal with those. Some issues that need to be resolved: 1) Overlap with current io and more io library Recommendation: Move the library to a new directory (iostreams) and document any overlap with other io libraries. Rationale: While there is overlap, iostreams is taking a somewhat new approach that departs a bit the approach of the I/O library. Both approaches have merit and rather than trying to combine them prematurely it would be better to have both available and see which approach is better in practice. Since there was some discussion about the library name during the review, but no conclusive conclusion I'm going to leave the directory name as an issue for open discussion on the list. 2) Memory-Mapped Library At the moment the portable memory-mapped library is an implementation detail of Iostreams. It would be best if this library could be brought out of detail and made a standalone library that could be used independently of Iostreams. We need a volunteer to take this on (sounds like Jonathan will help with this). 3) zip/bzip2 library components The library source currently contains headers for zlib and bzip2. These headers should be removed from the source tree since they will complicate boost licensing. They should be replaced with instructions on how to obtain these libraries and how to configure bjam to find the headers and libraries. Since these libraries are already widely distributed they are often already installed on a platform. 4) 'piping' interface There was some support for adopting a 'pipe like' interface as originally implemented by JC van Winkel in another library, eg: filter_stream out(tee(std::cout) | encode | gzip | file("some file")); While this interface is not required for adoption, Jonathan has already implemented and will provide this interface. 5) Resource concept naming There was a long discussion of the naming of the concept Resource -- should it be Device, etc. Final resolution of this issue needs to be discussed and adopted. 6) Presidential filter example While many of us see the humor in this, there was at least one objection to introducing 'political comedy' into boost. Overall, the example should be renamed and reformulated since in a few years no one will get the joke anyway. Sorry to go politically correct here, but boost needs to be above the fray. I'd like to thank the reviewers for their time and many thoughtful reviews. And finally thanks to Jonathan for an excellent library! Jeff

10 31

threads documentation caught in infinite loop
by Eric Niebler 06 Oct '04

06 Oct '04

From the threads release_notes page (http://tinyurl.com/6rrck) clicking next takes you to the threads glossary (http://tinyurl.com/66kq2) and clicking next from that page takes you to the threads design page (http://tinyurl.com/4huct) way back at the beginning of the threads doc. An infinite loop! -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

Renaming "c++boost.gif"
by Aleksey Gurtovoy 06 Oct '04

06 Oct '04

I'm planning on doing a massive search & replace throught the docs concerned with renaming "c++boost.gif" to "boost_logo.gif" (the former is not a valid ISO 9660/Level 2 name). Please speak up soon if you have any objections/concerns! -- Aleksey Gurtovoy MetaCommunications Engineering

15 34

Typo in time duration documentation
by Robert Zeh 06 Oct '04

06 Oct '04

The example for the duration_from_string has a small typo. It reads: time_duration duration_from_string(const std::string&) From delimited string. std::string ts("23:59:59.000"); time_duraton td(duration_from_string(ts)) The type time_duraton should be time_duration. In the current CVS, it looks like the typo is in boost/libs/date_time/xmldoc/time_duration.xml around line 160. Robert Zeh http://home.earthlink.net/~rzeh

2 1

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 05 Oct '04

05 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 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