Few questions: * BGD-Ubuntu is among tested platforms for release, but not for trunk. How is a poor fellow supposed to test on trunk first? * Same as above for BGD-Windows, with the fellow getting poorer and poorer * Are RW_WinXP_VC and RW_WinXP_VCrtl the same? * Can anyone please have a look at the trunk failures for HP-UX_ia64_aCC? For a bunch of libraries I've looked at it gives an Unsatisfied symbol "boost::exception_detail::refcount_ptr<..." What's that? Compiler bug, misconfiguration, phase of the moon? Sorry, but if this is the status quo I'm just going to merge to branches/release and be done with it. -- Genny
On Mon, Sep 8, 2008 at 5:12 PM, Gennaro Prota <gennaro.prota@yahoo.com> wrote:
Unsatisfied symbol "boost::exception_detail::refcount_ptr<..."
This is my fault thanks for spotting it. I'm looking into it right now. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Mon, Sep 8, 2008 at 5:33 PM, Emil Dotchevski <emil@revergestudios.com> wrote:
On Mon, Sep 8, 2008 at 5:12 PM, Gennaro Prota <gennaro.prota@yahoo.com> wrote:
Unsatisfied symbol "boost::exception_detail::refcount_ptr<..."
This is my fault thanks for spotting it. I'm looking into it right now.
This is a weird link error, but the "missing" destructor is inline. It seems to be a build problem specific to the HP-UX_ia64_aCC test site. The relevant change was introduced in revision 48634. This revision has been tested, and has not caused any problems, on any other test sites. I'm noticing that the HP-UX_ia64_aCC test is incremental. I have seen similar failures before which were "fixed" by a non-incremental build. Rather than panicking, I suggest trying a non-incremental build for a single failing test, to verify this theory, and if it works out, investigating why the error occurred in the first place. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Mon, Sep 8, 2008 at 5:33 PM, Emil Dotchevski <emil@revergestudios.com> wrote:
On Mon, Sep 8, 2008 at 5:12 PM, Gennaro Prota <gennaro.prota@yahoo.com> wrote:
Unsatisfied symbol "boost::exception_detail::refcount_ptr<..." This is my fault thanks for spotting it. I'm looking into it right now.
This is a weird link error, but the "missing" destructor is inline.
It's also the destructor of a class that should have nothing to do with dynamic_bitset (but who knows... it might be used by something used by something used by something else; the joys of Boost coupling)
It seems to be a build problem specific to the HP-UX_ia64_aCC test site. The relevant change was introduced in revision 48634. This revision has been tested, and has not caused any problems, on any other test sites.
I'm noticing that the HP-UX_ia64_aCC test is incremental. I have seen similar failures before which were "fixed" by a non-incremental build.
Rather than panicking, I suggest trying a non-incremental build
Are you suggesting that to me? If I had a HP-UX_ia64_aCC I wouldn't even bother looking at the test reports. -- Genny
Gennaro Prota wrote:
Are you suggesting that to me? If I had a HP-UX_ia64_aCC I wouldn't even bother looking at the test reports.
At Emil's request, I've started a full test. Just FYI. -boris
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennaro Prota Sent: Monday, September 08, 2008 9:30 PM To: boost@lists.boost.org Subject: Re: [boost] Tests are a mess
Emil Dotchevski wrote:
On Mon, Sep 8, 2008 at 5:33 PM, Emil Dotchevski <emil@revergestudios.com> wrote:
On Mon, Sep 8, 2008 at 5:12 PM, Gennaro Prota <gennaro.prota@yahoo.com> wrote:
Unsatisfied symbol "boost::exception_detail::refcount_ptr<..." This is my fault thanks for spotting it. I'm looking into it right now.
This is a weird link error, but the "missing" destructor is inline.
It's also the destructor of a class that should have nothing to do with dynamic_bitset (but who knows... it might be used by something used by something used by something else; the joys of Boost coupling)
It seems to be a build problem specific to the HP-UX_ia64_aCC test site. The relevant change was introduced in revision 48634. This revision has been tested, and has not caused any problems, on any other test sites.
I'm noticing that the HP-UX_ia64_aCC test is incremental. I have seen similar failures before which were "fixed" by a non-incremental build.
Rather than panicking, I suggest trying a non-incremental build
Are you suggesting that to me? If I had a HP-UX_ia64_aCC I wouldn't even bother looking at the test reports.
-- Genny
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Sep 8, 2008 at 6:34 PM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
Gennaro Prota wrote:
Are you suggesting that to me? If I had a HP-UX_ia64_aCC I wouldn't even bother looking at the test reports.
At Emil's request, I've started a full test. Just FYI.
Thanks Boris! Furiously clicking the refresh button in firefox now... :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
The tests are still running now, but there are ld: Unsatisfied symbol "boost::exception_detail::refcount_ptr<boost::exception_detail::error_info_container>::~refcount_ptr()(complete)" error messages in bjam.log. Boris
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Emil Dotchevski Sent: Monday, September 08, 2008 9:41 PM To: boost@lists.boost.org Subject: Re: [boost] Tests are a mess
On Mon, Sep 8, 2008 at 6:34 PM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
Gennaro Prota wrote:
Are you suggesting that to me? If I had a HP-UX_ia64_aCC I wouldn't even bother looking at the test reports.
At Emil's request, I've started a full test. Just FYI.
Thanks Boris!
Furiously clicking the refresh button in firefox now... :)
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Sep 9, 2008 at 5:39 AM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
The tests are still running now, but there are
ld: Unsatisfied symbol "boost::exception_detail::refcount_ptr<boost::exception_detail::error_info_container>::~refcount_ptr()(complete)"
Yep, I see it. Any ideas what might be causing this link error? I'm completely puzzled because the "missing" destructor (of boost::exception_detail::refcount_ptr) is right there, inline in the same file (boost/exception/exception.hpp) with class boost::exception, which is the only user of refcount_ptr... Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
Any ideas what might be causing this link error?
No idea. I'll investigate and get back to you. Thanks, Boris
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Emil Dotchevski Sent: Tuesday, September 09, 2008 1:54 PM To: boost@lists.boost.org Subject: Re: [boost] Tests are a mess
On Tue, Sep 9, 2008 at 5:39 AM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
The tests are still running now, but there are
ld: Unsatisfied symbol "boost::exception_detail::refcount_ptr<boost::exception_detail ::error_info_container>::~refcount_ptr()(complete)"
Yep, I see it.
Any ideas what might be causing this link error? I'm completely puzzled because the "missing" destructor (of boost::exception_detail::refcount_ptr) is right there, inline in the same file (boost/exception/exception.hpp) with class boost::exception, which is the only user of refcount_ptr...
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Sep 9, 2008 at 10:59 AM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
Emil Dotchevski wrote:
Any ideas what might be causing this link error?
No idea. I'll investigate and get back to you.
Boris, Thanks for looking into this! Here is some more info that you might find helpful: The refcount_ptr class template is just that, a simple reference counting pointer. The only instance of the template is found on line 229 in boost/exception/exception.hpp: refcount_ptr<exception_detail::error_info_container> data_; which is a member of boost::exception. The error_info_container type is abstract and it is defined in the same header file. There are friends of boost::exception that refer to data_, in exception/get_error_info.hpp, exception/info.hpp, and exception/diagnostic_information.hpp. The only thing that calls ~refcount_ptr() is the destructor of class boost::exception, which is pure virtual. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Sep 9, 2008 at 10:59 AM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
Emil Dotchevski wrote:
Any ideas what might be causing this link error?
No idea. I'll investigate and get back to you.
Boris, Peter Dimov advises me that the problem could go away if the boost::exception::~exception() destructor from exception/exception.hpp is not pure virtual. Could you please apply the attached patch and try to run a single test, perhaps the get_deleter_test.cpp from the smartptr test suite? If this fixes it, then I can do a workaround for this particular platform. Thanks, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil, I'll do it shortly. Thanks for the patch! Boris
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Emil Dotchevski Sent: Tuesday, September 09, 2008 6:28 PM To: boost@lists.boost.org Subject: Re: [boost] Tests are a mess
On Tue, Sep 9, 2008 at 10:59 AM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
Emil Dotchevski wrote:
Any ideas what might be causing this link error?
No idea. I'll investigate and get back to you.
Boris,
Peter Dimov advises me that the problem could go away if the boost::exception::~exception() destructor from exception/exception.hpp is not pure virtual. Could you please apply the attached patch and try to run a single test, perhaps the get_deleter_test.cpp from the smartptr test suite?
If this fixes it, then I can do a workaround for this particular platform.
Thanks,
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil, with the patch, get_deleter_test links cleanly and succeeds: bash-2.03$ aCC -DBOOST_ALL_NO_LIB=1 +d -g -I.. ../libs/smart_ptr/test/get_deleter_test.cpp +DD64 \
&& a.out No errors detected. bash-2.03$
I think, you can apply the patch. If you want to make it aC++ - specific, you can conditionalize it based on __HP_aCC macro. Thanks for looking at this! -boris
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Gubenko, Boris Sent: Tuesday, September 09, 2008 6:42 PM To: boost@lists.boost.org Subject: Re: [boost] Tests are a mess
Emil,
I'll do it shortly. Thanks for the patch!
Boris
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Emil Dotchevski Sent: Tuesday, September 09, 2008 6:28 PM To: boost@lists.boost.org Subject: Re: [boost] Tests are a mess
On Tue, Sep 9, 2008 at 10:59 AM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
Emil Dotchevski wrote:
Any ideas what might be causing this link error?
No idea. I'll investigate and get back to you.
Boris,
Peter Dimov advises me that the problem could go away if the boost::exception::~exception() destructor from exception/exception.hpp is not pure virtual. Could you please apply the attached patch and try to run a single test, perhaps the get_deleter_test.cpp from the smartptr test suite?
If this fixes it, then I can do a workaround for this particular platform.
Thanks,
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Sep 9, 2008 at 4:02 PM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
Emil,
with the patch, get_deleter_test links cleanly and succeeds:
Boris, Thanks for helping me troubleshoot this issue. Also thanks to Peter Dimov for suggesting the workaround. Revision 48690 should take care of it. It appears to be a bug in the compiler, it seems to incorrectly assume that the boost::exception_detail::refcount_ptr destructor is not needed if the destructor of the containing class, boost::exception, is pure virtual, which later triggers a link error. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
It appears to be a bug in the compiler
It is possible. I've filed CR QXCR1000850520 for this issue. Thanks for looking into this and a workaround! -boris
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Emil Dotchevski Sent: Tuesday, September 09, 2008 7:53 PM To: boost@lists.boost.org Subject: Re: [boost] Tests are a mess
On Tue, Sep 9, 2008 at 4:02 PM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
Emil,
with the patch, get_deleter_test links cleanly and succeeds:
Boris,
Thanks for helping me troubleshoot this issue. Also thanks to Peter Dimov for suggesting the workaround.
Revision 48690 should take care of it. It appears to be a bug in the compiler, it seems to incorrectly assume that the boost::exception_detail::refcount_ptr destructor is not needed if the destructor of the containing class, boost::exception, is pure virtual, which later triggers a link error.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Emil Dotchevski wrote:
It appears to be a bug in the compiler, [...]
Yes, it turned out to be a bug in the compiler, related to +d option (disable inlining). x.cpp ----- struct refcount_ptr { ~refcount_ptr() {} }; struct exception { virtual ~exception() = 0; refcount_ptr data_; }; inline exception::~exception() {} struct S : exception {}; inline void foo( S const & ) {} inline void bar() { foo( S() ); } int main() {} bash-2.03$ aCC +d x.cpp ld: Unsatisfied symbol "refcount_ptr::~refcount_ptr()(complete)" in file x.o 1 errors. bash-2.03$ aCC x.cpp bash-2.03$ Thanks again for adding a workaround for this issue. Boris
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Emil Dotchevski Sent: Tuesday, September 09, 2008 7:53 PM To: boost@lists.boost.org Subject: Re: [boost] Tests are a mess
On Tue, Sep 9, 2008 at 4:02 PM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
Emil,
with the patch, get_deleter_test links cleanly and succeeds:
Boris,
Thanks for helping me troubleshoot this issue. Also thanks to Peter Dimov for suggesting the workaround.
Revision 48690 should take care of it. It appears to be a bug in the compiler, it seems to incorrectly assume that the boost::exception_detail::refcount_ptr destructor is not needed if the destructor of the containing class, boost::exception, is pure virtual, which later triggers a link error.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Emil Dotchevski wrote:
On Tue, Sep 9, 2008 at 10:59 AM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
Emil Dotchevski wrote:
Any ideas what might be causing this link error?
No idea. I'll investigate and get back to you.
Boris,
Peter Dimov advises me that the problem could go away if the boost::exception::~exception() destructor from exception/exception.hpp is not pure virtual.
[snip] I believe I've seen something similar. I think you can work around this by providing an inlined, empty, body for the pure virtual dtor. Just make sure that this no-op dtor is defined _outside_ the class declaration, e.g.: struct foo { virtual ~foo() = 0; }; inline foo::~foo() {} Apologies if this is not applicable to your problem; I haven't read through all of the posts. / Johan
On Tue, Sep 9, 2008 at 11:36 PM, Johan Nilsson <r.johan.nilsson@gmail.com> wrote:
struct foo { virtual ~foo() = 0; };
inline foo::~foo() {}
Yes, that's what I was doing. Regardless, that particular compiler seems to erroneously discard the inline destructor definition, and then the linker complains that it's missing. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Tue, Sep 9, 2008 at 11:36 PM, Johan Nilsson <r.johan.nilsson@gmail.com> wrote:
struct foo { virtual ~foo() = 0; };
inline foo::~foo() {}
Yes, that's what I was doing. Regardless, that particular compiler seems to erroneously discard the inline destructor definition, and then the linker complains that it's missing.
Out of curiosity --as I really don't intend to waste one more minute on it-- is Test.Minimal using all this loathsomeness? -- Genny
On Wed, Sep 10, 2008 at 1:43 AM, Gennaro Prota <gennaro.prota@yahoo.com> wrote:
Out of curiosity --as I really don't intend to waste one more minute on it-- is Test.Minimal using all this loathsomeness?
It seems that it doesn't. The code in question, about 400 lines at present, is fully contained in boost/exception/exception.hpp and as of 1.36 is included in boost/throw_exception.hpp. The purpose of this coupling is to provide hooks to support boost::current_exception and the ability for users to augment active exception objects with additional (possibly user-specific) info not available at the point of the throw. If anyone is concerned about this coupling I encourage them to participate in the discussion on this very subject going on right now (hopefully after familiarizing themselves with the exception library.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Wed, Sep 10, 2008 at 1:43 AM, Gennaro Prota <gennaro.prota@yahoo.com> wrote:
Out of curiosity --as I really don't intend to waste one more minute on it-- is Test.Minimal using all this loathsomeness?
It seems that it doesn't. The code in question, about 400 lines at present, is fully contained in boost/exception/exception.hpp and as of 1.36 is included in boost/throw_exception.hpp. The purpose of this coupling is to provide hooks to support boost::current_exception and the ability for users to augment active exception objects with additional (possibly user-specific) info not available at the point of the throw.
If anyone is concerned about this coupling I encourage them to participate in the discussion on this very subject going on right now (hopefully after familiarizing themselves with the exception library.)
Nah, I'm not concerned about that, really. At least not specifically. I find it awful that, in a library that --believe me-- I know from the first to the last line of code, I have no idea of what gets included from the lower levels. Putting the Cassandra-hat on, I advise you not to start any discussion. It will be discussed ad infinitum without any useful consequence on code. The #include<> vs. #include"" issue was beaten to death in the past, for instance. To the point that it led to core issue 370; committee time wasted on it, and the obvious advice/conclusion from them. Still, no change in boost code. Another example? "Optimizing" operator=. With all the problems that Boost has. BTW, you were the only one who noticed that test reports were not working, so please don't assume I was attacking you. -- Genny
Library A depend on Library B. Some applications depend on library B. Library B is a very simple facility with a clearly defined purpose. That purpose is to permit programs and other libraries to write code which will work accross a variety of platforms. Now Library B is changed to add a bunch of new features and/or facilities. Library B now has a whole new purpose - to provide new features and facilities. How does this in any way benefit the users of the original version of library B? The are still using the library for the original purpose. This may or may not conflict with the new version of library B. Its claimed that the new version offers the original purpose. But this isn't obvious from looking at the code and/or documentation. The fact that the original version was maybe 30 lines and the new one is now 400 lines (at a minimum) and seems to depend on some new compile time switches, certainly suggests that that its not equivalent to the original version. When users complain that they to have time to re-visit all their old applications /libraries to verify that the new version is equivalent, users are library B are encouraged to study the documentation of the new version lf library B to discover what it does and how it will benefit them. It's unbelievable to me that this situation a) this even occured in the first place b) that this has persisted to this point. I don't know anything about the new exceptions library. How good is is or isn't, what it does, etc are not relevant. If you want to create a new throw exception with great new features that's just fine. But don't go foisting on me a whole new layer of work that I don't have time for - give it a different name. I haven't touched on breaking tests, portability, etc - as they are beside the point at this point. Robert Ramey
On Wed, Sep 10, 2008 at 12:10 PM, Robert Ramey <ramey@rrsd.com> wrote:
Library A depend on Library B. Some applications depend on library B.
Library B is a very simple facility with a clearly defined purpose. That purpose is to permit programs and other libraries to write code which will work accross a variety of platforms.
Now Library B is changed to add a bunch of new features and/or facilities. Library B now has a whole new purpose - to provide new features and facilities.
How does this in any way benefit the users of the original version of library B?
I was going to explain these benefits but then I read your post further.
I don't know anything about the new exceptions library. How good is is or isn't, what it does, etc are not relevant. If you want to create a new throw exception with great new features that's just fine. But don't go foisting on me a whole new layer of work that I don't have time for - give it a different name.
In fairness, if anyone is being foisted on a whole new layer of work, that's mostly me. I understand your frustration. But since you don't want to spend the time to understand the benefits for the end user (including users of Boost Serialization), I'm wondering how we can continue this discussion. In your mind, the situation is: no benefits - it's not worth it - I don't trust 400 lines of code that I don't understand and don't care about. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Robert Ramey wrote:
[..] But don't go foisting on me a whole new layer of work [...]
Sadly, by introducing boost::serialization::throw_exception, you have foisted work on me and other users of your library. Now we have to implement boost::serialization::throw_exception instead of just having one boost::throw_exception. This is exactly the kind of breakage you've been so strongly opposed to.
On Wed, Sep 10, 2008 at 12:49 PM, Pete Bartlett <pete@pcbartlett.com> wrote:
Robert Ramey wrote:
[..] But don't go foisting on me a whole new layer of work [...]
Sadly, by introducing boost::serialization::throw_exception, you have foisted work on me and other users of your library. Now we have to implement boost::serialization::throw_exception instead of just having one boost::throw_exception. This is exactly the kind of breakage you've been so strongly opposed to.
You didn't have to implement boost::serialization::throw_exception. That was your own decision, which I don't intend to object. I've learned that simply because I don't see the logic behind a given decision, doesn't mean that it was illogical. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Wed, Sep 10, 2008 at 2:20 PM, Emil Dotchevski <emil@revergestudios.com> wrote:
On Wed, Sep 10, 2008 at 12:49 PM, Pete Bartlett <pete@pcbartlett.com> wrote:
Robert Ramey wrote:
[..] But don't go foisting on me a whole new layer of work [...]
Sadly, by introducing boost::serialization::throw_exception, you have foisted work on me and other users of your library. Now we have to implement boost::serialization::throw_exception instead of just having one boost::throw_exception. This is exactly the kind of breakage you've been so strongly opposed to.
You didn't have to implement boost::serialization::throw_exception. That was your own decision, which I don't intend to object. I've learned that simply because I don't see the logic behind a given decision, doesn't mean that it was illogical.
Oh, DUH I *completely* misunderstood the previous post! Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski <emil@revergestudios.com> wrote:
Oh, DUH I *completely* misunderstood the previous post!
Sorry, yes my previous post pre-supposed readers were up to speed with the latest serialization changes in trunk where boost/serialization/throw_exception.hpp was introduced. See also http://svn.boost.org/trac/boost/changeset/48575
Pete Bartlett wrote:
Robert Ramey wrote:
[..] But don't go foisting on me a whole new layer of work [...]
Sadly, by introducing boost::serialization::throw_exception, you have foisted work on me and other users of your library. Now we have to implement
boost::serialization::throw_exception instead of just having one boost::throw_exception. This is exactly the kind of breakage you've been so strongly opposed to.
You're blaming the victim here. This problem isn't caused by me, I felt I had no other reasonable alternative. Robert Ramey
Robert Ramey:
Pete Bartlett wrote:
Sadly, by introducing boost::serialization::throw_exception, you have foisted work on me and other users of your library. Now we have to implement
boost::serialization::throw_exception instead of just having one boost::throw_exception. This is exactly the kind of breakage you've been so strongly opposed to.
You're blaming the victim here. This problem isn't caused by me, I felt I had no other reasonable alternative.
This particular problem is caused by you. There is no good technical reason to declare a separate throw_exception in another namespace for the user to implement. You should have re-declared boost::throw_exception.
Quoting Robert Ramey <ramey@rrsd.com>:
Pete Bartlett wrote:
Robert Ramey wrote:
[..] But don't go foisting on me a whole new layer of work [...]
Sadly, by introducing boost::serialization::throw_exception, you have foisted work on me and other users of your library. Now we have to implement
boost::serialization::throw_exception instead of just having one boost::throw_exception. This is exactly the kind of breakage you've been so strongly opposed to.
You're blaming the victim here. This problem isn't caused by me,
You've begged the question there. What is the specific, concrete, problem ? The introduction of BOOST_NO_RTTI solves the problem found in 1.36. If you mean that the header is still larger than in 1.35 then ok, its an arguable point, but surely the decision should be made by end-user (who may wish to disable the functionality (BOOST_DISABLE_EXCEPTION) or tweak his pre-compiled header), not by an intermediate library. To literally break the end-user's compile because of this smacks of cutting off one's nose to spite the face. Pete
______________________ Vicente Juan Botet Escribá ----- Original Message ----- From: "Peter Bartlett" <pete@pcbartlett.com> To: <boost@lists.boost.org> Sent: Thursday, September 11, 2008 5:02 PM Subject: Re: [boost] Tests are a mess
Quoting Robert Ramey <ramey@rrsd.com>:
Pete Bartlett wrote:
Robert Ramey wrote:
[..] But don't go foisting on me a whole new layer of work [...]
Sadly, by introducing boost::serialization::throw_exception, you have foisted work on me and other users of your library. Now we have to implement
boost::serialization::throw_exception instead of just having one boost::throw_exception. This is exactly the kind of breakage you've been so strongly opposed to.
You're blaming the victim here. This problem isn't caused by me,
You've begged the question there. What is the specific, concrete, problem ? The introduction of BOOST_NO_RTTI solves the problem found in 1.36.
If you mean that the header is still larger than in 1.35 then ok, its an arguable point, but surely the decision should be made by end-user (who may wish to disable the functionality (BOOST_DISABLE_EXCEPTION) or tweak his pre-compiled header), not by an intermediate library.
To literally break the end-user's compile because of this smacks of cutting off one's nose to spite the face.
Robert, maybe you can do the following: namespace boost { void throw_exception(std::exception const & e); // user defined namespace serialization { #ifdef BOOST_NO_EXCEPTIONS void throw_exception(std::exception const & e) { ::boost::throw_exception(e); } #else template<class E> inline void throw_exception(E const & e) { throw e; } #endif In this way, the user need to define only the boost::throw_exception function when BOOST_NO_EXCEPTIONS is defined. Vicente
Peter Bartlett wrote:
Quoting Robert Ramey <ramey@rrsd.com>:
Pete Bartlett wrote:
Robert Ramey wrote:
[..] But don't go foisting on me a whole new layer of work [...]
Sadly, by introducing boost::serialization::throw_exception, you have foisted work on me and other users of your library. Now we have to implement
boost::serialization::throw_exception instead of just having one boost::throw_exception. This is exactly the kind of breakage you've been so strongly opposed to.
You're blaming the victim here. This problem isn't caused by me,
You've begged the question there. What is the specific, concrete, problem ?
This specific concrete problems is that by replacing the functionality of a simple, well defined, understandable component with a very complex and elaborate one designed to address some other purpose now requires that one undertake a lot of new effort to verify what the new thing does, if it conflicts with the original reasons for selecting the component in the first place. All this takes a lot of time which I don't have. (We'll leave aside that apparently it depends on builds of other libraries for testing - which creates even more work). I raise this concern when the problems first came up and these concerns where dismissed. The author fail to see my concerns and legitimate and so no problem with behavior. So, even if I invested the effort to deal with this now, there was no guarentee that I wouldn't have to come back to it. I can't spend time on this kind of stuff and continue to be productive. I'm sorry this is created a problem for you as well. This question has been raised why I put it into boost::serialization::throw_exception instead just using boost::throw_exception for the for user override. This is the decision which I believe is causing your grief. First of all, it's not clear to me anymore what boost::throw_exception should do - its not obvious that its equivalent to the old boost::throw_exception. But the truth is I didn't think about it. Last year I got a huge amount of grief for some things I had in the boot namespace and agreed to move them in to the serialzation directory and namespace. An example was BOOST_STATIC_WARNING and a couple of others. It just so happened that I was moving this stuff out of the boost namespace to the serialization namespace and it was convenient to do the same with throw_exception at the same time. Robert Ramey
On Thu, Sep 11, 2008 at 10:46 AM, Robert Ramey <ramey@rrsd.com> wrote:
(We'll leave aside that apparently it depends on builds of other libraries for testing - which creates even more work).
No it does not. Here are the full tests: http://beta.boost.org/development/tests/trunk/developer/exception.html There was one instance, which originated this thread, in which my tests did not catch a _compiler bug_ on a _single platform_ which broke other libraries, without, for some reason, breaking my own test of that same functionality on that same platform. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
on Thu Sep 11 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
This specific concrete problems is that by replacing the functionality of a simple, well defined, understandable component with a very complex and elaborate one designed to address some other purpose now requires that one undertake a lot of new effort to verify what the new thing does, if it conflicts with the original reasons for selecting the component in the first place. All this takes a lot of time which I don't have. (We'll leave aside that apparently it depends on builds of other libraries for testing - which creates even more work).
I raise this concern when the problems first came up and these concerns where dismissed. The author fail to see my concerns and legitimate and so no problem with behavior.
Okay, Robert. Now your concerns have been taken seriously, and, I think, addressed. Is that correct, and if so, can we move on? If not, what is left to deal with?
This question has been raised why I put it into boost::serialization::throw_exception instead just using boost::throw_exception for the for user override. This is the decision which I believe is causing your grief. First of all, it's not clear to me anymore what boost::throw_exception should do - its not obvious that its equivalent to the old boost::throw_exception.
You won't take the word of Emil and Peter that it is?
But the truth is I didn't think about it. Last year I got a huge amount of grief for some things I had in the boot namespace and agreed to move them in to the serialzation directory and namespace. An example was BOOST_STATIC_WARNING and a couple of others. It just so happened that I was moving this stuff out of the boost namespace to the serialization namespace and it was convenient to do the same with throw_exception at the same time.
But throw_exception is not a similar case in any way. The things you were asked to move were *definitions* that were placed into namespace boost rather than into the serialization library. You didn't have a definition of throw_exception to move. Your change is analogous to making the switch from using boost::result_of to using your own private result_of template in Boost.Serialization. The result would be that existing code would stop working because your users had created necessary specializations of boost::result_of that would now not be used, just as now anyone's definition of boost::throw_exception will now not be used by the serialization library. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Thu Sep 11 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Okay, Robert. Now your concerns have been taken seriously, and, I think, addressed. Is that correct, and if so, can we move on? If not, what is left to deal with?
nothing - I move on some time ago.
This question has been raised why I put it into boost::serialization::throw_exception instead just using boost::throw_exception for the for user override. This is the decision which I believe is causing your grief. First of all, it's not clear to me anymore what boost::throw_exception should do - its not obvious that its equivalent to the old boost::throw_exception.
You won't take the word of Emil and Peter that it is?
No - I asked for a pledge that if this happened in the future it would be considered a bug. Since I didn't get one, there's no reason to believe it won't happen in the future. Rather than belabor the point, I just decided not to use the library until I have to time to look into it.
But throw_exception is not a similar case in any way. The things you were asked to move were *definitions* that were placed into namespace boost rather than into the serialization library. You didn't have a definition of throw_exception to move.
OK - I can easily implement vincent's suggestion. That should do it. Robert Ramey
on Thu Sep 11 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
David Abrahams wrote:
on Thu Sep 11 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Okay, Robert. Now your concerns have been taken seriously, and, I think, addressed. Is that correct, and if so, can we move on? If not, what is left to deal with?
nothing - I move on some time ago.
This question has been raised why I put it into boost::serialization::throw_exception instead just using boost::throw_exception for the for user override. This is the decision which I believe is causing your grief. First of all, it's not clear to me anymore what boost::throw_exception should do - its not obvious that its equivalent to the old boost::throw_exception.
You won't take the word of Emil and Peter that it is?
No - I asked for a pledge that if this happened in the future it would be considered a bug.
Whom did you you ask for a pledge?
Since I didn't get one, there's no reason to believe it won't happen in the future. Rather than belabor the point, I just decided not to use the library until I have to time to look into it.
I don't understand what "happening in the future" has to do with this particular library. Could you explain?
But throw_exception is not a similar case in any way. The things you were asked to move were *definitions* that were placed into namespace boost rather than into the serialization library. You didn't have a definition of throw_exception to move.
OK - I can easily implement vincent's suggestion. That should do it.
Great. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Sep 11, 2008 at 11:58 AM, David Abrahams <dave@boostpro.com> wrote:
on Thu Sep 11 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
David Abrahams wrote:
on Thu Sep 11 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote: Okay, Robert. Now your concerns have been taken seriously, and, I think, addressed. Is that correct, and if so, can we move on? If not, what is left to deal with? nothing - I move on some time ago.
This question has been raised why I put it into boost::serialization::throw_exception instead just using boost::throw_exception for the for user override. This is the decision which I believe is causing your grief. First of all, it's not clear to me anymore what boost::throw_exception should do - its not obvious that its equivalent to the old boost::throw_exception.
You won't take the word of Emil and Peter that it is?
No - I asked for a pledge that if this happened in the future it would be considered a bug.
In my mind, what "happened" was a change in implementation details of boost::throw_exception. I'm presuming that you are not requesting that any change in a function or library boost::serialization depends on should be considered a bug; could you explain your request a little better? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
David Abrahams wrote:
No - I asked for a pledge that if this happened in the future it would be considered a bug.
Whom did you you ask for a pledge?
Emil Here is where I asked for it http://lists.boost.org/Archives/boost/2008/07/139893.php Here is his response I got http://lists.boost.org/Archives/boost/2008/07/139894.php which includes the quote:
I would ask that library authors that cannot make a similar pledge include a disclaimer in thier documentation and header files something on the order of: ... You can ask anything you want and you can assume anything you want about Boost libraries, but the fact is that they do change and occasionally breaking changes are introduced, which may or may not be regressions.
which I took to at face value and acted accordingly. Robert Ramey
On Thu, Sep 11, 2008 at 2:20 PM, Robert Ramey <ramey@rrsd.com> wrote:
David Abrahams wrote:
No - I asked for a pledge that if this happened in the future it would be considered a bug.
Whom did you you ask for a pledge?
Emil
Here is where I asked for it
Ah. OK, the changes in boost::throw_exception are in full compliance with your unsolicited pledge. Its semantics have not been changed, only extended, and yes (I thought that was obvious) if any library that uses boost::throw_exception breaks due to the changed semantics, I *do* treat that as a bug (in boost::throw_exception.) Though I have no plans to make any changes in the rest of the Exception library, I can't make the same pledge for anything except for boost::throw_exception, for now. The difference is that boost::throw_exception is a simple, mature and proven interface; the rest of Boost Exception is relatively new, I have only used that code for about a year prior to the review proposal, and it was first released in 1.36.
I would ask that library authors that cannot make a similar pledge include a disclaimer in thier documentation and header files something on the order of: ... You can ask anything you want and you can assume anything you want about Boost libraries, but the fact is that they do change and occasionally breaking changes are introduced, which may or may not be regressions.
I wasn't expressing an opinion, I was stating a fact. Boost libraries do change, and occasionally the changes do break existing code, and occasionally such breaking changes are made on purpose. I apologize for the perhaps inappropriate tone of that remark. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
I wasn't expressing an opinion, I was stating a fact. Boost libraries do change, and occasionally the changes do break existing code, and occasionally such breaking changes are made on purpose. I apologize for the perhaps inappropriate tone of that remark.
No apology necessary. I do have a strongly held view on the issue of these kinds of changes. But I have come to realize that that view is not all that widely held. I accept the legitimacy of other views even if I don't agree with them. My course of action is based purely on practical considerations that a library maintenance can't consist of constantly going back to issues which have been considered settled. I know each one seems a small thing, but they add up to alot. Robert Ramey
On Thu, Sep 11, 2008 at 8:02 AM, Peter Bartlett <pete@pcbartlett.com> wrote:
Quoting Robert Ramey <ramey@rrsd.com>:
You're blaming the victim here. This problem isn't caused by me,
You've begged the question there. What is the specific, concrete, problem ? The introduction of BOOST_NO_RTTI solves the problem found in 1.36.
Actually, the Trunk revision does not need BOOST_NO_RTTI. It no longer requires RTTI. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Robert Ramey: ...
I don't know anything about the new exceptions library. How good is is or isn't, what it does, etc are not relevant. If you want to create a new throw exception with great new features that's just fine. But don't go foisting on me a whole new layer of work that I don't have time for - give it a different name.
The idea was to enhance the exceptions emitted by your library, thereby making it more useful, without your having to do any work. Users who catch an exception thrown by the serialization library could now take advantage of boost::exception facilities. Users who don't know or care about the additional functionality were supposed to find everything working exactly as before. This approach specifically wasn't meant to require you to use boost::exception (but you can start doing so in the future if you find it worthwhile.)
Emil Dotchevski wrote:
On Tue, Sep 9, 2008 at 11:36 PM, Johan Nilsson <r.johan.nilsson@gmail.com> wrote:
struct foo { virtual ~foo() = 0; };
inline foo::~foo() {}
Yes, that's what I was doing. Regardless, that particular compiler seems to erroneously discard the inline destructor definition, and then the linker complains that it's missing.
Ok, sorry for wasting bandwidth (and now again). / Johan
Richard Webb wrote:
Gennaro Prota <gennaro.prota <at> yahoo.com> writes:
* Are RW_WinXP_VC and RW_WinXP_VCrtl the same?
The 'RW_WinXP_VCrtl' tests are run in release mode (as opposed to debug like all the others).
Nice to know. That must have been a top secret piece of information before this post.
The 'RW_WinXP_VC' results arent actually there any more.
"There" where? They are in the release report and not in the trunk one. So that's another case where we can't test on trunk first. Nice. -- Genny
participants (11)
-
David Abrahams -
Emil Dotchevski -
Gennaro Prota -
Gubenko, Boris -
Johan Nilsson -
Pete Bartlett -
Peter Bartlett
-
Peter Dimov -
Richard Webb -
Robert Ramey -
vicente.botet