Re: [boost] Where is the implementation of boost::filesystem::filesystem_exeception::who,path1

2003-06-10 Thread Beman Dawes
Yes, you're right as far as 1.30.0 goes. The problem has been fixed in the Boost CVS, however, so you can get an update there. --Beman At 06:27 PM 6/10/2003, Benjamin Dauvergne wrote: Try to compile with(this is on a debian): g++ test-fs-boost.cc -o test-fs-boost /usr/lib/libboost_filesystem.a

Re: [boost] filesystem::path and ./

2003-06-09 Thread Beman Dawes
At 07:49 AM 6/9/2003, John Maddock wrote: While putting together bcp (see managing boost dependencies thread), I found that some of the boost html files contain relative URL's of that begin with ./. In order to get filesystem::path to accept these, I had to manually strip the ./ off first, so

Re: [boost] Command Line Config review results

2003-06-08 Thread Beman Dawes
At 09:12 AM 6/5/2003, Aleksey Gurtovoy wrote: Vladimir Prus wrote: There've been a fair amount of suggested changes, many of which are documented on Wiki [1], and since the author himself keeps track of the issues, I won't reiterate them here - except for stressing the need for a)

Re: [boost] Command Line Config review results

2003-06-08 Thread Beman Dawes
At 10:48 AM 6/4/2003, Vladimir Prus wrote: Aleksey Gurtovoy wrote: b) resolving the 'wchar_t' support issue before the library makes into official Boost distribution. I'm actually not that happy about solving general issue alone... but let it be. I assume I've not asked to implement any

Re: [boost] Re: Math Constants Formal Review

2003-06-08 Thread Beman Dawes
At 01:57 PM 6/8/2003, Gennaro Prota wrote: On Sun, 8 Jun 2003 15:56:53 +0100, Paul A Bristow [EMAIL PROTECTED] wrote: If someone would like to do this, I'd be grateful. (Memories of how to use commandlines and CVS have decayed). IIUC, the boost sandbox is, so to speak, a more precious resource

Re: [boost] Re: Better Intel-Win32 support

2003-06-06 Thread Beman Dawes
At 02:10 AM 6/5/2003, Daryle Walker wrote: On Wednesday, June 4, 2003, at 3:54 PM, Beman Dawes wrote: Hum... I just had a thought. Is it possible to detect if wchar_t is a typedef at compile time? Yes, I think so. Won't boost::is_same unsigned short, wchar_t ::value be true if wchar_t

Re: [boost] Re: Better Intel-Win32 support

2003-06-05 Thread Beman Dawes
At 07:58 AM 6/4/2003, John Maddock wrote: That will certainly work, but you shouldn't have to do that since the compiler itself defines _WCHAR_T_DEFINED. Since I made the fix earlier this afternoon I am able to compile some non-boost code correctly which had previously be failing. Just let

Re: [boost] Re: Re: Better Intel-Win32 support

2003-06-05 Thread Beman Dawes
At 11:24 AM 6/4/2003, Edward Diener wrote: I don't know about Intel-Win32 but I brought much of this up regarding MSVC 7.0+ and most everybody yawned. I am glad that some people have woken up to the fact that there is a problem using wide characters with compilers which support both the native

[boost] Formal review: program_options

2003-06-03 Thread Beman Dawes
This review is based purely on reading the documentation. The code was not inspected and no tests were run. I also skim read some of the other review comments. In general, I like the library and think that it should be accepted by Boost. But there are a number of issues, and I have the feeling

Re: [boost] Re: Better Intel-Win32 support

2003-06-03 Thread Beman Dawes
At 07:02 AM 6/2/2003, David Abrahams wrote: Since I made the fix earlier this afternoon I am able to compile some non-boost code correctly which had previously be failing. What fix is that... Fixes to boost/config/compiler/intel.hpp. I just did a commit of that file that brings it into sync

Re: [boost] Imminent Code Breakage

2003-06-03 Thread Beman Dawes
At 07:57 PM 6/2/2003, David Abrahams wrote: I'm going to want to replace the old Boost iterator adaptors implementation with the new one in the Boost sandbox pretty soon, and while they are similar in intent and spirit, they have totally incompatible interfaces. In fact, the new one lives in a

Re: [boost] Argument-dependent lookup for Intel/Win32

2003-06-03 Thread Beman Dawes
At 10:01 AM 6/2/2003, David Abrahams wrote: I just checked in changes to the intel-win32-tools.jam file which enable argument-dependent lookup for all versions, since we were were incorrectly operating as though it was enabled for v7.1 anyway. I think we are still out-of-synch with the config,

Re: [boost] Better Intel-Win32 support

2003-06-02 Thread Beman Dawes
At 11:12 AM 6/1/2003, David Abrahams wrote: I just checked in some improvements to intel-win32 support for Boost.Build version 1. This includes a hack which works around our inability to detect wchar_t support for intel6. It also includes automatic version detection and resulting customization

Re: [boost] Better Intel-Win32 support

2003-06-02 Thread Beman Dawes
At 12:09 PM 6/1/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: Looks much improved, thanks! Two of the config_info macros look a bit questionable: I don't know what you mean; I didn't touch the Boost config. All I did was to edit intel-win32-tools.jam. Understood. But now

Re: [boost] Re: Better Intel-Win32 support

2003-06-02 Thread Beman Dawes
At 02:50 PM 6/1/2003, Pavel Vozenilek wrote: Beman Dawes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'll try to trace where BOOST_NO_INTRINSIC_WCHAR_T is being set. I'm not so worried about ADL, at least with VC++ 7.1. You may look on test table http://aspn.activestate.com

Re: [boost] Re: Better Intel-Win32 support

2003-06-02 Thread Beman Dawes
At 03:09 PM 6/1/2003, David Abrahams wrote: Pavel Vozenilek [EMAIL PROTECTED] writes: Beman Dawes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'll try to trace where BOOST_NO_INTRINSIC_WCHAR_T is being set. I'm not so worried about ADL, at least with VC++ 7.1. You may look

Re: [boost] Re: Better Intel-Win32 support

2003-06-02 Thread Beman Dawes
At 03:08 PM 6/1/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: The fresh regression tests are now posted. Here is what changed in the Intel results, presumably as a result of the intel-win32 changes: New fails: config/limits_test integer

[boost] boost/fenv.hpp needed?

2003-05-31 Thread Beman Dawes
C99 has a header fenv.h which provides types, macros, and functions to provide access to the floating-point environment. Some Boost code in the Interval Library uses this header, or has to do workarounds if not present. Metrowerks, GCC, and Dinkumware currently ship the header, but many others

RE: [boost] MPL regression tests?

2003-05-31 Thread Beman Dawes
At 07:15 AM 5/30/2003, Aleksey Gurtovoy wrote: IMO it's worth to step back and try to answer a couple of big picture questions: Yes, that's a good idea. 1) What are the target audiences for the regression test results? 2) What kind of information these audiences are looking to find in there?

Re: [boost] boost::filesystem::path and '.'

2003-05-29 Thread Beman Dawes
At 12:37 PM 5/28/2003, Stefan Seefeld wrote: hi there, I'm trying to load a plugin from the same directory the application was run from, so I'm doing the following: int main(int argc, char **argv) { //... fs::path path(argv[0]); fs::path dir(path.branch_path()); //... but as soon

Re: [boost] MPL regression tests?

2003-05-29 Thread Beman Dawes
At 03:29 PM 5/28/2003, Eric Friedman wrote: I apologize if this has already been asked, but why aren't the libs/mpl/test sources included in regresssion testing? I know some tests are missing and some are perhaps as robust as they might be, but it seems some testing is better than no testing.

RE: [boost] MPL regression tests?

2003-05-29 Thread Beman Dawes
At 08:19 PM 5/28/2003, Aleksey Gurtovoy wrote: Eric Friedman wrote: I apologize if this has already been asked, but why aren't the libs/mpl/test sources included in regresssion testing? I know some tests are missing and some are perhaps as robust as they might be, but it seems some testing is

Re: [boost] persistence

2003-05-27 Thread Beman Dawes
At 07:04 PM 5/25/2003, Scott Woods wrote: Is anyone interested in a persistence mechanism? It isn't clear from you post if you are aware of all the work (including a formal review) that has already gone into persistence and/or serialization at Boost. See the archives at

Re: [boost] smart_ptr suggestion: smart_ptr.hpp should include weak_ptr.hpp, etc.

2003-05-27 Thread Beman Dawes
At 11:44 AM 5/27/2003, Peter Dimov wrote: Chuck Messenger wrote: For convenience, logical continuity, and consistency with other Boost libraries, you should be able to include all the smart_ptr pieces with #include boost/smart_ptr.hpp Currently, only 4 are included: #include

Re: [boost] Should regression summary consider both pass and warn as passing?

2003-05-27 Thread Beman Dawes
Take a look at the new version of http://boost.sourceforge.net/regression-logs/. I think the meaning of the percentages is much clearer now. Thanks to those who provided suggestions, and to Rene Rivera for the implementation. --Beman ___

Re: [boost] Should regression summary consider both pass and warn as passing?

2003-05-26 Thread Beman Dawes
At 05:04 AM 5/26/2003, Toon Knapen wrote: The number of warnings also provides valuable information but indeed it's not as important as the Pass/Fail categories so this needs to be communicated to the viewers as well. But how ? I support the suggestion of Greg indicating something like: Pass:

Re: [boost] Comeau/como-win32 regression test results

2003-05-22 Thread Beman Dawes
At 07:31 AM 5/22/2003, John Maddock wrote: - Detects some regex problems that previously only Metrowerks was detecting. Working on it. Looks like you're making some progress - today's regex tests for Comeau are looking better:-) * Shows what looks like a Boost config problem

[boost] [filesystem] last_write_time function added

2003-05-11 Thread Beman Dawes
A last_write_time() function has been added to boost/filesystem/operations.hpp It is based on suggestions from Richard Fanta, Ben Hutchings, and Peter Dimov, CVS has been updated. --Beman ___ Unsubscribe other changes:

Re: [boost] Re: CVS status

2003-05-08 Thread Beman Dawes
... various backup suggestions SourceForge already makes the entire Boost CVS tarball available every night, and several Boosters download it daily. (At least I hope they do - I have no way of telling if they are still running their cron jobs.) That is supposed to protect us from total

Re: [boost] Is a 3% timing difference reliably repeatable in real code?

2003-05-08 Thread Beman Dawes
At 11:11 AM 5/8/2003, Darin Adler wrote: On Thursday, May 8, 2003, at 07:04 AM, Beman Dawes wrote: A 2-3% timing difference probably isn't reliably repeatable in real code. How code and data happens to land in hardware caches can easily swamp out such a small difference. The version

Re: [boost] Re: [filesystem] new functions proposals

2003-04-30 Thread Beman Dawes
At 03:21 AM 4/25/2003, Vladimir Prus wrote: Beman Dawes wrote: Beman, if that's fine with you, I'll code them. Yes, go ahead. Although the concept of extension may be foreign on some operating systems, I think the idea is widespread enough to be worth including. If I understand your

Re: [boost] Re: [filesystem] new functions proposals

2003-04-30 Thread Beman Dawes
At 12:14 AM 4/27/2003, Trevor Taylor wrote: So it sounds to me like the :blat is *not* part of the extension. It sounds like the NT file name is made up of three parts: name, extension and stream. In which case I think it is fine to have functions extension() and change_extension() - they just

Re: [boost] Re: [filesystem] new functions proposals

2003-04-30 Thread Beman Dawes
At 10:08 AM 4/27/2003, Pavel Vozenilek wrote: Trevor Taylor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] So it sounds to me like the :blat is *not* part of the extension. It sounds like the NT file name is made up of three parts: name, extension and stream. In which case I think

Re: [boost] Workarounded regression tools for MSVC 6

2003-04-30 Thread Beman Dawes
At 06:40 PM 4/29/2003, Vaclav Vesely wrote: This patch allows to compile regression tools with MSVC 6. First, thanks for going to the effort to work through the various issues. I have very mixed feelings about the patch. Obviously it is great to extend the regression reporting tools to work

[boost] VC++ 7.1 __ctor error [was: iterator_adaptors and vc7.1]

2003-04-29 Thread Beman Dawes
At 06:10 AM 4/16/2003, Thomas Witt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Witt wrote: | | Hi, | | When compiling code using iterator_adaptors with vc7.1 I often get | errors like the following | | c\graphmanager_detail.cpp(76) : error C2061: syntax error : identifier |

Re: [boost] Re: [filesystem] new functions proposals

2003-04-21 Thread Beman Dawes
At 09:15 AM 4/21/2003, Vladimir Prus wrote: Jason House wrote: Vladimir Prus wrote: Does those alternate streams belong to filesystem library at all? For one thing, the ':' symbols is not allowed anywhere except for root name. For another thing, on all systems but NTFS, bar.baz.blip:blat

Re: [boost] Re: Re: Oughtn't filesystem::path acc ept the * and ? wildcards?

2003-04-21 Thread Beman Dawes
At 10:37 PM 4/20/2003, Edward Diener wrote: Beman Dawes wrote: The idea is that rather than directory iteration returning iterators for all path entries, it would only return those which passed a predicate which was driven by the pattern. For some uses, the pattern might more flexibly

Re: [boost] Re: Quantity Library

2003-04-20 Thread Beman Dawes
At 02:28 PM 4/19/2003, Pavel Vozenilek wrote: b7- ability to distinguish different types of the same dimension (e.g. width of image and width of screen) Other examples: It should be an error to try to add gallons of gasoline to gallons of propane. Not to mention trying to add gallons of

Re: [boost] Re: Oughtn't filesystem::path acc ept the * and ? wildcards?

2003-04-20 Thread Beman Dawes
At 02:17 PM 4/20/2003, Edward Diener wrote: Beman Dawes wrote: At 08:22 AM 4/9/2003, Christian Engström wrote: In my application I need to handle paths that contain wildcards, such as for example foo/chapter?.txt or bar/*/index.html. I think that your need is both valid and commonplace

Re: [boost] document translation into Japanese

2003-04-03 Thread Beman Dawes
At 04:01 AM 4/2/2003, k.t. wrote: And in translating, we found some incorrect expressions in boost document. We want to report them for feedback, then is it no problem to report them here? Is boost users mailing list better for it? This list is probably the best place. Thanks, -- Beman

Re: [boost] Regression logs

2003-03-30 Thread Beman Dawes
At 09:46 AM 3/29/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: I think Alisdair's raised some good points. While I'm not sure regression testers will want to put a lot of effort into back tests, I think it would be good if from here on out we segregated current from past

Re: [boost] Comeau and regression testing

2003-03-30 Thread Beman Dawes
At 06:30 PM 3/30/2003, Giovanni Bajo wrote: is it possible to add Comeau to the automatic daily regression testing? I'm willing to go through the bugs and prepare patches as needed to fix compatibility with it. I've got an action item for the C++ committee meeting next week to corner Greg

Re: [boost] Regression logs

2003-03-28 Thread Beman Dawes
At 04:10 PM 3/28/2003, Rene Rivera wrote: [2003-03-28] Alisdair Meredith wrote: For boost 1_29 the Linux regression logs were preserved. For boost 1_30 we have the logs for many more platforms. However, this means that almost half the logs on the testing page are never going to be updated and

Re: [boost] Regression tests failing - tools not building

2003-03-27 Thread Beman Dawes
At 01:28 PM 3/27/2003, Marshall Clow wrote: On Monday, I attempted to run the Darwin regression tests off the main branch. The tools failed to build - specifically process_jam_log failed to build, because the filesystem library failed to compile. In particular,

RE: [boost] random and msvc6

2003-03-26 Thread Beman Dawes
Kirill wrote: Given that boost.random does not have an active maintainer, who could take a look into this? There has been some private discussion going on in the background. Hopefully there will be an announcement within a day or two. In the meantime, keep posting any fixes here - they are

Re: [boost] Re: [date_time] enabling microsec_clock under C++Builder

2003-03-24 Thread Beman Dawes
At 08:04 AM 3/24/2003, Alisdair Meredith wrote: Russell Hind wrote: I agree with that. Would it be better to make it a millisec_clock, or just use the microsec_clock but the resolution is only milliseconds? WinAPI Note: we can get a higher resolution using the QueryPerformanceCounter API (and

Re: [boost] Re: [date_time] enabling microsec_clock under C++Builder

2003-03-24 Thread Beman Dawes
Russell Hind wrote: Does this help? I've just run this quickly on my PIII 800 running Win2K SP3 and worse case for 1,000,000 calls to QueryPerformanceCounter was 1.92seconds, usually between 1.55 and 1.65 seconds (10 runs). LARGE_INTEGER Start, End, Temp; QueryPerformanceCounter(Start);

[boost] 1.30.0 release postmortem

2003-03-24 Thread Beman Dawes
In many ways the preparation Boost 1.30.0 went very well, and the resulting release seems very high quality to me. There were rough edges of course, and we'll try to make some improvements in coming months. Mostly just procedural stuff like making sure we have an active maintainer for all

Re: [boost] Re: [date_time] enabling microsec_clock under C++Builder

2003-03-24 Thread Beman Dawes
Russell Hind wrote: I've just run this quickly on my PIII 800 running Win2K SP3 and worse case for 1,000,000 calls to QueryPerformanceCounter was 1.92seconds, usually between 1.55 and 1.65 seconds (10 runs). I tied it on a 1.8 giga-hertz Pentium 4M, running XP Pro, with very similar results:

RE: [boost] random and msvc6

2003-03-24 Thread Beman Dawes
At 05:47 PM 3/24/2003, Lapshin, Kirill wrote: The interesting part that it fails to compile even when there is no instantiation of the template. In random library this assertion is within #ifndef BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS #endif directives. That makes no sense. That macro is

Re: [boost] RPMS?

2003-03-21 Thread Beman Dawes
At 01:11 PM 3/21/2003, Neal D. Becker wrote: I have built SRPMS for RH8 for boost1.30.0. They required just minor modifications to the spec files. Where should I upload them? Should that be part of the regular Boost distribution, and thus live in CVS? If so, would you be willing to maintain

Re: [boost] RPMS?

2003-03-21 Thread Beman Dawes
At 01:58 PM 3/21/2003, William E. Kempf wrote: Until we have a more formal installation solution, I think the SRPM's spec file should reside in CVS. It would also be nice to have other installation options as well, such as Debian packages (sorrry, not totally familiar with the terminology to

Re: [boost] Boost::format, MSVC, BOOST_TESTED_AT

2003-03-20 Thread Beman Dawes
At 05:58 AM 3/20/2003, Giovanni Bajo wrote: - Original Message - From: David Abrahams [EMAIL PROTECTED] To: Boost mailing list [EMAIL PROTECTED] Sent: Thursday, March 20, 2003 4:06 AM Subject: Re: [boost] Boost::format, MSVC, BOOST_TESTED_AT Great! Why don't you check in a

[boost] Boost version 1.30.0 released

2003-03-20 Thread Beman Dawes
Boost version 1.30.0 has been released. The highlights include: * Filesystem Library added - Portable paths, iteration over directories, and other useful filesystem operations, from Beman Dawes. * Optional Library added - A discriminated-union wrapper for optional values, from Fernando

Re: [boost] Boost version 1.30.0 released

2003-03-20 Thread Beman Dawes
At 01:06 PM 3/20/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: Boost version 1.30.0 has been released. The highlights include: snip no mention of Boost.Python What did I do wrong? I established a news page in my docs; I thought that was the way to go these days

RE: [boost] Boost version 1.30.0 released

2003-03-20 Thread Beman Dawes
At 02:21 PM 3/20/2003, Rozental, Gennadiy wrote: Date-Time Change History is missing It isn't in CVS either. And if it isn't in CVS, it doesn't go in the release. The release is really just an export of CVS as of the release tag. Nothing gets added, nothing gets subtracted. --Beman My

Re: [boost] Win32/VC++ 6.0 lexical_cast problems

2003-03-19 Thread Beman Dawes
At 03:13 AM 3/19/2003, Terje Slettebø wrote: Ok, it seems we may have to exclude wide character support for lexical_cast on MSVC 6, to avoid breaking Date/Time. I suggest something like: #if defined(BOOST_NO_STRINGSTREAM) || \ defined(BOOST_NO_STD_WSTRING) || \

Re: [boost] Re: boost::format 1.30.0-b1 (again)

2003-03-19 Thread Beman Dawes
At 08:06 AM 3/19/2003, Alisdair Meredith wrote: Russell Hind wrote: Does anybody know if this needs fixing, or is it my mistake. If it needs fixing, is someone able to do it before 1.30.0 is released? Yes, I think it needs fixing! Unless others disagree strongly, this should be held for the

Re: [boost] Re: boost::format 1.30.0-b1 (again)

2003-03-19 Thread Beman Dawes
At 08:54 AM 3/19/2003, Alisdair Meredith wrote: I don't know how close the release schedule is now, but if we could at least change the version check from 0x0561 to 0x0564 that would be extrely useful. This would make the difference between our being able to use boost 1_30 'out-the-box' (as I

[boost] OK to tag for 1.30.0 release?

2003-03-19 Thread Beman Dawes
Please speak up now if you have any uncommitted RC_1_30_0 changes or other problems. Otherwise we will tag for release at 3 PM US Eastern Time (20:00 UTC). --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Latest borland patch - compiler version 0x564

2003-03-19 Thread Beman Dawes
At 09:35 AM 3/19/2003, Alisdair Meredith wrote: Alisdair Meredith wrote: I am currently doing a search for other places where borland v 0x0561 is assumed, as I don't think the latest patch fixed any issues that would affect boost and it would be a shame to have to choose between boost and

Re: [boost] OK to tag for 1.30.0 release?

2003-03-19 Thread Beman Dawes
At 12:52 PM 3/19/2003, Beman Dawes wrote: Please speak up now if you have any uncommitted RC_1_30_0 changes or other problems. Otherwise we will tag for release at 3 PM US Eastern Time (20:00 UTC). Currently holding waiting for resolution of Boost.Python link problem. Also, CVS is running so

Re: [boost] Win32/VC++ 6.0 lexical_cast problems

2003-03-19 Thread Beman Dawes
At 04:35 PM 3/19/2003, Terje Slettebø wrote: I see from the CVS that the above has only been put in the header, not the test, as well. It needs to be in both. If it's just in the header, it'll try the wide character tests - on a header that has wide character conversions disabled - a recipe for

Re: [boost] OK to tag for 1.30.0 release?

2003-03-19 Thread Beman Dawes
At 04:36 PM 3/19/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 12:52 PM 3/19/2003, Beman Dawes wrote: Please speak up now if you have any uncommitted RC_1_30_0 changes or other problems. Otherwise we will tag for release at 3 PM US Eastern Time (20:00 UTC

Re: [boost] OK to tag for 1.30.0 release?

2003-03-19 Thread Beman Dawes
At 05:40 PM 3/19/2003, Joel de Guzman wrote: Spirit version 1.5.2 will also have to be bumped to 1.6.0 (the final release version). By convention, odd numbered minor versions are developmental. The final release will have the version change. The patches do not affect the code. Unless there is

Re: [boost] Re: filesystem library name RC_1_30_0 [RESENT]

2003-03-18 Thread Beman Dawes
At 07:25 AM 3/18/2003, Markus Schöpflin wrote: Beman Dawes wrote: At 07:17 AM 3/17/2003, Thomas Witt wrote: the library name is still fs. I was under the impression that this was only temporary and should be changed to a more boost compatible boost_filesystem before release. From

Re: [boost] RC_1_30_0: gcc 2.96 boost/libs/python/test/opaque.cpp failure

2003-03-18 Thread Beman Dawes
At 09:48 AM 3/18/2003, David Abrahams wrote: [EMAIL PROTECTED] writes: it seems to me that these aren't actually legal specializations (though I've never specialized functions before so I could be wrong). Shouldn't that be: template inline type_info

Re: [boost] Re: RC_1_30_0 still broken -- More lexical_cast

2003-03-18 Thread Beman Dawes
At 03:48 PM 3/18/2003, David Abrahams wrote: Terje Slettebø [EMAIL PROTECTED] writes: - With wide character support in lexical_cast enabled for MSVC 6, three tests (of 137) fail. These are omitted for that compiler version, using BOOST_WORKAROUND and BOOST_TESTED_AT. You shouldn't be using

Re: [boost] Re: RC_1_30_0 still broken -- More lexical_cast

2003-03-18 Thread Beman Dawes
At 04:42 PM 3/18/2003, Terje Slettebø wrote: BOOST_CHECK_THROW(lexical_castint( 123), boost::bad_lexical_cast); BOOST_CHECK_THROW(lexical_castint(std::string( 123)), boost::bad_lexical_cast); BOOST_CHECK_THROW(lexical_castbool(123), boost::bad_lexical_cast); If these are omitted for g++ 2.95.x,

[boost] Win32/VC++ 6.0 lexical_cast problems

2003-03-18 Thread Beman Dawes
A fresh version of the Win32 regression tests has just been posted. See http://boost.sourceforge.net/regression-logs/cs-win32-RC_1_30_0-diff.html There are seven new fails in date_time tests; presumably all caused by lexical_cast.hpp problems. See typical error message below. --Beman

Re: [boost] filesystem RC_1_30_0

2003-03-17 Thread Beman Dawes
At 01:38 AM 3/17/2003, Victor A. Wagner, Jr. wrote: I finally got simple_ls to compile and link. The build now correctly builds two libraries (one release, one debug) and if you point to the right place (shouldn't there be some way to marshall the libraries instead of leaving them scattered

Re: [boost] 1.30.0 Outstanding patches and fixes - Sunday night update

2003-03-17 Thread Beman Dawes
At 10:40 PM 3/16/2003, Giovanni Bajo wrote: Could this patch be accepted in time for 1.30.0? I asked yesterday for a fix to array.hpp that allows it to be used when exceptions are disabled, and this looks legit to me. The change looks innocuous to me. Would anyone object if I go ahead an apply

Re: [boost] 1.30.0 Outstanding patches and fixes - Sunday night update

2003-03-17 Thread Beman Dawes
At 07:14 AM 3/17/2003, John Maddock wrote: * [Boost.Regex] [PATCH] Fix GCC 3.3 warnings from Lars Gullik Bjønnes. Awaiting response from John Maddock. (Since this one just eliminates warnings, the release won't be held for it.) That one will have to wait - gcc 3.3 hasn't been

Re: [boost] Re: RC_1_30_0 still broken (apologies and help!)

2003-03-17 Thread Beman Dawes
At 08:16 AM 3/17/2003, David Abrahams wrote: Still looks broken over here: http://cci.lbl.gov/boost/results/1047901021/dailylog_win32_vc60 We are still waiting for SourceForge to clear an errant lock. It can't be fixed until then. --Beman ___

Re: [boost] filesystem library name RC_1_30_0

2003-03-17 Thread Beman Dawes
At 07:17 AM 3/17/2003, Thomas Witt wrote: the library name is still fs. I was under the impression that this was only temporary and should be changed to a more boost compatible boost_filesystem before release. From a pratical point of view fs seems like begging for a nameclash. Good point. OK,

Re: [boost] RE: bidirectional map

2003-03-17 Thread Beman Dawes
At 12:27 PM 3/17/2003, Joaquín Mª López Muñoz wrote: Jeff Garland ha escrito: OK, so how I ask for preliminary review? Posting a mail here? Yes, you can just ask for preliminary feedback on this list. Another thing you can do is put the code in the boost-sandbox. This helps get things

Re: [boost] Re: RC_1_30_0 still broken -- More lexical_cast

2003-03-17 Thread Beman Dawes
At 03:40 PM 3/17/2003, Terje Slettebø wrote: Well, I think this reinforces the suggestion to define BOOST_NO_STRINGSTREAM for 2.95.x. Comments? Either that, or to have some way to detect where std::basic_stringstream is not supported, and turn off wide character support for that, in

Re: [boost] Regex and STLPMT.LIB

2003-03-17 Thread Beman Dawes
At 06:51 PM 3/17/2003, Malcolm Smith wrote: I just compiled the regex library under C++Builder 5. I've tried to compile an application and it complains about not being able to find STLPMT.LIB - I can find no information on this LIB. That's not a Boost library. It's a Borland library. On my

Re: [boost] boost web page nitpick

2003-03-16 Thread Beman Dawes
At 09:50 AM 3/14/2003, Keith Burton wrote: Please see http://www.boost.org/more/download.html#CVS From this page : free GUI clients are also available for Windows, Mac, and other systems from CvsGui.org. The link to cvsgui.org goes to somewhere that appears to be not longer valid Yes, a

Re: [boost] CVS main line is all messed up

2003-03-16 Thread Beman Dawes
At 09:30 AM 3/14/2003, Victor A. Wagner, Jr. wrote: I appreciate the difficulties in getting a release out. I _am_ puzzled about what behavior you wish people (who use (all | any) of boost regularly) to use in validating problems they may encounter (most of the time boost is in a constant state

Re: [boost] RC_1_30_0 still broken (apologies and help!)

2003-03-16 Thread Beman Dawes
At 07:00 AM 3/16/2003, John Maddock wrote: My sincere apologies over the is_class fiasco: those changes were never meant to be checked in. I've being trying all morning to revert to the earlier version, but all I'm seeing is: cvs server: [03:56:46] waiting for johnmaddock's lock in

Re: [boost] RC_1_30_0 filesystem broken

2003-03-16 Thread Beman Dawes
At 01:57 AM 3/16/2003, Victor A. Wagner, Jr. wrote: Ok, I finally got all the junk straightened out. got a clean update for the RC instead of the mainline, and guess what? It looks like it cannot find ANY functions that purportedly are defined in filesystem. oh, compilerVC7.1 --

Re: [boost] Re: RC_1_30_0 still broken (apologies and help!)

2003-03-16 Thread Beman Dawes
At 06:13 PM 3/16/2003, Andreas Huber wrote: Beman John, Both the main trunk and RC_1_30_0 are working fine for me as of Sunday 6PM US Eastern time. Douglas Gregor has already fixed the is_class.hpp problem, please see http://lists.boost.org/MailArchives/boost/msg45230.php Today's Win32

[boost] 1.30.0 Outstanding patches and fixes - Sunday night update

2003-03-16 Thread Beman Dawes
Here is the current list. The second and third items look to me like showstoppers. --Beman * [Boost.Regex] [PATCH] Fix GCC 3.3 warnings from Lars Gullik Bjønnes. Awaiting response from John Maddock. (Since this one just eliminates warnings, the release won't be held for it.) *

Re: [boost] RC_1_30_0 filesystem broken

2003-03-16 Thread Beman Dawes
At 08:17 PM 3/16/2003, Victor A. Wagner, Jr. wrote: Agreed, something is amiss. I've read the docs several times and all they seem to say is everything is in the template includes. Filesystem Library components are supplied by several headers, all in directory boost/filesystem: my #includes

RE: [boost] RC_1_30_0 still broken (apologies and help!)

2003-03-16 Thread Beman Dawes
At 09:20 PM 3/16/2003, Aleksey Gurtovoy wrote: Beman Dawes wrote: Both the main trunk and RC_1_30_0 are working fine for me as of Sunday 6PM US Eastern time. I was unclear; the CVS lock problem was cleared, not the is_class problems. Today's Win32 RC_1_30_0 regression tests (just posted

Re: [boost] CVS main line is all messed up

2003-03-14 Thread Beman Dawes
At 11:00 PM 3/13/2003, Victor A. Wagner, Jr. wrote: for the past 3 hours I've been getting: ...failed updating 300 targets... ...skipped 117 targets... ...updated 8 targets... when trying to make the latest CVS update: date /T update.log time /t update.log cvs -z3 update -A -P -d update.log

Re: Boost RPMS (Was: [boost] Outstanding patches and fixes)

2003-03-13 Thread Beman Dawes
At 04:02 AM 3/13/2003, Vladimir Prus wrote: I believe that Malte Starostik is the right person for dealing with this issue. I'm pretty sure the different is naming is difference between Mandrake and Redhat, but have no idea how to fix it. And, while we're on it, I think it would be much better

Re: [boost] Outstanding patches and fixes

2003-03-13 Thread Beman Dawes
At 10:51 AM 3/12/2003, Jaakko Jarvi wrote: On Wed, 12 Mar 2003, Beman Dawes wrote: Here is my list of outstanding patches and fixes. It would be great if we could resolve the bulk of these for 1.30.0. * tuples::apply Did this every get resolved? Aleksey? Jaakko? Aleksey's message

Re: [boost] Before we get too carried away...

2003-03-13 Thread Beman Dawes
At 02:24 AM 3/13/2003, Daryle Walker wrote: 4. My testing was with a stock Boost 1.29.0 from a zip file. If the CVS version of Boost already has fixes for CW-DS and/or CWP8.3, I'll switch to that and apologize for wasting everyone's time. Daryle, with all the current focus on 1.30.0, I'm not

Re: [boost] Re: Outstanding patches and fixes

2003-03-13 Thread Beman Dawes
At 11:52 AM 3/12/2003, Alisdair Meredith wrote: I have also reported and not seen rejected: (easily lost in the volume surrounding a release) [2 Random fixes also required for Graph] === RCS file:

Re: [boost] Outstanding patches and fixes

2003-03-13 Thread Beman Dawes
At 11:42 AM 3/12/2003, Sam Partington wrote: Daniel Frey wrote: Beman Dawes wrote: * Possible addition to operators library from Sam Partington Daniel Frey and Sam discussing changes. We need some discussion of it and I would like to see it in CVS and thus in the regression tests

Re: [boost] Outstanding patches and fixes

2003-03-13 Thread Beman Dawes
At 07:59 AM 3/13/2003, John Maddock wrote: * Regex make boost work better patch from Lars Gullik Bjønnes John Maddock will investigate once new machine working should be done soon. OK. * PRB with type_traits::is_member_function_pointer Would prefer John Maddock or someone else more

[boost] Update: Outstanding patches and fixes

2003-03-13 Thread Beman Dawes
Here is the current list: * lexical_cast problems. Hold changes for next release? * Regex make boost work better patch from Lars Gullik Bjønnes John Maddock says he will apply soon. * [status/Jamfile] Jamfile patches for Borland Dave says factor commonality out into template. Too late

Re: [boost] Update: Outstanding patches and fixes

2003-03-13 Thread Beman Dawes
At 10:58 AM 3/13/2003, Daniel Frey wrote: Beman Dawes wrote: * Daniel Frey: provided a fix for some warnings in the type-traits (is_class/is_enum IIRC), John Maddock is aware of it AFAIK. Just to remove any doubts: This should not be a show-stopper. The warnings are in there for quite some

[boost] lexical_cast fixes

2003-03-13 Thread Beman Dawes
Kevlin has done an update that incorporates the overloading fix and is less permissive about which platforms will get wide character support. The Win32 tests are now looking as good or better than with the old 1.29.0 version. See

[boost] Outstanding patches and fixes

2003-03-12 Thread Beman Dawes
Here is my list of outstanding patches and fixes. It would be great if we could resolve the bulk of these for 1.30.0. If you resolve any of these issues, please let me know so I can clear it off the list. Thanks, --Beman * lexical_cast changes Kevlin and Terje doing final tests on changes.

Re: [boost] Re: C++ Standards Committee upcoming meeting

2003-03-12 Thread Beman Dawes
At 11:19 PM 3/11/2003, Douglas Gregor wrote: As it stands, the system itself is in good shape, and the documentation for libraries I've redocumented in BoostBook is quite reasonably. I still think a BoostBook overview/tutorial at Oxford would be beneficial. Let's plan on it. Would Sunday

Re: [boost] typ_traits documentation nitpick

2003-03-12 Thread Beman Dawes
At 07:41 AM 2/13/2003, Fredrik Blomqvist wrote: boost::is_polymorphic documentation is written in a slightly larger font than the rest of the items and there's also a spelling error ('magority') in the following text. Fixed. Thanks! --Beman ___

Re: [boost] Re: Patch for multi_array/test/constructors.cpp

2003-03-12 Thread Beman Dawes
At 07:11 AM 3/12/2003, Markus Schöpflin wrote: Markus Schöpflin wrote: currently the constructors test of the multi array library fails for VACPP6. This is due to the fact that the test uses an unsigned int where a size_type should be used. The attached patch replaces the unsigned int with

<    1   2   3   4   5   6   >