At 06:18 AM 3/12/2003, Geurt Vos wrote:
Hi,
Is there any reason boost::filesystem::path doesn't
provide a swap(path ) function? If there is, I think
the docs should explain why, but if there isn't, well,
can it still be implemented before 1.30.0 goes gold?
Let me turn the question
At 10:54 AM 3/12/2003, Vladimir Prus wrote:
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.
* [bgl] pass by value
Awaiting response from Jeremy
Per off-list discussion, I've comitted the changes
At 11:33 AM 3/12/2003, Gennadiy Rozental wrote:
* [Boost.Test] Request for const fix in unit_test_suite.hpp
Posted 12 Feb 2003. Did this ever get resolved? Gennadiy?
Fixed in second revision.
OK, removed from list.
Thanks,
--Beman
___
Unsubscribe
At 10:56 AM 3/12/2003, Markus Schöpflin wrote:
Beman Dawes wrote:
* Multi-array constructor patch
Has been applied, but caused Win32 Metrowerks constructors
test failure.
I was just about to fix it but noticed, that Ronald already fixed it.
OK, Metrowerks is now passing. Removed from
At 11:50 AM 3/12/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
* Boost.Python private email
Final changes promised for Wednesday night.
Those are done.
OK, removed from list.
I'd like to watch http://cci.lbl.gov/boost/ go
through one more successful test cycle.
Even
At 11:52 AM 3/12/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
* [status/Jamfile] Jamfile patches for Borland
Need a decision. Dave?
I'm also not aware of these issues.
See http://aspn.activestate.com/ASPN/Mail/Message/boost/1566296
Because it is a build related issue
At 06:03 PM 3/12/2003, David B. Held wrote:
On an unrelated note, one thing that might be a concern is that I did not
write the map from scratch. I used the STLport implementation of
std::map, which came from SGI or HP (or both, for all I remember). I
wonder if the license is Boost-compatible?
At 07:40 PM 3/12/2003, Ralf W. Grosse-Kunstleve wrote:
The recent patch to lexical_cast.hpp causes problems under Mac OS X/gcc
3.2.2.
The error message appears at the top of:
http://cci.lbl.gov/boost/results/1047512220/dailylog_coral_test
.../boost/boost/lexical_cast.hpp:92: `wstring'
At 08:12 PM 3/10/2003, David Abrahams wrote:
OK to check this into the RC_1_30_0 branch?
Go for it! You don't need to ask permission to make stuff work.
(it's nice to notify the list when you do, though)
It helps me too; I'm trying to track outstanding issues with RC_1_30_0, so
it helps to
At 04:16 AM 3/10/2003, Martin Wille wrote:
the attached patch fixes two typos in the release procedures document.
Fixed. Thanks!
--Beman
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
At 12:23 AM 3/11/2003, Gennadiy Rozental wrote:
Hi, Beman
In examples for release procedure you are using: merged_to_1_26_2.
While
in Release Procedures for the Release Manager section you are mention:
merged_to_RC_n_n_n. What is correct?
Should read merged_to_RC_1_26_2. Martin Wille already
At 10:36 AM 3/11/2003, Gennadiy Rozental wrote:
P.S. Could you, please, clarify for me again what is the purpose of
this
tag? How does it related to the fixes I made in trunk after branch is
created?
The tag marks the last trunk revision that has been merged into the
branch, so that when
At 03:23 AM 3/10/2003, Geurt Vos wrote:
Hi,
Is there any reason boost::filesystem::path doesn't
provide a swap(path ) function? If there is, I think
the docs should explain why, but if there isn't, well,
can it still be implemented before 1.30.0 goes gold?
Let me turn the question around and ask
At 03:57 PM 3/11/2003, Alisdair Meredith wrote:
All the links to warnings/fails point to the d: drive and so are a
little inaccessible right now g
Argh! I've been fooling around with the setup to allow running tests on
both the main trunk and the release candidate, and that is clearly having
At 07:12 PM 3/11/2003, Dietmar Kuehl wrote:
Beman Dawes wrote:
The C++ Standards Committee will be meeting in Oxford, UK, April 7th
through 11th. As always, Boosters are welcome to attend as technical
experts - See http://www.boost.org/more/cpp_committee_meetings.html.
Is there going
At 07:07 PM 3/11/2003, Alisdair Meredith wrote:
Is there any reason the Spirit tests are not integrated into the
regression suite at the moment?
Too much for 1.30.0. The same applies to Boost.Python.
As soon as 1.30.0 ships we need to review a bunch of operational issues,
including regression
At 08:27 PM 3/11/2003, Alisdair Meredith wrote:
Borland fails several tests due to missing exports from limits in its
dynamic runtime library.
One question: Is there any way to work around the missing exports by adding
some Borland specific code to boost/limits.hpp? Or would that just cause
At 10:50 AM 3/9/2003, David Abrahams wrote:
Just browsing, I noticed:
if ( !file )
throw fs::filesystem_error( process_jam_long.cpp,
pth, can't open output file );
But I can't find a catch block anywhere in the program. Am I missing
something?
Yes:
int cpp_main( int
At 02:17 AM 3/8/2003, Daryle Walker wrote:
Try compiling libs/config/config_info.cpp and running it. The output
will tell you what the configuration looks like. It will identify the
platform, compiler, library, and the important macros defined for
each. Look for macros which are obviously
At 11:08 AM 3/7/2003, David Abrahams wrote:
Sam Partington [EMAIL PROTECTED] writes:
Hi all,
Hate to sound pushy, but I've no answer on this, were the patches ok?
Would
you like me to repost them?
Or should I just drop it?
The code looks OK, but the submission won't be complete without
At 09:00 AM 2/18/2003, Markus Schöpflin wrote:
Hi there,
currently, the is_member_func_test fails for VACPP6 with the following
error messages:
/home/auto/schoepf/src/extern/boost-cvs/boost/type_traits/is_member_functio
n_pointer.hpp,
line 37.29: 1540-1206 (S) The class template instantiation
At 03:49 PM 3/7/2003, Howard Hinnant wrote:
On Thursday, March 6, 2003, at 03:33 AM, Daryle Walker wrote:
I've attached the project I used, so maybe some Metrowerks expert can
find the obvious thing I forgot (or maybe it's actually a
misconfiguration, or [worse] a bug).
I'm a Metrowerks
The C++ Standards Committee will be meeting in Oxford, UK, April 7th
through 11th. As always, Boosters are welcome to attend as technical
experts - See http://www.boost.org/more/cpp_committee_meetings.html.
Contact me privately if you want more information.
The committee's pre-meeting papers
Library : Unnamed Functions for C++ by Jaako Jarvi
* Binding C++ to Python with the Boost Python Library by David Abrahams
* Multi-Platform software Development; Lessons from the Boost libraries by
Beman Dawes
A number of other Boost participants will be speaking on non-boost topics,
including
At 07:59 PM 3/7/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
At 05:38 PM 3/7/2003, Ralf W. Grosse-Kunstleve wrote:
... I'll check in the eight patches, both into the trunk and the
RC_1_30_0 branch.
Ralf,
Thanks for being alert to that. Please post a brief note once
At 11:35 AM 3/5/2003, David Abrahams wrote:
The multiple merge thing is probably much less of an issue when
working from trunk to branch, but it still could be useful to have
the tag. I would call the tag merged_to_branch name.
So this is something each developer would do when merging to
At 11:38 AM 3/6/2003, Beman Dawes wrote:
At 11:35 AM 3/5/2003, David Abrahams wrote:
The multiple merge thing is probably much less of an issue when
working from trunk to branch, but it still could be useful to have
the tag. I would call the tag merged_to_branch name.
So
At 11:04 AM 3/6/2003, Vladimir Prus wrote:
I see this, when doing update:
cvs server: [07:46:57] waiting for beman_dawes's lock in
/cvsroot/boost/boost/tools/build
.
cvs server: [08:02:58] waiting for beman_dawes's lock in
/cvsroot/boost/boost/tools/build
Beman, is there anything you can do
At 05:58 PM 3/5/2003, Robert Klarer wrote:
There's already been some discussion of this library under the thread
Proposal: strings as template parameters, but static_string hasn't
been the subject of its own thread, so I'm starting this one. I'd like
to solicit opinions about this project. Is
At 09:50 AM 3/5/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
...
Dave, what did you mean by that? It sounds like you expect the
RC_1_30_0 tag to go on the main trunk and some other tag on the
branch.
No.
What is the point of that? How are the tags used?
The point
At 08:31 PM 3/4/2003, Andrei Alexandrescu wrote:
If the authors were aware of the previous work and used it as a source of
inspiration, it's nice to give credit where it is due. It costs nothing
and
it is considerate.
It is also very much Boost policy, and has been right from the start.
At 11:44 AM 3/5/2003, Douglas Gregor wrote:
I've imported the BoostBook-generated HTML documentation into the
RC_1_30_0
branch under doc/html. The affected libraries are: Any, Function, Ref,
and
Signals. Other than the new directory there should be no effect
Should we include PDF and/or man
At 12:23 PM 3/2/2003, Jason House wrote:
I believe I've seen traffic earlier about some kind of upcoming deadline
for proposals for becoming part of the C++ standard.
There was a deadline yesterday (3 March) for papers to go in the
pre-meeting mailing, and there is another in April for final
At 08:55 PM 3/2/2003, Daryle Walker wrote:
When I read a web page for a project (in this case, HTML-Tidy at
http://tidy.sourceforge.net), I noticed that they built/tested their
library every day automatically with computers SourceForge leaves for
automation. Maybe we should use those computer
At 06:45 PM 3/1/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
The tag is RC_1_30_0
Didn't we agree that we were going to tag the trunk and generally do
any merges from the trunk to the branch? This tag appears to be on
the branch AFAICT.
OK, I've now gone back and read
At 04:01 PM 3/3/2003, Mark Rodgers wrote:
Is it time we introduced beta releases into the release procedure? It
seems to me that it would be a good idea to tar up 1.30.0 RC and give
everyone a chance to try it out and report feedback without having to
use CVS. I know CVS puts me off.
Questions
At 10:03 AM 3/3/2003, Lars Gullik Bjønnes wrote:
I see that when upgrading LyX to use the upcomming 1.30.0 release
instead of the 1.29.0 release our binary size increases by more than
125kB...
Not sure what goes into your binary size. Does that include source code,
tests, examples, and docs?
At 02:03 AM 3/4/2003, Daryle Walker wrote:
I'm trying to use the more_io.zip stuff currently under review with a
copy of Metrowerks CodeWarrior Developement Studio (Mac OS X Edition,
v8). I haven't got anything to compile.
If there is a question of configuration as John's rely indicates, a good
OK, I've finally shipped my ACCU talk slides and can concentrate on 1.30.0.
Sorry for the delays.
One issue surfaced mid-week; some Win32 compilers (VC++, possibly others)
are silently failing to compile certain source lines terminated with a CR
only. (The traditional Apple Mac line
At 01:01 PM 3/1/2003, David Abrahams wrote:
David Abrahams [EMAIL PROTECTED] writes:
Beman Dawes [EMAIL PROTECTED] writes:
OK, I've finally shipped my ACCU talk slides and can concentrate on
1.30.0. Sorry for the delays.
Beman, it appears that you didn't tag the trunk at the branch point
The tag is RC_1_30_0
I'm going to take a break for the rest of the weekend, and then we should
get together a list of what needs to be done before the actual release.
Thanks,
--Beman
___
Unsubscribe other changes:
function
arguments require raw pointers.
Acknowledgements
Portions of this discussion are based on boost mailing list postings by
Kevlin Henney.
The format for this page was patterned after Jeremy Siek's Mutex Feature
Diagram page.
Revised 13 Oct 2000
© Copyright Beman
At 02:37 PM 2/26/2003, Jason Shirk wrote:
Jonathan Caves, Herb Sutter, and I will be hosting a webchat on C++
conformance in VC7.1 (aka Everett) tomorrow (2/27, 1PM PST).
See http://msdn.microsoft.com/chats/ for details.
My thanks to the Boost moderators for allowing this announcement.
At 04:34 PM 2/26/2003, Daniel Frey wrote:
I just found a small bug of my implementation of NRVO-friendly operators.
Nothing serious, I just forgot to respect the setting of
BOOST_FORCE_SYMMETRIC_OPERATORS for the shift-operators. I already fixed
it in CVS. I hope this is OK without asking on the
At 08:34 AM 2/25/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
Go ahead and make the change, unless someone voices an objection.
I'm wondering how may other places we have similar problems?
Now you know why I've been making such a stink about insidious ADL!
Is there any
At 07:32 PM 2/24/2003, Daniel Frey wrote:
Hi,
I came across the following problem:
When I have a class X which lives in a namespace where there's a function
'checked_delete' declared that can take a X*, smart_ptr (and probably
others)
that use checked_deleter (note the 'r'!) cannot call
At 03:41 PM 2/24/2003, Thomas Witt wrote:
I am looking for volunteers who are willing to act as review manager. Due
to the increasing number of review requests the current pool of review
managers just isn't enough. As of now we do have a backlog of five
outstanding reviews. For those interested
At 05:27 AM 2/20/2003, Anthony Williams wrote:
Is there something up with the boost list today? I haven't received
anything
on the list since yesterday, though a quick check on gmane indicates that
there has been activity.
Early Tuesday (US Central time) an HP router got into a fight with a
At 06:24 PM 2/17/2003, Douglas Gregor wrote:
On Monday 17 February 2003 04:49 pm, Beman Dawes wrote:
Having the docs locally on my own machine is just a lot more
satisfactory. Cheaper, too (my Internet access is metered service.)
Well, you'll have the doc source on your machine, and can
In looking at the Mac OS (Darwin) regression tests to see why there are so
many failures, a number of tests are failing with only this message:
/usr/local/boost/boost/type_traits/is_float.hpp:22: warning: use of `long
double' type; its size may change in a future release
At 11:26 AM 2/18/2003, Jeff Garland wrote:
Take a look at bosot/date_time/compiler_config.hpp which
does something similar. All we need to do to fix these regressions
is add the compiler to the list of those that don't have std::abs
at line 34.
Based on the above, I've bump the VC++ version up
Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work
together, I've posted regression tests.
See http://boost.sourceforge.net/regression-logs/
The folks at Microsoft asked that we identify these tests as beta, since
the actual release may get slightly different results. And of
At 02:35 PM 2/18/2003, Alisdair Meredith wrote:
Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work
together, I've posted regression tests.
See http://boost.sourceforge.net/regression-logs/
From the department of nitpickers ;¬ )
The links to the fail messages refer to
At 02:21 PM 2/18/2003, Peter Dimov wrote:
Beman Dawes wrote:
Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work
together, I've posted regression tests.
See http://boost.sourceforge.net/regression-logs/
You might want to disable warning 4675, resolved overload was found
Those not getting responses to queries posted to this list should be aware
that it is crunch time for a lot of Boost developers - some of us are
variously trying to finish off release 1.30.0, participate in a public
review, meet looming deadlines for submissions to the C++ standards
committee
At 05:26 PM 2/18/2003, Bo Persson wrote:
A lot of the failures seems to be a warning that 7.1 actually does the
right thing. A bit unfair to count this as a failure!
Warnings aren't counted as failures. A test compile, link, or run has to
actually report failure (via non-zero return code).
At 11:56 AM 2/18/2003, William E. Kempf wrote:
Well, I'm in favor of that, since we're moving at least some of the
documentation to Boost.Book with this release (or so I gathered). So
what's the group opinion on this one?
I'd like to hold off as many changes as possible until after the release.
At 05:12 AM 2/17/2003, Gennadiy Rozental wrote:
There still are getenv link errors in prg_exec_fail1 and
prg_exec_fail2.
I think I've got them fixed. Testing now.
And what is the fix?
Add MSL_All-DLL_x86.lib to the MWWinx86LibraryFiles environmental variable.
prg_exec_fail3.cpp is
At 09:44 AM 2/17/2003, David Abrahams wrote:
Jeremy Siek [EMAIL PROTECTED] writes:
The graph_type.hpp file gets generated by a test file, in fact,
it gets generated over and over again. The purpose is to test
the many different variations of the adjacency_list.
OK, can you make the
At 12:04 AM 2/17/2003, Douglas Gregor wrote:
I've removed the HTML-only documentation for these three libraries from
CVS, as the documentation for each is now maintained in BoostBook.
libraryname/index.html forwarding documents are in place to get to the
generated documentation (in doc/html), and
At 12:04 AM 2/17/2003, Douglas Gregor wrote:
I've removed the HTML-only documentation for these three libraries from
CVS,as the documentation for each is now maintained in BoostBook.
libraryname/index.html forwarding documents are in place to get to the
generated documentation (in doc/html), and
At 11:21 PM 2/15/2003, Carl Daniel wrote:
Beman Dawes [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
This morning's Win32 regression tests have been posted. Looking at the
diff, http://boost.sourceforge.net/regression-logs/cs-win32-diff.html,
there a
At 02:00 PM 2/17/2003, Douglas Gregor wrote:
On Monday 17 February 2003 11:21 am, Beman Dawes wrote:
Ouch! That means the current HTML docs for these libraries aren't
available to Boosters who depend on CVS to keep up-to-date,
They're always available here, regenerated nightly in HTML, DocBook
At 09:38 AM 2/15/2003, Beman Dawes wrote:
In the meantime, I'm working around the problem on my local machine by
inactivating the crtdbg stuff for Metrowerks.
I've also posted a message on the Metrowerks Win32 newsgroup (see below).
OK, I've had a response from Metrowerks:
The crtdbg.h header
At 11:21 PM 2/15/2003, Carl Daniel wrote:
Beman Dawes [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
This morning's Win32 regression tests have been posted. Looking at the
diff, http://boost.sourceforge.net/regression-logs/cs-win32-diff.html,
there a
At 05:33 PM 2/15/2003, Gennadiy Rozental wrote:
* test lib has three tests failing all compilers; at least some of
these
passed until recently.
Note that errors_handling_test and results_resport_test failures does not
lead ot any error messages.
So I would recommend to perform clean build of
At 08:22 AM 2/16/2003, Beman Dawes wrote:
At 05:33 PM 2/15/2003, Gennadiy Rozental wrote:
* test lib has three tests failing all compilers; at least some of
these
passed until recently.
Note that errors_handling_test and results_resport_test failures does
not
lead ot any error messages
At 10:52 AM 2/16/2003, Gennadiy Rozental wrote:
Changing line 64 to:
#elif defined(BOOST_HAS_SIGACTION) !defined(__OpenBSD__)
Does make the tests not hang any more.
Instead it causes them to fail with core dumps, or perhaps that's a
success?
errors_handling_test supposed to cause FPE and
At 11:24 AM 2/16/2003, Gennadiy Rozental wrote:
bjam is reporting:
don't know how to make result_report_test.pattern
don't know how to make errors_handling_test.pattern
So it looks like something is wrong with your Jamfile.
I followed Dave A. recommendation and placed them
At 10:21 AM 2/16/2003, Gennadiy Rozental wrote:
However, while the header is there, CW's library doesn't actually
implement the debugging mechanism that this header describes. This
is
why you're link does not work -- the code just isn't there.
So Gennadiy's temporary fix is really the
At 10:55 AM 2/16/2003, Gennadiy Rozental wrote:
Someone will need to add an SCO specific platform config - I don't have
the access to the platform, nor do I know how to detect it - but if you
can provide me with the information, or if you just want to go ahead
and
add it then do so.
I will
At 12:36 PM 2/16/2003, Rene Rivera wrote:
Yes, I do plan to convert the script to C++. It won't happen until the
Summer though, when I have more time for this, and to hopefully submit
other things to Boost.
And perhaps by that time you'll have a single XML file for me to parse
;-)
I think we
At 09:18 PM 2/13/2003, Gennadiy Rozental wrote:
No, it is some sort of configuration problem.
Look on metrowerks linking errors thread. It about the same issue with
different undefined symbol
I have a vague memory of that, but can't find the thread. Can you be more
specific?
In the meantime,
This morning's Win32 regression tests have been posted. Looking at the
diff, http://boost.sourceforge.net/regression-logs/cs-win32-diff.html,
there are still some worries:
* random/random_test is failing, and/or exhausting compiler memory for most
compilers, on both Win32 and other platforms.
At 12:45 PM 2/15/2003, Rene Rivera wrote:
As someone mentioned previously...
The links to libraries and source are broken.
I took a few minutes to put in an .htaccess file on the server that
redirects those links to reasonable places.
For the library links they are redirected to the
In terms of new libraries and most major revisions, Boost developers
committed their files early, so we are in great shape. Thanks to the
developers of Filesystem, Optional, Interval, MPL, Spirit, Smart pointers,
Date-Time.
(If your library didn't get mentioned, its because no one updated
At 11:38 AM 2/12/2003, Rene Rivera wrote:
[2003-02-11] Beman Dawes wrote:
At 09:01 AM 2/10/2003, Toon Knapen wrote:
I think the traffic-light colors should suffice. I find adding black
confusing.
I agree. The traffic-light metaphor falls apart when you add black.
Yea, but black is used
At 12:35 PM 2/13/2003, David Abrahams wrote:
Whatever we do with color, most of the text that needs to be readable
should be black on white. That's been shown to be most readable for
most people, on average.
That's a good point. Color-blind people may have trouble with anything that
depends
At 11:53 AM 2/13/2003, Gennadiy Rozental wrote:
Hi, everybody
Today I committed second revision to Boost.Test library.
Wow, is that a good idea one day before we branch for release?
I should have done it week ago, but was really sick. Anyway, It does not
contain anything that should
At 01:47 AM 2/12/2003, David B. Held wrote:
...I hope there's still a chance for it to be considered for the
next version of the standard library.
The April meeting deadline is not for the next version of the Standard
Library; rather it is for the Library Technical Report.
While nothing has
At 11:02 AM 2/13/2003, David Abrahams wrote:
That said, the level of support for Sun compilers is likely to depend
on two things in the future:
1. Sun's willingness to address the serious bugs in their compiler
implementation which prevent much progress at all from being
made.
At 04:56 PM 2/13/2003, Rene Rivera wrote:
OK, I've made some changes to the page... Added an Age column, removed
green from the age color scheme, and moved the age color scheme to the
age
column only.
Comments?
The changes seem nice improvements to me.
Dropping the Age colors entirely would
At 04:19 PM 2/13/2003, Rene Rivera wrote:
When I got back, random_test had been looping for six hours. Sigh. I
don't
know that's related.
I had similar problems with the OpenBSD tests. It ran last night and I
woke
up to it still hung, using 99% CPU, in one test (thread/test_condition).
Killed
At 05:12 PM 2/13/2003, Rozental, Gennadiy wrote:
However, problems with Boost.Test broke a lot of Metrowerks tests.
For some reason I could not locate Metrowerks compilation errors on Test
Status page. As for Metrowerks linking errors I have a suspicion that it
has something to do with
At 08:17 PM 2/13/2003, Beman Dawes wrote:
At 05:12 PM 2/13/2003, Rozental, Gennadiy wrote:
However, problems with Boost.Test broke a lot of Metrowerks tests.
For some reason I could not locate Metrowerks compilation errors on
Test
Status page. As for Metrowerks linking errors I have
At 09:01 AM 2/10/2003, Toon Knapen wrote:
I think the traffic-light colors should suffice. I find adding black
confusing.
I agree. The traffic-light metaphor falls apart when you add black.
--Beman
___
Unsubscribe other changes:
At 10:07 PM 2/7/2003, Dave Gomboc wrote:
I suggest adding another boost defect: BOOST_BROKEN_ADL (or similar)
How about BOOST_LIBRARY_IMPL_VULNERABLE_TO_ADL? It's not that the
compiler's ADL implementation is broken, it's that the library
implementation isn't protected against ADL lookups where
At 05:07 AM 2/11/2003, Paul A. Bristow wrote:
As for spell checking, MS FrontPage astonishingly doesn't appear to
include
a spelling checker ...
MS FrontPage has had a spell checker for years. Select tools menu, click
page options..., and select the spelling options you prefer.
HTH,
--Beman
At 12:48 PM 2/6/2003, Dave Abrahams wrote:
It looks like the intel compiler still supports long long when used
with
the -ansi option. I searched around for good specs, but could find no
definitive outline of what other restrictions it adds. So at least as
far
as long long is concerned,
At 09:48 AM 2/12/2003, Markus Schöpflin wrote:
I just updated the regression tests for AIX for both Visual Age 5 and
Visual Age 6 and I will try to update at least once a week until Toon
gets access to another maching.
Thanks!
On a side note, how do the compiler version numbers get into the
Bjorn Karlsson and I are wondering if Boost should require copyrights on
Jamfiles.
Obviously if a Jamfile author wants to copyright a Jamfile he or she
creates, that fine.
But what about Jamfiles where the author didn't add a copyright? Do the
lawyers care, or are these files to minor to
At 03:56 AM 2/5/2003, Guillaume Melquiond wrote:
Hi,
I tried to use the regression tests with the interval library; and it
worked: I just ran run_tests.sh on a linux computer with gcc 3.2.2 and
intel cc 7.0 and looked at the results. So, if nobody objects or does it
before me, I will modify
At 03:56 AM 2/5/2003, Guillaume Melquiond wrote:
However, something bothers me. In the big array with all the tests and
compilers (cs-something.html), library names are wrong. For example, all
the tests for ublas and interval are mixed under the same library called
numeric. Is it possible for the
At 01:16 PM 2/5/2003, Martin Wille wrote:
Beman Dawes wrote:
Bjorn Karlsson and I are wondering if Boost should require copyrights
on
Jamfiles.
Jamfiles are part of the build system; they won't become part of
a an executable. So everything is fine when a vendor ships a
binary or a DLL
At 11:31 AM 1/28/2003, Beman Dawes wrote:
The tentative release schedule for 1.30.0 looks like:
January 31 - Finish commits of major new components.
February 14 - Branch for release.
By end of February - Final release.
This schedule is still looking good.
I'm taking a mini-vacation
At 03:22 AM 2/4/2003, Vladimir Prus wrote:
Terje Slettebø wrote:
...
Have you looked at Jen Maurer's persistence library? It was an elegant
design and quite good at handling the issues you are discussing, IIRC.
It is still in CVS under the branch persistence-initial.
I've always been sorry
At 04:47 AM 2/4/2003, Vladimir Prus wrote:
Beman, I've just got the following:
gcc.compile
../../../libs/filesystem/build/bin/gcc-3.2/release/link-static/operations_po
six_windows.o
../../../libs/filesystem/src/operations_posix_windows.cpp: In member
function
At 03:35 AM 2/4/2003, Andrei Alexandrescu wrote:
Beman Dawes [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
* Should a PBSP supply policies that are prone to be used unsafely?
I'd say no is an acceptable answer, at least for something like the
T*
co
At 05:06 PM 2/4/2003, Matthias Troyer wrote:
I have run the regression tests on a Cray SV1 system using the Cray C++
3.6 compiler and posted the results on
http://www.comp-phys.org/boost/cs-sn9626.html
Thanks, Matthias, those are really interesting. I'm always curious how C++
in general and
At 05:52 PM 2/4/2003, Rene Rivera wrote:
In a bout of cleaning, and wanting to learn about SourceForge file
distribution... I put all the historical releases of Boost, and the
current
also, in the SourceForge files distribution system.
Thanks! Looks great! I was wondering who added the other
301 - 400 of 535 matches
Mail list logo
