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 you have
> finished all commits.
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 you have
finished all commits.
I haven't really figured out when we will close off RC_1_
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> Should be:
>
> #if !BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x570)) \
> && !BOOST_WORKAROUND(__EDG_VERSION__, <= 238)
> // The EDG version number is a lower estimate.
> // It is no
--- "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote:
> I don't use -d0, but I don't see that **passed** message anywhere.
>
> Something else is not right: The other "fail" tests are only built once, but
> the as_to_python_function.cpp test is built each time I enter bjam again.
> That's why yo
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> --- David Abrahams <[EMAIL PROTECTED]> wrote:
>> It's easy enough to test it with a little program that prints the
>> value you have.
>
> OK, OK, OK, David. I know that MIPSpro == EDG 238, what I don't know is which
> EDG version fixes the p
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> It's easy enough to test it with a little program that prints the
> value you have.
OK, OK, OK, David. I know that MIPSpro == EDG 238, what I don't know is which
EDG version fixes the problem. Is this better?
Index: is_base_and_derived.hpp
=
Ralf W. Grosse-Kunstleve wrote:
> OK, I'll wait for a word from Aleksey. If he is happy I'll heck in
> the eight patches, both into the trunk and the RC_1_30_0 branch.
Yep, they all look good to me.
Aleksey
___
Unsubscribe & other changes: http://list
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> --- David Abrahams <[EMAIL PROTECTED]> wrote:
>> "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
>>
>> > David and Aleksey, could you please review the patches and tell
>> > me which are OK to check in? -- I am a bit worried about th
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
>
> > David and Aleksey, could you please review the patches and tell
> > me which are OK to check in? -- I am a bit worried about the
> > two patches in the mpl/aux_/preprocessed directory. Are
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> David and Aleksey, could you please review the patches and tell
> me which are OK to check in? -- I am a bit worried about the
> two patches in the mpl/aux_/preprocessed directory. Are these
> files auto-generated? Are there master files tha
--- Aleksey Gurtovoy <[EMAIL PROTECTED]> wrote:
> OK, I've checked in a fix into the main trunk (see
> "boost/mpl/aux_/lambda_support.hpp"). If you could check if it makes the
> problem go away, I'll integrate the new version into the release branch.
Thank you very much Aleksey! The error posted b
Aleksey Gurtovoy wrote:
> > If one of the developers could at least comment on this I might give it
> > another try. Otherwise I estimate it would take me weeks to
> > reverse-engineer what is happening here.
>
> Ralf, I will definitely look into it tonight and get back to you.
OK, I've checked i
Ralf W. Grosse-Kunstleve wrote:
> This requires active participation by the developers. We've spent a
> lot of time setting up the auto-builds to enable developers to see
> immediately when their changes break portability. We've also made a
> major effort cleaning up 1.29.0. That seemed like a g
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> I think it would be better to make the trunk work,
This requires active participation by the developers. We've spent a lot of time
setting up the auto-builds to enable developers to see immediately when their
changes break portability. We've also mad
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> --- David Abrahams <[EMAIL PROTECTED]> wrote:
>> "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
>>
>> > Is the __BORLANDC__ branch different from (not as good as) the
>> > is_base_and_derived implementation in 1.29.0?
>>
>> cvs dif
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
>
> > Is the __BORLANDC__ branch different from (not as good as) the
> > is_base_and_derived implementation in 1.29.0?
>
> cvs diff knows for sure.
Sure, but this "chasing tails" game is imprac
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> Is the __BORLANDC__ branch different from (not as good as) the
> is_base_and_derived implementation in 1.29.0?
cvs diff knows for sure.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
__
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> There are any number of ways you could try reformulating this to make
> the error go away. At worst you could try the __BORLANDC__ branch in
> is_base_and_derived.hpp.
>
> Another approach:
>
> template
> static type_traits::yes_type bd_he
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> Below is a stand-alone minimal test that still produces the same error message
> with MIPSpro:
>
> % CC -LANG:std zminmin.cpp
> cc-1108 CC: ERROR File = zminmin.cpp, Line = 13
> The indicated expression must have pointer-to-function type.
Below is a stand-alone minimal test that still produces the same error message
with MIPSpro:
% CC -LANG:std zminmin.cpp
cc-1108 CC: ERROR File = zminmin.cpp, Line = 13
The indicated expression must have pointer-to-function type.
static const unsigned long value = sizeof(bdhelper_t::check(
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> The MIPSpro problems are due to a hickup in is_base_and_derived.hpp.
> Here is the relevant *preprocessed* piece of code:
>
> template
> struct bd_helper
> {
> template
> static type_traits::yes_type check(D const volatile *, T);
>
The MIPSpro problems are due to a hickup in is_base_and_derived.hpp.
Here is the relevant *preprocessed* piece of code:
template
struct bd_helper
{
template
static type_traits::yes_type check(D const volatile *, T);
static type_traits::no_type check(B const volatile *, int);
};
tem
The regression tests (version 3) are running, and it may be a while
before they are done. In the meantime, the results of preprocessing the
file give more details of the error:
cc-1108 CC: ERROR File =
/mnt/vracs001/home9/users/patrick/src/Boost/boost-1.30.0-cvs/boost/type_traits/is_base_and_d
Patrick Hartling <[EMAIL PROTECTED]> writes:
> Is there a recommended procedure I can follow for tracking this down
> and submitting a patch?
I would start by preprocessing the file to see what's going on behind
that macro, then tweaking it until it works.
> For example, I was considering runn
I just grabbed the latest code from the RC_1_30_0 branch, and I got a
compile failure when building the Boost.Filesystem library with the
MIPSpro Compilers (7.3.1.3m):
mipspro-C++-action
../../../libs/filesystem/build/bin/libfs.a/mipspro/debug/exception.o
cc-1108 CC: ERROR File =
/mnt/vracs001
25 matches
Mail list logo
