On Sun, 16 Feb 2003 04:58:42 +0100, Aleksey Gurtovoy wrote:
Daniel Frey wrote:
[...]
Anyway, I would understand your frustration if you've proposed a drop-in
replacement for the current 'is_class' implementation that passes all
the current tests and is better, in at least one way, than
Hello,
may I know if anyone is maintaining the Boost heap
implementations? The email address of the original
author doesn't seem to exist anymore.
I still have not been able to determine if the
pointers returned by the heap are guaranteed to be
valid. The documentation does not say so. There is
One thing that bother me is the absence of BOOST_HAS_SIGACTION. I checked
and it seems that my sigaction-based signlal handling algorithm working
properly on this configuration, so I do not see a reasons why we could not
have above variable defined.
Someone will need to add an SCO specific
typedef test::remove_pointer int A::* ::type t1;
typedef test::remove_pointer int A::* const ::type t2;
typedef test::remove_pointer int A::* volatile ::type t3;
typedef test::remove_pointer int A::* const volatile ::type t4;
Those should not work: or maybe you want them to do
On Sun, 16 Feb 2003 03:12:13 +0100, Daniel Frey [EMAIL PROTECTED] wrote:
On Sun, 16 Feb 2003 01:14:17 +0100, David Abrahams wrote:
Daniel Frey [EMAIL PROTECTED] writes:
I won't try to fix any of these anymore. I neither understand the
documentation nor the implementation of boost's
I've been trying to build the thread test programs from status/Jamfile, but
they all fail to link because they can't find libboost_thread: I think the
problem may be that cygwin gcc can't link to an .so file directly but need
an .a file to be generated as well?
...found 1076 targets...
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 are still
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
John Maddock wrote:
typedef test::remove_pointer int A::* ::type t1;
typedef test::remove_pointer int A::* const ::type t2;
typedef test::remove_pointer int A::* volatile ::type t3;
typedef test::remove_pointer int A::* const volatile ::type t4;
Those should not work:
John Maddock wrote:
The basic point was (IMHO) never answered. I tried to clean up the
implementation by providing a closed implementation of is_class for more
compilers. This should decrease the coupling of all the different parts. I
think that this is a better design than the current
Gennaro Prota wrote:
More generally, cleaning up implementations is IMHO a must do at
this point of the boost evolution. Rather than worrying about ordinary
releases, I think we should have the library undergoing a global
review, focused on eliminating the noise that have been accumulating
Gennaro Prota [EMAIL PROTECTED] writes:
On Sat, 15 Feb 2003 12:00:36 -, John Maddock
[EMAIL PROTECTED] wrote:
Can't we detect
whether the compiler is supporting long long and only enable the
long long code under those circumstances? In fact, /don't/ we do
that?
If this is just about
Gennaro Prota [EMAIL PROTECTED] writes:
And lambda_support, in turn, includes so much preprocessor stuff that
I think it is more than what I would have in the whole application
hadn't I included is_integral.
Only on non-conforming compilers like vc6/7. On the rest,
lambda_support.hpp is
Beman Dawes [EMAIL PROTECTED] writes:
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.
Daniel Frey [EMAIL PROTECTED] writes:
On Sun, 16 Feb 2003 01:14:17 +0100, David Abrahams wrote:
Daniel Frey [EMAIL PROTECTED] writes:
I won't try to fix any of these anymore. I neither understand the
documentation nor the implementation of boost's type-traits. I tried to
make the code
Gennaro Prota [EMAIL PROTECTED] writes:
#include boost/type_traits/detail/bool_trait_def.hpp
I end up including:
- template_arity_spec.hpp
- bool_c.hpp
and
- lambda_support.hpp (!!!)
And lambda_support, in turn, includes so much preprocessor stuff that
I think it is more than
Daniel Frey [EMAIL PROTECTED] writes:
On Sun, 16 Feb 2003 04:58:42 +0100, Aleksey Gurtovoy wrote:
Daniel Frey wrote:
[...]
Anyway, I would understand your frustration if you've proposed a drop-in
replacement for the current 'is_class' implementation that passes all
the current tests and
John Maddock [EMAIL PROTECTED] writes:
I've been trying to build the thread test programs from status/Jamfile, but
they all fail to link because they can't find libboost_thread: I think the
problem may be that cygwin gcc can't link to an .so file directly but need
an .a file to be generated
David Abrahams wrote:
Daniel Frey [EMAIL PROTECTED] writes:
On Sun, 16 Feb 2003 04:58:42 +0100, Aleksey Gurtovoy wrote:
Daniel Frey wrote:
[...]
Anyway, I would understand your frustration if you've proposed a drop-in
replacement for the current 'is_class' implementation that
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.
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 in input section of run
rule.
The above tests expect
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 permanent fix.
There still are getenv link errors
Rozental, Gennadiy [EMAIL PROTECTED] writes:
Maybe I should do the factorization and put it in the sandbox or
boost::detail...
Looking forward to see that. Could you, please, let me know when you done or
if you need my help?
Sure. I'll try to do something this week.
optimization crop
test_fp_comparisons IS failing on all compilers for now. It shows some
problems with comparison alsorithm. I will take a closer look after
release.
Maybe you could take a quick look sooner? We aren't going to branch for
release until Monday, and the release won't happen for some time
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 crash in case if signal
handling is turned off.
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 try to look into this. What is the usual procedure
Daniel Frey [EMAIL PROTECTED] writes:
But I think that #ifdefs should only be the very last option.
Your philosophy goes against the one which says that breaking working
implementations should be the last option. I'm sorry, library
maintainers have an obligation to their users to keep the
[2003-02-16] David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
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
Gennadiy Rozental [EMAIL PROTECTED] writes:
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 in input
[2003-02-16] 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 crash in
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 in input section of
run
rule.
The above
See also the discussion about a general coding guideline to always
provide a name for template parameters. Here, the maintainer already
did the right thing when he received the patch.
If the maintainer hid the compiler brokenness completely, then they did
the wrong thing. If they didn't,
David Abrahams wrote:
Daniel Frey [EMAIL PROTECTED] writes:
See also the discussion about a general coding guideline to
always provide a name for template parameters.
I never saw that discussion.
http://www.mail-archive.com/boost%40lists.boost.org/msg05124.html
Here, the maintainer
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
Dave Gomboc wrote:
See also the discussion about a general coding guideline to always
provide a name for template parameters. Here, the maintainer already
did the right thing when he received the patch.
If the maintainer hid the compiler brokenness completely, then they did
the wrong
Daniel Frey [EMAIL PROTECTED] writes:
Often, granted. But the above patch (the link I gave) shows, that we
also have already evidence of #ifdefs that should be removed.
Actually, there is some argument for keeping the #ifdef there. HP is
currently working on fixing their compiler and using
David Abrahams wrote:
Well maybe we should start over. The way this whole thing started it
sounded like a lot of judgemental complaining about the current state
of the library without any willingness to bend your principles enough
to do something that was actually practical. Let me also
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
On Sun, 16 Feb 2003 12:45:30 +0100, John Maddock wrote:
typedef char t9[ !test::is_class int( int ) ::value ];
Generates warnings on gcc only, these have been reported and confirmed
as a gcc bug:
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-traildatabase=gccp
r=8503
Daniel Frey [EMAIL PROTECTED] writes:
David Abrahams wrote:
Well maybe we should start over. The way this whole thing started it
sounded like a lot of judgemental complaining about the current state
of the library without any willingness to bend your principles enough
to do something that
On Sun, 16 Feb 2003 12:45:30 +0100, John Maddock wrote:
typedef char t8[ test::is_convertible double, int ::value ];
That one issues a warning: for other compilers we are able to suppress
that, if you have any ideas on how to do so with gcc I'd be happy to
hear about it.
After looking
On Sun, 16 Feb 2003 22:52:52 +0100, David Abrahams wrote:
Are you saying that the current implementation of is_class is broken for
some compiler?
No. I think it was is_enum and I now have a patch for it, see my other
post. So, yes, I took the wrong approach when you want to see the
improvement
Daniel Frey [EMAIL PROTECTED] writes:
I agree. You'd have to be willing to use #ifdefs, though.
No reply to that?
Just when I thought we were getting somewhere!
My language was (again) choosen bad, sorry. I think we *are* getting
somewhere. :)
Whew!
it seems that I have a different
Daniel Frey [EMAIL PROTECTED] writes:
That's me. I think the problem is that otherwise is_convertible gets
instantiated on the type, and at the time the comment was written we
couldn't instantiate is_convertible on noncopyable types because it
required an accessible copy ctor. I think we
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
All -
Today is the start of the formal review of the Variant library
by Eric Friedman and Itay Maman. The review will run until
Tuesday Feb. 25th. I will be serving as review manager.
The variant library offers a simple, type-safe solution for
manipulating an object from an inhomogeneous set
All-
Jeff Garland wrote:
[snip]
You can obtain the latest version of the library from the
boost-sandbox or from:
http://groups.yahoo.com/group/boost/files/variant.zip
Please note that the version in the sandbox differs (sometimes
significantly) from the .zip in the files section. (The
On Saturday 15 February 2003 10:24 am, Beman Dawes wrote:
* signals lib is failing all Intel and Microsoft tests; as recently as a
few days ago the bulk of these were passing.
Should be fixed now. I forgot to tell the library to link statically for the
testcases.
Doug
-Original Message-
From: Jeff Garland [mailto:[EMAIL PROTECTED]]
I agree that multiplexing has to be in the design thoughts and
ultimately part of boost, but I worry it will be too much
to deliver, test, and review in the first pass. And,
I see no way I would use Boost.Socket for
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 when we near the release I will
provide a
Someone at HP has been testing against boost and has found a bug and
some workarounds for parts of the graph library. The message he sent
me is enclosed. His question about the validity of the boost sources
is clearly the result of a misunderstanding on the part of whoever is
implementing
54 matches
Mail list logo
