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) extensively reworked and extended documentation,
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.
Definitely, and
Beman Dawes wrote:
One possible short-term fix might be to run the MPL tests separately,
and post them as a separate table.
That's what we plan to do, although format of the table probably going
to be different - please see below.
Long term, some kind of hierarchical approach might help with
Hi Andreas,
[...]
An attempt at an easy-to-use FSM library that supports
well-maintainable and code-expressive machines of almost any size and
does not require a code generator can be found in the fsm directories
in the boost-sandbox and here:
The formal review of Vladimir Prus' Command Line Config library is now at
an end. A summary and conclusion will follow shortly.
Thanks to everyone who responded,
Aleksey Gurtovoy
___
Unsubscribe other changes: http://lists.boost.org/mailman
to comment on
the final version.
Once again, thanks to the author and all the reviewers.
Aleksey Gurtovoy
Command Line Config Review Manager
[1]
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Program_Optio
ns_Library_Pages
Aleksey Gurtovoy wrote:
'int_' (and other integral constant wrappers) needs to provide a
definition
for its '::value' member for the
!defined(BOOST_NO_INCLASS_MEMBER_INITIALIZATION) case.
I will fix it in a few days.
Done in the main trunk now.
Aleksey
I just restored the lost revisions for these three headers:
boost/config/platform/win32.hpp
boost/config/stdlib/stlport.hpp
boost/filesystem/convenience.hpp
and, comparing what is probably the most recent before-the-disk-crash CVS
snapshot to the current CVS state, it seems that
Christopher Currie wrote:
While in theory I agree with Aleksey, I tried David's suggestion of
inhibiting in-class static constant initialization. This single change
eliminatated all but one of the remaining problems I've had compiling
the tests for type_traits (there's still an assertion
David Abrahams wrote:
the following fails to compile. Should it?
--
#include boost/mpl/vector.hpp
#include boost/mpl/push_back.hpp
namespace mpl = boost::mpl;
typedef mpl::vectorint[1], int[2], int[3], int[4], int[5], int[6],
int[7], int[8], int[9], int[10] v10;
typedef
Beman Dawes wrote:
... various backup suggestions
SourceForge already makes the entire Boost CVS tarball available every
night, and several Boosters download it daily.
Oh, good. There is no such thing as too much backup.
(At least I hope they do - I have no way of telling if they are
Ralf W. Grosse-Kunstleve wrote:
While compiling certain Boost.Python regression tests (e.g. args.cpp) gcc
3.3
complains about some typedefs being private. Attached is a trivial patch
which
fixes the problem. OK to commit to CVS?
Yep, the patch is OK - gcc is right, and there is no point in
[EMAIL PROTECTED] (Greg Comeau) wrote:
On a more general note... what are the regression results for?
Who is supposed to be their readers?
What information is one supposed to gleam from perusing them?
What should one walk away from them knowing or saying?
FWIW, I tried to answer these here -
... as per http://article.gmane.org/gmane.comp.lib.boost.devel/20648 are
available from here:
* user summary page -
http://boost.sourceforge.net/regression-logs/user_summary_page.html
* developer summary page -
http://boost.sourceforge.net/regression-logs/developer_summary_page.html
Please
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
... as per http://article.gmane.org/gmane.comp.lib.boost.devel/20648
are available from here:
* user summary page -
http://boost.sourceforge.net/regression-logs/user_summary_page.html
* developer summary page -
http
Gennaro Prota wrote:
On Wed, 18 Jun 2003 10:01:58 -0500, Aleksey Gurtovoy
[EMAIL PROTECTED] wrote:
... as per http://article.gmane.org/gmane.comp.lib.boost.devel/20648
are available from here:
* user summary page -
http://boost.sourceforge.net/regression-logs/user_summary_page.html
Vladimir Prus wrote:
Aleksey Gurtovoy wrote:
... as per
http://article.gmane.org/gmane.comp.lib.boost.devel/20648 are
available from here:
* user summary page -
http://boost.sourceforge.net/regression-logs/user_summary_page.html
* developer summary page -
http
Rene Rivera wrote:
[2003-06-18] Aleksey Gurtovoy wrote:
as per
http://article.gmane.org/gmane.comp.lib.boost.devel/20648 are
available from here:
* user summary page -
http://boost.sourceforge.net/regression-logs/user_summary_page.html
* developer summary page -
http
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
Peter Dimov wrote:
The summaries are nice, but the red broken thing on the user page
may be too intimidating,
When will show the actual status, it shouldn't be (it doesn't yet,
since some cooperation from library authors is needed - please
David Abrahams wrote:
AFAICT, Aleksey is the only one who knows how to make
modifications
to MPL correctly in the context of its preprocessing
system. Aleksey,
a short README would totally solve this problem, wouldn't it?
How about this one instead:
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
Well, check out the latest developer report -
http://boost.sourceforge.net/regression-logs/developer_summary
_page.html!
Intel-7.1 is misconfigured. ADL is disabled but
BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is not set. That is why
Peter Dimov wrote:
We just need to agree on the configuration, here. Currently, we run
Intel 7.1 in MSVC 6.0 compatibility mode, and Beman probably has his
configured for 7.0. I am not sure which configuration is more common
in the real world - assuming that this is the criterion we want
Beman Dawes wrote:
The other possibility is that Intel changed something in their 7.1
update. I'm planning to install that update in a day or two; we'll
see if it breaks the Win32 regression tests.
We upgraded to 7.1 a couple of days ago, so
Peter Dimov wrote:
Beman's approach, where unexpected failures were automatically
determined by comparing the current run with aprevious run, seems to
cope better with this scenario, and requires no manual input.
Does it? What if the previous run was a total failure - what the next
one is
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
Peter Dimov wrote:
Also, please note that I don't mind the _developer summary_ being
aggressive in its pass/fail reports. There are no expected
failures there as far as I'm concerned. Every failure needs to be
reported in red, with pass-fail
Drazen DOTLIC wrote:
Hi,
Hi Drazen,
My company is using boost and we would very much like to use variant
library immediately and not wait for the next official release of
boost. Now, we know that this might not be sensible, but we are ready
to take the risk. At the same time, we don't want
Daniel Frey wrote:
To complete the implementation of combined_argument_type, it would
help if mpl::vector would have 16 instead of 10 arguments,
Just do #include boost/mpl/vector/vector20.hpp and use 'vector16'.
Aleksey
___
Unsubscribe other
Daniel Frey wrote:
Peter Dimov wrote:
You've considered
bind(f, bind(g, _1, _2), bind(h, _1, _2))
right? ;-)
Sure. But still compose.hpp is in itself incomplete. And it completes
the standard's parts on function objects so I think it might be
desirable to supply
Thomas Wenisch wrote:
Hi,
Hi Thomas,
First of all, thanks for the report.
for_each seems to be unable to deal with empty lists, or lists that
are built by push_front on an empty list. However, vectors work
fine. Here is code which demonstrates the problem. Replacing list with
vector
Markus Werle wrote:
Hi!
Hi Markus,
Though Intel C++ compiles this without complaint
gcc fails with ICE on this code snippet, which is
preprocessor output of boost code:
struct void_ {};
template
bool C
, typename T1
, typename T2
struct if_c
{
typedef T1
David Abrahams wrote:
That's because void_ is for MPL internal use only; it's not a type
you should manipulate
While I agree that _some_ user needs for a special unique type a
better handled by introducing a new one (otherwise you'll get yourself
into situation like we have right now, only in
David Abrahams wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
IMO we should just stop using 'void_' for internal purposes and give it
up to users :).
I am still unsure about 'void_' being better than 'nil' or
'null' Users already have a type, 'void', which means void
Hi Eric,
First of all, thanks for the report!
Eric Friedman wrote:
I've found that mpl::is_sequence fails to operate correctly on
certain types under MSVC7.
To be precise, on class types that have a member named 'begin' that is
not a typename.
I haven't tested extensively, but there
Eric Friedman wrote:
Aleksey (and all),
In working on porting boost::variant to Borland, I've come across some
trouble with a bug in the compiler.
Specfically, I'm getting Cannot have both a template class and
function named 'bind1st' and similarly for bind2nd. I know other MPL
headers
David Abrahams wrote:
Eric Friedman [EMAIL PROTECTED] writes:
I'd apply the patch myself, but due to the heavy use of preprocessed
headers, I'm worried I won't get it completely right. So I'll leave
it up to Aleksey (or others) to fix.
AFAICT, Aleksey is the only one who knows how to
Eric Friedman wrote:
Aleksey (and others),
Hi Eric,
I'm working on getting variant to compile under MSVC 6, but I've come
across what seems to be an ETI problem that needs a workaround.
However, I'm not sure what is the most appropriate way to make the fix.
The most common way to deal with
Drazen DOTLIC wrote:
Hello,
Hi Drazen,
I've recently discovered that mpl provides all the functionality
I was previously using from loki, so I decided to switch. There
is one small thing driving me crazy, and I was wondering if I
missed something...
I was using loki's TypeAtNonStrict
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. Is there already
some
Beman Dawes wrote:
At 04:54 PM 7/16/2003, David Abrahams wrote:
Martin Wille [EMAIL PROTECTED] writes:
Hmm, I'd have to find out how I would do that. Is there already
some support for showing diffs between two versions of the test
result tables?
Yes. Beman?
I have a hack that
Misha Bergal wrote:
Here are the results we have:
1.30.0 tarball: http://tinyurl.com/h6cx
CVS main trunk (relative to 1.30.0 tarball): http://tinyurl.com/h6d0
CVS RC_1_30_0 branch (relative to 1.30.0 tarball):
http://tinyurl.com/h6d7
(will be available in 9 hours)
CVS RC_1_30_0
David Abrahams wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
Any reason you cannot use
http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_summary_page.html?
None, in particular. This table is a little weird though:
http://www.meta-comm.com/engineering/resources
David Abrahams wrote:
I have put a diff of the changes between Version_1_30_0 and RC_1_30_0
at http://www.boost-consulting.com/diffs-1-30-1.txt. These will be
the changes that go into the Boost 1.30.1 release. Will the
authors/maintainers of the following libraries please post a brief
David Abrahams wrote:
Here's an example I just cooked up of using the PP lib to solve a
classic C++ OO problem: repeated boilerplate in the definition of
Pimpl classes.
There is another variation of the idiom, sometimes called hidden state,
which doesn't have the shortcoming in the first
Fernando Cacciola wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] escribió en el mensaje
news:[EMAIL PROTECTED]
David Abrahams wrote:
Here's an example I just cooked up of using the PP lib to solve a
classic C++ OO problem: repeated boilerplate in the definition of
Pimpl classes
David Abrahams wrote:
Paul Mensonides [EMAIL PROTECTED] writes:
Aleksey Gurtovoy wrote:
David Abrahams wrote:
Here's an example I just cooked up of using the PP lib to solve a
classic C++ OO problem: repeated boilerplate in the definition of
Pimpl classes.
There is another
David Abrahams wrote:
Thanks for all the testing; the release looks pretty darned great!
Just to make sure it's understood - although expected, all the green
failures are still failures. Not that we can do much about them, of course.
From a user POV, a darned great release would be the one for
Brian Simpson wrote:
The implementation reasoning runs like this: It seems that the problem
with
building a switch statement to implement type selection is that a switch
statement can't be built incrementally--it is a syntactic construct. (The
currently accepted solution builds an
David Abrahams wrote:
Matthias Troyer [EMAIL PROTECTED] writes:
Dear Boosters,
Since some of the applications and libraries we plan on releasing soon
rely on Boost features and bugfixes that are in the CVS but not in
Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0
David Abrahams wrote:
As far as I know the CVS is in very good health at the moment.
Uhmm, I really wouldn't say so! If you look at the main trunk report -
http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html,
there are lots of regressions comparing
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
Consider the following snippet:
void show_warning( message_dialog const, user_message );
void post_command( boost::functionvoid() );
int main()
{
boost::functionvoid( user_message ) f(
bind
Beman Dawes wrote:
At 07:37 AM 8/11/2003, David Abrahams wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
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
criteria
Alisdair Meredith wrote:
Aleksey Gurtovoy wrote:
While I totally support the failures markup goal, I would like to see
_the_ release criteria to include no regressions from the previous
release item as well, preferrably for all non-beta compilers that are
currently under regression
David Abrahams wrote:
Here -
http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/developer_summary_page.html
Yellow cells indicate failures on the newly added tests/compilers. The
updated report tools are not in the CVS yet, we will check them in after
the
first round of
Consider the following snippet:
void show_warning( message_dialog const, user_message );
void post_command( boost::functionvoid() );
int main()
{
boost::functionvoid( user_message ) f(
bind( post_command
, ( bind( show_warning,
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
There is another variation of the idiom, sometimes called hidden
state, which doesn't have the shortcoming in the first place:
class foo
{
public:
foo();
foo(int);
int f() const;
void g
David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
For a lightly used toolset like intel-7.1 with STLPort, looks for all
the world like a config problem seems like a good enough resolution
to me.
In that case, can I release 1.30.2? I don't like having the 1.30.1
debacle hanging
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
criteria will be 100% accounting for all failures on those
platform/compiler pairs.
While I totally support the failures markup goal, I
David Abrahams wrote:
Regarding http://tinyurl.com/jhtn: does this compiler ever need the
typename keyword? If not, perhaps we ought to define
BOOST_NO_DEDUCED_TYPENAME for all Borland versions
Any particular failure that triggered your attention?
Aleksey
David Abrahams wrote:
Martin Wille [EMAIL PROTECTED] 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):
David Abrahams wrote:
Many are simply not going to get better; they're due to compiler bugs
which can't be worked around.
Which is totally fine. If you provide us with the list of expected
failures, these will be cleared.
All of the *_fail tests that are failing should be cleared.
Beman Dawes wrote:
(I still haven't gotten over Microsoft being the
first compiler to pass 100%. The world takes some strange twists
sometimes.)
Well, it's not like this happened by an accident, is it? It's been
explicitly stated that they are committed to this goal, and they made it
Rene Rivera wrote:
[2003-08-11] David Abrahams wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
Well, sure, as long as we are in agreement about having differently
named toolsets for different compiler versions/configurations, e.g.
bcc-5.5.1
bcc-5.6.4
intel-7.1-vc60
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.
Well, it was assumed that when adding a new compiler one should use
re-run
the regressions against
David Abrahams wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
I worry a little about requiring library authors not to regress on
compiler combinations they don't test with.
Well, the regressions are run daily, so testing happens. Another
question is whether library authors care
Beman Dawes wrote:
At 05:12 AM 8/11/2003, Alisdair Meredith wrote:
Aleksey Gurtovoy wrote:
While I totally support the failures markup goal, I would like to see
_the_ release criteria to include no regressions from the previous
release item as well, preferrably for all non-beta
David Abrahams wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
Aleksey Gurtovoy wrote:
David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
For a lightly used toolset like intel-7.1 with STLPort, looks for
all
the world like a config problem seems like a good enough
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 support the new
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_metacomm/developer_summary_page.html
Yellow
Aleksey Gurtovoy wrote:
David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
For a lightly used toolset like intel-7.1 with STLPort, looks for all
the world like a config problem seems like a good enough resolution
to me.
In that case, can I release 1.30.2? I don't like
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_metacomm
Beman Dawes wrote:
At 11:13 PM 8/10/2003, Aleksey Gurtovoy wrote:
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
criteria will be 100% accounting for all failures on those
David Abrahams wrote:
Douglas Paul Gregor [EMAIL PROTECTED] writes:
On Mon, 11 Aug 2003, David Abrahams wrote:
According to your chart, the following libraries are all regressing:
function
Are these real regressions or just newly-tested compilers? Can the
library
David B. Held wrote:
Hmm...ok, I'm not getting anywhere talking about it abstractly, so
I'll just say that I'm trying to figure out how to improve the policy
adaptor interface for smart_ptr. In particular, I would like to go
from this:
smart_ptrint, my_policy_, my_other_policy_ p;
to
Misha Bergal wrote:
Our results are available now.
Looking at it:
* static_assert library name got somehow replaced with libs.
This one is really nasty. We tracked it down, and it's caused by yesterday
changes in testing.jam:
RCS file: /cvsroot/boost/boost/tools/build/testing.jam,v
David Abrahams wrote:
Great! Here's a summary of my changes:
Boost Consulting is now hosting Boost CVS mirrors. See
http://www.boost.org/more/download.html
Bugs in regression reporting in subproject tests were fixed.
Tests are now run in the context of the user's PATH
For everyone's information, here's the status of 1.30.2 release preparation.
Current status:
Two outstanding problems with the win32 regressions (accidentally revealed
bug in testing.jam + unexpected failures for the intel-stlport
configuration) have been fixed. Consequently, as at this moment,
Martin Wille wrote:
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.
Perfect
101 - 177 of 177 matches
Mail list logo
