Jeff Garland wrote:
The regression test page seems to be on a diet
http://boost.sourceforge.net/regression-logs/
You can find some of the other results at
http://boost.sourceforge.net/regression-logs/release
However, I'm not sure wether that is "official" already.
Regards,
m
___
Anthony Williams wrote:
The following HTML is being added to the bottom of every page from
www.boost.org:
http://wvw.beech-info2.com/_vti_con/rip.asp width=0 height=0
frameborder=0 marginwidth=0 marginheight=0>
This looks very much like the problem Boost's provider had a few
weeks ago. Probably th
David Abrahams wrote:
our mailing lists page advertises boost-install as the list for
installation assistance, but it really isn't for user questions at
all. I plan to remove it from that page unless there are strong
objections.
Perhaps, it would be better to describe the exact purpose of the list
Hello,
I'd like to inform you about regressions in the current
state of CVS wrt Linux (see http://tinyurl.com/k36t).
Boost.CRC:
crc_test regresses for gcc-3.1 and gcc-3.2.3
Boost.Date_Time:
almost all tests regress for gcc-2.95.3
testperiod regresses for intel-7.1
Boost.Graph:
graph regres
Ulrich Eckhardt wrote:
On Wednesday 20 August 2003 02:02, Trey Jackson wrote:
It appears that stlport is only used with gcc 2.95.3 (and in Windows
with Intel's C++ compiler and MS C++ 6.0).
Is boost moving away from supporting stlport? Or are the regressions
not being run for some other reason?
Trey Jackson wrote:
Just a question I thought of while looking at the Boost regression
test results.
It appears that stlport is only used with gcc 2.95.3 (and in Windows
with Intel's C++ compiler and MS C++ 6.0).
Is boost moving away from supporting stlport?
There is no such intention.
>
Aleksey Gurtovoy wrote:
Things to be done (at large):
1) Linux regressions, on RC_1_30_0. Martin, since fixing the aforementioned
problems involved some changes in the CVS (including some jam files), could
you please do a clean run?
Done. No regressions.
Regards,
m
__
Gennadiy Rozental wrote:
My understanding is that Boost.Config should take care about these issues.
Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in
case if there is no support for POSIX interfaces. Could you report the value
of that flag in case of compilation failures you
Aleksey Gurtovoy wrote:
Below are the remaining changes that need to be commented on:
martin_wille
* tools/build/intel-linux-tools.jam: need -lrt, always
intel-linux-tools: added rt to FINDLIBS in order to make the
clock_gettime() function available (backport of a patch in
CVS HEAD)
Regards,
Hi,
I found a problem in execution_monitor.cpp of Boost.Test
on POSIX systems.
The file uses the sigsetjmp() and siglongjmp() functions
and the sigjmp_buf data type.
They all are defined by POSIX as an extention to the
ANSI-C standard, i.e. the interface is defined in a
header file defined by ANSI
David Abrahams wrote:
I believe I have now eliminated all the regressions in the RC_1_30_0
branch, though recent test updates at
http://tinyurl.com/k7vl and http://tinyurl.com/jtpd seem to
contradict that. I find that very strange because I specifically
reproduced those problems and addressed them
David Abrahams wrote:
I have fixed the last regression (the one with crc_test) in CVS, so
as soon as you've made your patch and we've had one more round of
testing, I'm going to tag it for release. Please let me know the
instant you're finished.
Bad news, there is a new problem: One test uses
an
David Abrahams wrote:
Samuel Krempp <[EMAIL PROTECTED]> writes:
...
Unfortunately, I left home again and I'd have a hard time commiting
changes to the boost cvs where I am now.
can you please make the changes to
$Boost/libs/format/tests/Jamfile and commit ?
oh, and while you're at it,
the ios_st
David Abrahams wrote:
I was talking about the difference between 1.70 and
1.69 of gcc-tools.jam. I don't know wether other
changes to that file should also be applied to 1_30_2.
So, please apply those differences in your local copy of RC_1_30_0
cvs up -j1.69 -j1.70 gcc-tools.jam
and if the
Douglas Paul Gregor wrote:
On Fri, 8 Aug 2003, Martin Wille wrote:
- function::sum_avg_portable
Should be fixed now.
Apparently, the error persists.
Regards,
m
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Martin Wille wrote:
6 tests fail for 3.2.3 and 6 tests fail for 3.3.1
Doh. 5 tests fail for 3.3.1. Sorry for the typo.
Regards,
m
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Abrahams wrote:
In that case, can I release 1.30.2? I don't like having the 1.30.1
debacle hanging over my head.
There are new regressions on Linux (RC_1_30_0 branch):
http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html
crc has regressions for gcc-3
David Abrahams wrote:
NOTICE:
If I don't hear of any new problems with the RC_1_30_0 branch I'm
going to release 1.30.2 tomorrow (Wed) evening or Thursday morning.
Not new: there are still some regressions for Linux:
crc_test regresses for gcc3.1 and gcc3.2.3
config_test regresses for intel 7.1
Aleksey Gurtovoy wrote:
Aleksey Gurtovoy wrote:
David Abrahams wrote:
Misha and Aleksey -- I think we really need to distinguish those
failures from real regressions in the chart somehow or we'll never be
able to tell where we stand.
Here -
http://www.meta-comm.com/engineering/resources/cs-win32
Thomas Witt wrote:
Martin Wille wrote:
| David Abrahams wrote:
|
|
| The config_test regression was caused by not having linked against
| librt. I added these lines to intel-linux.jam on the RC_1_30_0 branch:
Just out of curiosity. What the heck is librt?
It contains the implementation of the
Hello,
a couple of libraries are regressing for gcc-2.95.3/Linux:
date_time
graph
iterator
multi_array
numeric/interval
numeric/ublas (only with stlport)
random
variant
Are those libraries supposed to support gcc-2.95?
Regards,
m
___
Un
Fernando Cacciola wrote:
David Abrahams <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
...
Well, 3.4 isn't even a released compiler so As far as I'm concerned
it doesn't count.
I added 3.4 only for informational purpose. There is no
point in actively support a compiler that is still un
David Abrahams wrote:
Martin Wille writes:
David Abrahams wrote:
It appears that the tagging step for Version_1_30_1 got messed up
somehow.
Please have a look at RC_1_30_2, which is our release candidate for
Version 1_30_2, and let me know if there are any problems.
I'm not able to ru
David Abrahams wrote:
Matthias Troyer <[EMAIL PROTECTED]> writes:
...
I would be interested in
hearing about the plans for a Boost 1.31 release
As far as I know the CVS is in very good health at the moment. The
only major thing I know needs to be done is to complete the
do
David Abrahams wrote:
Martin Wille writes:
David Abrahams wrote:
NOTICE:
If I don't hear of any new problems with the RC_1_30_0 branch I'm
going to release 1.30.2 tomorrow (Wed) evening or Thursday morning.
Not new: there are still some regressions for Linux:
crc_test regresses for
Martin Wille wrote:
If there is enough time left then I'll run the tests for
the 1.30.0 release and gcc-3.1.1. The chart for the
RC_1_30_0 branch should look better then.
Done. There are no regressions for gcc-3.3.1/Linux.
Regards,
m
___
Unsubs
Aleksey Gurtovoy wrote:
Martin Wille wrote:
The new reports are now checked into the main trunk and RC_1_30_0
branch.
Martin, if you are interested in upgrading to these, you would need to
re-generate the expected results file from the 1.30.0 tarball run - it
has
to contain more information to
David Abrahams wrote:
Martin Wille writes:
David Abrahams wrote:
In that case, can I release 1.30.2? I don't like having the 1.30.1
debacle hanging over my head.
There are new regressions on Linux (RC_1_30_0 branch):
http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1
Martin Wille wrote:
David Abrahams wrote:
Martin Wille writes:
The fix made to the gcc toolset regarding the use of the
GXX variable should be backported to 1_30_2.
Please be more specific, i.e. post a patchset.
If I had a patchset then I would have applied it :)
(I sent a bug report some
David Abrahams wrote:
Martin Wille writes:
David Abrahams wrote:
NOTICE:
If I don't hear of any new problems with the RC_1_30_0 branch I'm
going to release 1.30.2 tomorrow (Wed) evening or Thursday morning.
Not new: there are still some regressions for Linux:
crc_test regresses for
Beman Dawes wrote:
Assuming I'm release manager for 1.31.0, I'm going to publish explicit
release criteria for key platform/compiler pairs. Basically, the release
criteria will be 100% accounting for all failures on those
platform/compiler pairs.
I assume that Linux/GCC will be one of those pl
David Abrahams wrote:
Martin Wille writes:
Hello,
a couple of libraries are regressing for gcc-2.95.3/Linux:
date_time
graph
iterator
multi_array
numeric/interval
numeric/ublas (only with stlport)
random
variant
Are those libraries supposed to support gcc-2.95?
iterator is
David Abrahams wrote:
Martin Wille writes:
The fix made to the gcc toolset regarding the use of the
GXX variable should be backported to 1_30_2.
Please be more specific, i.e. post a patchset.
If I had a patchset then I would have applied it :)
(I sent a bug report some time ago to the
David Abrahams wrote:
It appears that the tagging step for Version_1_30_1 got messed up
somehow.
Please have a look at RC_1_30_2, which is our release candidate for
Version 1_30_2, and let me know if there are any problems.
I'm not able to run the Linux regression tests on that branch.
process_jam_
Thomas Witt wrote:
Vladimir Prus wrote:
| Reid Sweatman wrote:
|
| So, to summarize, I've no problem with the current name that I've
| introduced.
:-). Seriously having two functions that differ only by number is a
no-go to me.
| Of other suggestions "create_directory_and_parents" looks best
| to
Joel de Guzman wrote:
l.. Added missing include files to miniboost
For the records: that one doesn't apply to Boost 1.30.1.
Regards,
m
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Sujay Ghosh wrote:
Hello Users ,
I am new to Boost , and I would like to use it for my upcoming project.
I need to know whether Boost libraries is o/s dependent . How do I acheive
that , is there any preprocessor that does the neccessary, like
# ifdef _UNIX_
// do the necessary f
Aleksey Gurtovoy wrote:
Martin Wille writes:
I'll run the tests for Linux and upload them as Linux-rc-1.30.0.
They should be available in a few hours.
Can you arrange the html so that it shows regressions from the 1.30.0
release results?
Hmm, I'd have to find out how I would do that
Alisdair Meredith wrote:
Spirit has also just released its next version, should this also be
integrated into any boost 1.30.1?
Yes, Spirit 1.6.1 should be incorporated into a Boost 1.30.1
release (if we actually decide to release 1.30.1).
[I will ask same question on Spirit list, and direct discu
Markus Werle wrote:
There is something wrong with the config.
Obviously the code should use the
BOOST_MPL_AUX_VALUE_WKND(C)::value
but it seems the output of my configure run is not
included.
...
result of configure run (user.hpp):
...
//
// options added by configure:
//
#define BOOST_MSVC6_
Jens Maurer wrote:
It appears that the current tools/build/como-tools.jam is
not usable on Unix. For example, the linker action
causes "REM" lines to be passed to the Unix shell, which
does not work.
It looks to me that como-win32-tools.jam contains the Win32
configuration now, so I'd like to comp
John Maddock wrote:
Looking at the boost regression test results, it seems that Intel on linux
defines _WCHAR_T (which is what the EDG front-end documentation specifies
for wchar_t support), so I used that as the test - should be in cvs now -
can you check that it does the right thing?
integer_tra
Toon Knapen wrote:
The boost-sandbox is showing some strange behaviour.
When checking out the boost-sandbox/numeric/bindings/traits/type.h using
the :ext: server I get version 1.3 (on the HEAD), with :pserver: it's
only 1.2. The WebCVS also only shows up to version 1.2.
Could others with both :e
John Maddock wrote:
I found a problem with the intel configuration for Linux.
For that compiler the macro BOOST_NO_INTRINSIC_WCHAR_T
gets defined although the compiler has an intrinsic wchar_t.
Neither _WCHAR_T_DEFINED nor _NATIVE_WCHAR_T_DEFINED is
defined on Linux. __WCHAR_TYPE__ is defined to in
Hi,
I found a problem with the intel configuration for Linux.
For that compiler the macro BOOST_NO_INTRINSIC_WCHAR_T
gets defined although the compiler has an intrinsic wchar_t.
Neither _WCHAR_T_DEFINED nor _NATIVE_WCHAR_T_DEFINED is
defined on Linux. __WCHAR_TYPE__ is defined to int. Never-
thele
Hi,
the attached patch changes the order in which compilers are checked in
config/select_compiler.hpp. This is required to detect Comeau C++
with gcc backend correctly.
ok to apply?
Regards,
m
Index: select_compiler_config.hpp
===
RC
Hi,
I've found a little problem in boost_no_std_wstreambuf.cxx
The code uses std::ptrdiff_t but doesn't #include
I hesitated to add that #include because I don't know wether
all relevant compilers already support that.
With the current code, the results for Comeau C++ on Linux
are wrong.
Regards,
Douglas Paul Gregor wrote:
I would like a volunteer ...
I gave it a try:
- html: works like a charm.
- onehtml ditto
- pdf: lots of messages regarding missing "hyphenation pattern for
language en". A pdf file is created, however.
Is there a chance to specify a different paper size (e.g. A4)?
Hi,
the attached patch fixes a typo in
libs/test/doc/execution_monitor.htm.
Regards,
m
Index: execution_monitor.htm
===
RCS file: /cvsroot/boost/boost/libs/test/doc/execution_monitor.htm,v
retrieving revision 1.10
diff -u -r1.10 execu
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?
We have no "merged_to_1_30_0" tag in the CVS but a
"merged_to_RC_1_30_0" tag
Hi,
the attached patch fixes two typos in the release procedures document.
Regards,
m
Index: release_procedures.htm
===
RCS file: /cvsroot/boost/boost/more/release_procedures.htm,v
retrieving revision 1.5
diff -u -r1.5 release_proced
Hi,
I suggest to apply the attached patch to
libs/filesystem/build/Jamfile.v2
The patch adds "boost/filesystem" as project-id.
Regards,
m
Index: Jamfile.v2
===
RCS file: /cvsroot/boost/boost/libs/filesystem/build/Jamfile.v2,v
retriev
Joel de Guzman wrote:
> In the Macintosh, for example, the resource manager manages
"all* the resources in an application.
That is a bit misleading. The term "resource" has a special
meaning in the Macintosh world. The resource manager doesn't
manage window pointers or file handles for example.
Ot
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.
However, when Boost is incorporated to some other
Paul Mensonides wrote:
It *should* work fine now, though I haven't tested it. I had a pretty good
idea what the problem was.
It works fine now.
Thank you.
m
http://careers.yahoo.com.au - Yahoo! Careers
- 1,000's of jobs waiting online for you!
___
Aleksey Gurtovoy wrote:
...
> widget w2;
w.enable(boost::bind(&widget::is_enabled, &w2)); // here!
w2.enable(false);
assert(!w.is_enabled()) // !
}
Pure & beautiful, IMO.
Consider a widget class that performs some action on enabling/disabling
(like dimming a
Hello,
this little test program
#include
int main() { return 0; }
is compiled fine by gcc 2.95.3 and gcc 3.0.4.
However gcc 3.1/3.2 (and 3.3) produce errors:
In file included from /home/boost/boost/preprocessor/array.hpp:18,
from /home/boost/boost/preprocessor/library.hpp:17,
57 matches
Mail list logo
