Re: [boost] Re: Problem with type_with_alignment.hpp
Daniel Frey wrote: Hartmut Kaiser wrote: > Hi all, > > The current version of the file type_with_alignment.hpp gives spourios > errors, because some macro expansion code generates '>>' instead of '> > >>' (closing template brackets). The corresponding fixing patch is > > attached. > > Just out of curiousity: Is this a workaround for a compiler bug? It is. > I think > I remember that if generated by the preprocessor, tokens need to be > glued with ## to form a single new token like >>, otherwise even two > consecutive >'s will be treated like two tokens. My colleague says I'm > wrong. Am I? :) Nope, you are right. Macro replacement happens after tokenization, and at that stage the only way to produce a new token is to use the ## operator. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost memory management guidelines
E. Gladyshev wrote: > > * Consider parametrization, especialy if your library is to be available > > for embedded or non-traditional (like DSP, etc.) platfroms. > > I think this item will make you think twice before hiding > boost::signal's allocator. An allocator parameter is not the only way to parameterize, here, nor it is necessarily the most appropriate one. If I wanted to manage how function/signals allocate their memory, I wouldn't want to do it on a per-object basis - which, without the typedef templates, is pretty much the only level the allocator template parameter would allow me to manage it on. At least for these two libraries, a per-project parameterization seems more appropriate to the real needs, and something as simple as a trait class could provide the means. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Release of 1.30.2 imminent
Jens Maurer wrote: > > BOOST_NO_STDC_NAMESPACE is documented to relate to C names, > > but swap is a C++ name so I don't think such macro > > should be used here. > > The CVS change of optional.hpp:1.10 is definitely incorrect, > because STDC_NAMESPACE refers to C names, not C++ names. > Sorry. > > However, just reverting the patch will make gcc-3.3 > non-functional, because std::swap(int,int) (for example) > is not going to be found. > > I've checked in a better fix to the main branch. optional_test.cpp > now works with gcc 2.95, gcc 3.0 and gcc 3.3 on Linux. > Please test on other platforms and (optionally) transport > the fix to the 1.30.0 CVS branch. Please don't check anything in RC_1_30_0 - we are about to tag for the release, and the branch already contains a workaround which works on pretty much every GCC version one might be interested in, including 3.3 - http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html (http://tinyurl.com/ke9z) Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.2 status
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, thank you! I've got all the notes too, so will check in the updated 'index.htm' shortly. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] 1.30.2 status
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, clean regressions run on win32 platform shows up correctly and "all green" - http://www.meta-comm.com/engineering/resources/cs-win32_rc_1_30_0_metacomm/developer_summary_page.html (http://tinyurl.com/jtpd) Needless to say, it is expected that things will stay this way until the release is out. 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? 2) Collect the release notes (in progress). 3) Tag for the release, prepare the tarballs. 4) After the tarballs are ready, pre-publish them, and do another round of regressions (on the tarballs). 5) Publish the release! If everything goes as planned, the latter can be expected to happen by Tuesday. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release notes for 1.30.2
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 environment > settings > > msvc-stlport and intel-win32-stlport toolsets now build static > libraries with multithreading enabled, to be compatible with the > STLPort builds. > > intel-win32 toolset now handles wchar_t correctly when intel is > installed over msvc6. > > Backported fixes from the main trunk which prevent errors building > the Boost.Test library in its default configuration. > > Backported portability improvements for checked_delete > > Locale support for metrowerks (requiring a statically-linked > runtime) is more uniformly handled. > Thank you! A couple more summaries are directly derivable from the CVS log (although the library authors are welcome to provide any corrections!): * Boost.Optional: new fix for std::swap (for gcc >= 3.3), fix a couple of typos in the documentation * Boost.Format: feed_args.hpp, format_class.hpp, msvc_disambiguater.hpp: merged MSVC7.1 fixes from the main trunk * Boost.Function: doc/tutorial.xml: fix a typo in the example code, test/sum_avg_portable.cpp: regenerated Below are the remaining changes that need to be commented on: johnmaddock * boost/config/: compiler/comeau.hpp, compiler/intel.hpp, compiler/vacpp.hpp, select_compiler_config.hpp, select_stdlib_config.hpp, platform/hpux.hpp, platform/irix.hpp, platform/linux.hpp, platform/solaris.hpp, platform/win32.hpp, stdlib/dinkumware.hpp, stdlib/libcomo.hpp, stdlib/stlport.hpp: Selectively merged changes in the main trunk into the branch for 1.30.2 release. martin_wille * tools/build/intel-linux-tools.jam: need -lrt, always John, Martin? Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] testing.jam - weird behavior? (Re: 1.30.2 ready for release?)
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 retrieving revision 1.15 retrieving revision 1.15.2.1 diff -r1.15 -r1.15.2.1 102c102 < local file = $(files[1]:R=$(SUBDIR_TOKENS:J=/) ; --- > local file = $(files[1]:R=$(SUBDIR_TOKENS:J=/)) ; ^^^ While the above looks like a right fix to me (not to mention that I have no idea how the mismatched brackets _could be_ handled without giving a syntax error), but the fact is that the change caused an unwanted behavior - now, while dumping the tests info, bjam appends an erroneous 'libs\' prefix to the static_assert library test names: [bjam.log] ... boost-test(COMPILE_FAIL) "static_assert_test_fail_8" : "libs\libs\static_assert\static_assert_test_fail_8.cpp" boost-test(COMPILE_FAIL) "static_assert_test_fail_7" : "libs\libs\static_assert\static_assert_test_fail_7.cpp" ^ This, in turn, leads to erroneous detection of the library name further in the tools chain, and ultimately to incorrect summary and detailed regression reports - http://tinyurl.com/jtpd (the yellow cells in the middle). The old revision works exactly as wanted (however weird it is): boost-test(COMPILE_FAIL) "static_assert_test_fail_8" : "libs\static_assert\static_assert_test_fail_8.cpp" boost-test(COMPILE_FAIL) "static_assert_test_fail_7" : "libs\static_assert\static_assert_test_fail_7.cpp" I would appreciate if someone with bjam expertise explained what's happening here and what would be the right fix. Thanks, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [MPL] Metafunction classes
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_ptr, my_other_policy<_> > p; > > to this: > > smart_ptr p; > > I know I can do this by changing my_*policy to a metafunction > class. But then smart_ptr doesn't know where the guts are. I am afraid I don't exactly understand the last sentence ;), but if 'smart_ptr' does something like typedef typename apply< typename lambda::type , T >::type p; things should work independently of whenever 'Policy' is in form of 'my_policy<_>' or 'my_policy' - given that the latter is a metafunction class, of course. HTH, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 will be 100% accounting for all failures on those > >> platform/compiler pairs. > > > > 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 testing. Especially since now we have tools > > to ensure it. > > 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 about how their libraries perform on all the compilers the regressions are being run on. Obviously, some compilers/configurations are included in the regression testing because the ones who manage the latter are the ones who are most interested in those. Then, again, obviously, some compilers/ configurations are included in the regressions because they are very widely used. For every release, the interested parties include library authors, regression runners, the release manager, the maintenance wizard, and of course active users who are subscribed to either of the lists. Given the above "setup", the implied interests of the participating groups, and their explicit and implicit responsibilities and gratitude towards each other, I think striving for "no regressions" goal I stated above would be both a reasonable and fair strategy which can be made to work. > For example, who is going > to address the one lexical_cast failure that's plaguing the 1.30.2 > release? If I were a release manager, I would: 1) ask the library maintainer if he is interested in looking at the failure; if he is not, or he is not responding - which is kind of likely in this case since Intel+STLPort is not a very common configuration, then: 2) ask the regression maintainers to look at the failure; if they are busy/don't know how to fix it, then: 3) put the issue on the list of probable regressions, and in at least a week before the release post an explicit pre-release regression warning on possibly both the users and developers lists asking interested parties to step in; if nothing happens, release with the regression and document it in the release notes. In this particular case, you can assume that we are at the stage 2. > It's only on intel-7.1 with STLPort and looks for all the > world like a config problem. Well, then we'll take a look at it closely. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bind/lambda - unsupported use case?
Gary Powell wrote:
> >Consider the following snippet:
> >
> >void show_warning( message_dialog const&, user_message );
> >void post_command( boost::function );
> >
> >int main()
> >{
> >boost::function f(
> > bind( &post_command
> >, ( bind( &show_warning, message_dialog(), _1 ) )
> >// what goes here?
> >)
> >);
> >}
> >
> >Could we make it work, somehow? Offers of a hand-written function
> >performing the composition are not accepted :)
> >
>
> I'm a bit confused by your request,
> Do you want both fns to be called?
Nope. Please see http://article.gmane.org/gmane.comp.lib.boost.devel/23466
for the semantics clarification. Basically, I want the whole bind
expression to return an unary function object which, when invoked, will
use the argument to construct a nested nullary function object:
bind( &show_warning, message_dialog(), )
and pass it as an argument to 'post_command'.
Does it make more sense now?
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
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 authors/maintainers address these problems? Where is our > >> maintenance wizard? > > > > All of the failures for function are due to newly-tested compilers. > > 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 the previous release and report the current status using _those_ expected results. But in any case, you have a point - for one, it's not always practical/possible to do the full re-run. We'll look into it. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 > >> platform/compiler pairs. > > > >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 testing. Especially since now we have tools > >to ensure it. > > That sounds reasonable to me. > > >Especially since now we have tools to ensure it. > > Damn. I forgot to bookmark the URL. Could you post it again please? Here's the page that links to all the reports we currently provide - http://www.meta-comm.com/engineering Please note that at the moment the main trunk report is not run against 1.30.0 results, but using the failures markup you provided us with - thus a greater number of red color there. > Or > better yet add something to boost-root/status/compiler_status.html linking > to the permanent location. That in turn means deciding what of your > experiment work is permanent and where it will live. Will happily do that, although it'll probably take some time to figure out the best way. We'll post the prototype for the discussion before actually checking it in. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
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/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 feedback. 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 status higlighting. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 status higlighting. > > I tried the new reports for the 1_30_0 branch.The results look broken > now. Everything that used to be in red is yellow now. (yellow is ok for > gcc-3.4-cvs, but the other fields should be red). Err, sorry, broken check-in! Fixed now. Could you please re-generate the expected results file, and try it again? Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 about how their libraries perform > > on all the compilers the regressions are being run on. > > > > Obviously, some compilers/configurations are included in the regression > > testing because the ones who manage the latter are the ones who are > > most interested in those. Then, again, obviously, some compilers/ > > configurations are included in the regressions because they are very > > widely used. > > > > For every release, the interested parties include library authors, > > regression runners, the release manager, the maintenance wizard, and of > > course active users who are subscribed to either of the lists. > > > > Given the above "setup", the implied interests of the participating > > groups, and their explicit and implicit responsibilities and gratitude > > towards each other, I think striving for "no regressions" goal I stated > > above would be both a reasonable and fair strategy which can be made to > > work. > > Some people are posting regressions for pre-release compilers. Should > a library author should be expected to keep his library healthy on > some weird/broken compiler just because it happened to work there by > chance at one point? You skipped the part of my original posting which explicitly said: > > 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 testing. Especially since now we have tools > > to ensure it. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
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 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 feedback. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 > >> intel-7.1-vc60-stlport > > > >It's OK with me. > > I'd rather that they have the same root as the base toolsets... > > borland-5.5.1 > borland-5.6.4 > intel-win32-7.1-vc60 > intel-win32-7.1-vc60-stlport > > Makes for easier maintenance. OK, we'll go with these. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 the previous release and report the current status > > using _those_ expected results. > > Many tests might have worked on the new compiler "by chance" with the > previous release. It isn't fair to demand that maintainers to fix > bugs on compilers they haven't agreed to support. I am not sure how your remark is related to this particular sub-thread, but I agree, actually. On the other hand, some of the compilers which the library author(s) might be indifferent to are of some interest to the regression test maintaniners and some number of users. It would be unfair to _not_ to give them a chance to keep those supported by a small amount of cooperation on everyone's side. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: ublas and gcc (was: Re: [boost] Re: Compiler status for GCC 3.3)
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 happen. Other vendors haven't been, so no wonder they are lagging behind. IMHO 7.1 folks have done a great service to the C++ community at large, and they deserve a little bit more appreciation. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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. Actually > I don't know about bcc-5.6.4 since I don't have that compiler, but I > expect the conditions are the same as for bcc-5.5.1. Will be done. > > >> As for the others, the failures you're reporting with intel-7.1 are > >> very strange; my 7.1 compiler doesn't have these problems AFAIK. > > > > Hmm, looks like another configuration problem to me. We'll take a look > > at it. > > > >> What does the "meta-" prefix mean? > > > > "meta-" is our prefix for non-boost toolsets. > > It's a strange standard to hold boost libraries to, passing on > toolsets which are not checked into the Boost CVS. Can we do > something about that? 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 intel-7.1-vc60-stlport etc. > > >> Do you have some special configuration of each of these compilers? > > > > Well, most of them are not really special. For instance, bcc-* ones > > were introduced for the only purpose of being able to test 5.5.1 and > > 5.5.4 compilers simultaneously. The complete list of differences is > > available here - > > > > http://www.meta-comm.com/engineering/resources/cs-win32_rc_1_30_0_metacomm/patches.html > > That's good to know. Is there a link on the main summary page? It's on our TODO list (the regressions on the branch and on the main trunk are being run on different machines, and these are slightly out of sync). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] 1.30.2 - lexical_cast failure (was: Boost 1.31 release?)
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 having the 1.30.1 > > debacle hanging over my head. > > Can it wait a day or two? As regression maintainers, we are interested in > fixing this one. OK, it looks like simply integrating the main trunk version will take care of it - http://tinyurl.com/jtpd. What would be the right way to do it in the CVS terms at the moment? Should we just follow the procedure in http://www.boost.org/more/release_procedures.htm, or there is more to it? (e.g. what's with this mysterious RC_1_30_2 tag?) Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 compilers that are > >> currently under regression testing. Especially since now we have tools > >> to ensure it. > > > >OTOH, it might not always be achievable. > >For boost 1.31 we are having an interface breaking change to the > >iterator_adaptors, and not all compilers pass all tests with the new > >adaptors yet. > > > >While this may not be a problem for the iterators library (it is > >effectively new) it may have a knock-on effect on any other boost > >libraries implemented on top of it. > > > >The principle is a good one, but I be prepared to make a few allowances > >in the practice. > > I think a reasonable goal is that any regressions should be understood and > discussed, rather than silent. Exactly my sentiments. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: 1.30.2 - lexical_cast failure
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 resolution > >> > > to me. > >> > > >> > In that case, can I release 1.30.2? I don't like having the 1.30.1 > >> > debacle hanging over my head. > >> > >> Can it wait a day or two? As regression maintainers, we are interested in > >> fixing this one. > > > > OK, it looks like simply integrating the main trunk version > > Of what? intel-win32-tools.jam? No, of the test in question, "libs/conversion/lexical_cast_test.cpp". The current version in RC_1_30_0 is simply mis-configured in relation to the newer header - and integrating from the main trunk will fix that. > I did ask Misha to try using that with the RC_1_30 branch, but never heard back. You can consider my reply as "hearing back". We didn't miss your suggestion, but simple examination of the test itself led us to what we consider to be a more appropriate fix. > > > will take care of it - http://tinyurl.com/jtpd. What would be the > > right way to do it in the CVS terms at the moment? Should we just > > follow the procedure in > > http://www.boost.org/more/release_procedures.htm, or there is more > > to it? > > That procedure should work. If the 3rd step doesn't result in a file > with the same contents as your current state after "integrating the > main trunk version", you should make it so. > > > (e.g. what's with this mysterious RC_1_30_2 tag?) > > It's not mysterious but it is misnamed. Shoulda been RC_1_30_2a1. > IOW, it's a non-branch tag marking the first release candidate for > 1.30.2. You can ignore it. OK, good to know, thanks. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
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): > > http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html > > [BTW, Misha and Aleksey, when I click any of the failure links they > lead to the log but not to any internal target showing the specific > failure. Can this be fixed?] Fixed in the RC_1_30_0 branch; if the next run is done with the updated/rebuilt tools, the problem will go away. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 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 testing. Especially since now we have tools to ensure it. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 over my head. Can it wait a day or two? As regression maintainers, we are interested in fixing this one. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Fun PP lib example
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(double*);
> >
> > private:
> > struct state;
> > scoped_ptr m_state;
> > };
>
> Missing ~foo, possible undefined behavior. :-)
Not here :). I intentionally didn't qualify 'scoped_ptr'; ours works just
fine :).
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] bind/lambda - unsupported use case?
Consider the following snippet:
void show_warning( message_dialog const&, user_message );
void post_command( boost::function );
int main()
{
boost::function f(
bind( &post_command
, ( bind( &show_warning, message_dialog(), _1 ) )
// what goes here?
)
);
}
Could we make it work, somehow? Offers of a hand-written function
performing the composition are not accepted :).
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
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 feedback. > > Very nice! Thank you! > I am looking for a library which has both red and yellow for > the same compiler so that I can verify that it shows up red in the > top-level summary. It does. See, for instance, "regex" on "cwpro8". > > I have looked at the iterator library failure with > meta-intel-7.1-stlport. It appears to me that either > BOOST_NO_STD_ITERATOR_TRAITS or BOOST_MSVC_STD_ITERATOR is > misconfigured for this library. This configuration probably needs to > change depending on whether you are using STLPort iostreams and which > Dinkum library underlies your STLPort. Thanks for the info, we will look into it. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 testing. Especially since now we have tools > > to ensure it. > > OTOH, it might not always be achievable. > For boost 1.31 we are having an interface breaking change to the > iterator_adaptors, and not all compilers pass all tests with the new > adaptors yet. > > While this may not be a problem for the iterators library (it is > effectively new) Yes. > it may have a knock-on effect on any other boost libraries implemented > on top of it. And any failures concerned with the interface change per se should be fixed before the release. It might happen that major changes in a library inadvertently cause _functionality regression_ on the particular compiler, but IMO "inadvertently" is a key word here. > > The principle is a good one, but I be prepared to make a few allowances > in the practice. Sure, as long as it's an explicit decision. After all, those could be put in the release notes. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 will be 100% accounting for all failures on those > >>> platform/compiler pairs. > >> > >> 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 testing. Especially since now we have tools > >> to ensure it. > > > >I worry a little about requiring library authors not to regress on > >compiler combinations they don't test with. For example, who is going > >to address the one lexical_cast failure that's plaguing the 1.30.2 > >release? It's only on intel-7.1 with STLPort and looks for all the > >world like a config problem. > > It can be very time consuming to track down the exact reason for failures. > Thus we should focus our 1.31.0 effort on a small number of widely used > compilers which don't have a lot of problems. It doesn't have to be the release manager who investigates all the issues himself, though. There might be enough of the interested parties with motivation/resources to resolve most of these in a reasonable time frame if they a given a chance/"managed" properly. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bind/lambda - unsupported use case?
Peter Dimov wrote:
> Aleksey Gurtovoy wrote:
> > Consider the following snippet:
> >
> > void show_warning( message_dialog const&, user_message );
> > void post_command( boost::function );
> >
> > int main()
> > {
> > boost::function f(
> > bind( &post_command
> > , ( bind( &show_warning, message_dialog(), _1 ) )
> > // what goes here?
>
> "protect", in boost/bind/protect.hpp. Lambda has both "protect" and
> "unlambda", either will work (I think).
>
> > )
> > );
> > }
I am afraid it's not that simple. Note that 'post_command' takes a
_nullary_, not an unary function. To clarify the semantics of the above,
I need to construct a bind expression which would allow the original code
to become equivalent to the following:
void
post_show_warning_command(
message_dialog const& a_dialog
, user_message a_message
)
{
post_command( boost::bind( &show_warning
, a_dialog
, a_message
) );
}
int main()
{
boost::function f(
boost::bind(
&post_show_warning_command
, message_dialog()
, _1
)
);
}
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 to 1.30.0, and IMO we ought to > > fix all these before we branch for the release or anything. > > I can't really tell what these represent. As usual, a red cell means a regression from the 1.30.0 tarball, a dark green one - an improvement. > All of the new iterator library tests which weren't in 1.30.0 are > showing up as regressions if they're failing. Yes, it's a known shortcoming - or a feature, depending of how you look at it. By default, new tests are expected to pass. > 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. > As for the others, the failures you're reporting with intel-7.1 are > very strange; my 7.1 compiler doesn't have these problems AFAIK. Hmm, looks like another configuration problem to me. We'll take a look at it. > What does the "meta-" prefix mean? "meta-" is our prefix for non-boost toolsets. > Do you have some special configuration of each of these compilers? Well, most of them are not really special. For instance, bcc-* ones were introduced for the only purpose of being able to test 5.5.1 and 5.5.4 compilers simultaneously. The complete list of differences is available here - http://www.meta-comm.com/engineering/resources/cs-win32_rc_1_30_0_metacomm/patches.html Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
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 > > release? Since we would prefer to base our released software on a > > Boost release instead of a CVS snapshot 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. 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 to 1.30.0, and IMO we ought to fix all these before we branch for the release or anything. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] switch-based runtime type selection (for variant)
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 else-if-then statement incrementally
> by means of a recursive function template instantiation.) But what if you
> could give a template the number of types among which you want to select
in
> addition to the sequence? Could it then implement a switch-based
selection
> on the first 'n' types in the sequence? The answer turns out to be yes,
up
> to a point. The mechanism, in this case, is partial template
> specialization.
> Let us define a template class:
> template
> class n_ary_rtts_invoker;
> How does it produce a switch statement based on 'n'? Well, if we limit
> ourselves to a specific value of 'n', we can express it. For example,
here
> is a specialization for 'n'==3:
>
> template
> class rtts_invoker
> {
> public:
>template
>static
>BOOST_DEDUCED_TYPENAME Operator::result_type
>invoke(Operator & op, StoragePtr storage, long index)
>{
> switch (index)
> {
> case 0:
> return op(*(static_cast::type
> *>(storage)));
> case 1:
> return op(*(static_cast::type
> *>(storage)));
> case 2:
> return op(*(static_cast::type
> *>(storage)));
> }
>}
> };
>
> Given this specialization of n_ary_rtts_invoker, we can setup runtime type
> selection on the first three types in a sequence. To be more specific, if
> we instantiate a type, "n_ary_rtts_invoker", the template
> machinery should match the above specialization, and the statement,
> "n_ary_rtts_invoker::invoke(my_op, storage, index)", will make
a
> selection among the first three types in 'my_seq' via a switch statement
> (assuming 0<=index<3).
> If we define a similar specialization for values 1 and 2, we can setup
> selection on sequences of size 1-3.
>
> The general case devolves into an else-if-then:
> Let us assume that we have specializations up to a certain number,
> 'max_specialization_count'. Then we know that we can get switch-based
> runtime type selection ("rtts") on any mpl::Sequence whose size is not
> greater than 'max_specialization_count'. To provide rtts for Sequences
> whose size is greater than 'max_specialization_count', we provide a more
> general template definition. Its "invoke" function sets up a switch-based
> selection among the first 'max_specialization_count' types, and then sets
up
> a (recursive) selection among the remaining types.
FWIW, I've used a similar technique in MPL to do recursion unrolling for the
'advance' algorithm:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/boost/mpl/aux_/preprocessed/plain/advance_forward.hpp?rev=1.4
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
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 which http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/user_summary_page.html would reveal a clear green field, without any "details" links to check. > > http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_result_page.html > > Only one red box (intel-7.1-stlport lexical_cast)! ... which means a regression from 1.30.0 ;). To be fair, quite a few failures have been fixed (dark green cells) - http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_summary_page.html Still, it would be nice if we didn't release until _all_ regressions are fixed. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fun PP lib example
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 variation of the idiom, sometimes called > >> "hidden state", which doesn't have the shortcoming in the first place: > > > > Dave, do you still think this would be a good example to add to the > > docs? > > Well, yeah. I don't understand how Aleksey's idiom accomplishes the > same things as pimpl (yet). I was talking about pimpl as described here - http://www.gotw.ca/gotw/024.htm. > I need to be able to plug in different > runtime-polymorphic implementations behind the handle classes I'm > defining. Sounds like a job for an interface class + a factory function, unless your objects need to be passed by value. In any case, IMO the latter one is more correctly described as "handle/body". Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fun PP lib example
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. > > > > There is another variation of the idiom, sometimes called "hidden state", > > which doesn't have the shortcoming in the first place: > > > A shortcoming of the hidden state idiom compared to the classic delegation > idiom is that only the state is encapsulated, not the behaviour. I am not sure what do you mean by "encapsulated". Hidden in a source file as opposite to the header? > IOWs, if you need to hide the operations, not just the state, you still > need to mirror the interface class member functions into > the impl class. How so? With the hidden state, what would be private member functions becomes free functions at the file scope. You just call those directly from anywhere within the file scope, without the boilerplate forwarding. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Fun PP lib example
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 place:
class foo
{
public:
foo();
foo(int);
int f() const;
void g(double*);
private:
struct state;
scoped_ptr m_state;
};
and then in the .cpp file:
struct foo::state
{
// c'tor only!
state( int b, double* fu );
int bar;
double* fu;
};
foo::foo( int b )
: m_state( new state( b, 0 ) )
{
}
int foo::f() const
{
return m_state->bar;
}
void foo::g( double* ptr )
{
m_state->fu = ptr;
}
A nice by-product property of the technique is that now you don't have to
prefix/postfix the state's member names since their are always accessed
throuh 'm_state->' (or 'state().' or 'self().' or whatever accessor you
prefer).
Here at work we have a little helper class that hides the rest of the
boilerplate stuff:
class foo
: hidden_state
{
public:
foo();
foo(int);
int f() const;
void g(double*);
};
FWIW :),
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preparing 1.30.1 Release
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 > summary of the fixes that were applied? > > smart_ptr > lexical_cast > function > lambda > MPL The change in "mpl/aux_/typeof.hpp" is yours, and the note is almost OK to use as-is, IMO: "Use Gibbons typeof for [Metrowerks CodeWarrior] Pro8". Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
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/cvs_RC_1_30_0/developer_result_page.html#mpl It is. It's due to a bug in 'process_jam_log.cpp', which confuses the tests with the same names from different libraries (MPL and Preprocessor, in this case). We didn't have time to fix it yet. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
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 branch results (relative to 1.30.0 tarball) are available now. The developers summary page summarizes things quite nicely (light green OK cell means there has been no regression): http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_summary_page.html Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
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 I use to produce > http://boost.sourceforge.net/regression-logs/cs-win32-diff.html > > It proves the concept, so to speak, but is way too unreliable. Fails when > new compilers are added, for example. > > What is really needed is to add a "history" element to the test_log.xml > files. That would be far more reliable. Let me think about it overnight. The way we do it in the new reports is to extract the failures from the original regression run and pass them as "expected failures" to the input of the scripts producing the today's reports. The scripts merge these into "extended results" XML, and then produce the HTML reports basing on that. Works perfectly. All XML processing is done through XSLT, but it's very worth it - the stlysheets which do the extracting and merging are barely 100 lines long. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
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 support for showing diffs between two versions of the test > result tables? For the new regression report format, yes. For instance, here's the CVS main trunk report against the 1.30.0 tarball - http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html If you are interested in producing these, we will provide you with the scripts. You'd need an XSLT processor and Python, but beside that it's as simple as running a Python script after the regression run. > > If there isn't such a thing I would try to implement something that > reads two tables and marks the differences. That would take a day > or two, I guess. Please, don't! If you have the prerequisits installed, setting up a step to produce the new-format reports should take about 15 minutes, and they are way much more informative. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: functors for taking apart std::pair?
Brian McNamara wrote: > If and when I get FC++ ( http://www.cc.gatech.edu/~yannis/fc++/ ) into > Boost, FC++ has the same kind of selectors you've shown above (named > "fst" and "snd", as in Haskell). Whereas these function objects also > cannot be used with STL algorithms requiring adaptables (for the reason > you mention above), it can be used with the analogous algorithms in > FC++, since the FC++ infrastructure enables return-type-deduction for > template function objects. So do Boost.Lambda and Phoenix infrustructures, and unification of these is proposed for the TR1 - http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.html > > I've been working on "boostifying" FC++ this past week (adopting naming > conventions, reusing Boost code, etc.) and will hopefully get a > Boost-ful FC++ version up for review in the next two weeks or so. Since the experts on the subject are silent, I thought it's worth to point out that the Phoenix framework, which is a part of Boost.Spirit (http://www.boost.org/libs/spirit/phoenix/index.html), is highly influenced by FC++, so it might be worth looking at it to see how much of the work can be reused between these two. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
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. ... in conventional run-time programs. Unfortunately, 'void' is not special for metaprograms, many of which have a need to routinely manipulate it along with all other built-in types. 'mpl::void_' addresses this issue. > There's no correspondence between void_ and void the way there is > between bool_ and bool. 'void_' in MPL plays a role very similar to a role of 'void' in the core language. So, conceptually, there is a correspondence. Personally, I appreciate the analogy, dislike 'null'/'nil'/etc. for the lack of such, and would like to keep the name. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Warnings about derivation without explicit accesscontrol specified
Daniel Frey wrote: > > The libraries itself are relatively bug-free, but there are plenty of > > portability problems with some compilers. For the HP-UX, IRIX, and DEC > > compilers in the versions I have access to, it's probably a waste of > > time to try and fix problems, unless it's obvious what to do, because > > the compilers have relatively old front-ends with plenty of > > non-conformance issues. > > I wonder if it's possible to distinguish regressions into "fail" and "not > supported", where the latter means that it fails and we (currently?) > can't make it work. This way it might be easier to find regressions that > are supposed to work but fail because of "accidents" :) See http://www.mail-archive.com/[EMAIL PROTECTED]/msg08641.html for the thread on this exact topic. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
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 your own code :), I don't
agree that we should deny the occasional need for a special type in
many simpler cases - like Drazen's one. It would just make user life
unnecessary more complicated than it should be.
Besides, 'void_' _is_ a public type:
begin::type === void_
order::type === void_
and a couple of others I don't remember off hand :).
> (I think Aleksey doesn't believe me, but I'm
> about to prove it... ).
I don't _agree_ :).
>
> Observe the definition of identity (comments added for exposition
> purposes):
>
> template
> struct identity
> {
> typedef T type;
> };
>
>
> // identity is a metafunction class which makes it efficient
> // to pass mpl::identity<> where a lambda expr/metafunction class is
> // expected.
> template<>
> struct identity< void_ >
> {
> template<
> class T1, class T2 =void_, class T3 =void_, class T4 =void_, class
T5 =void_
> >
> struct apply
> : identity< T1 >
> {};
> };
>
> // specialization of lambda > for efficiency.
> template<>
> struct lambda< identity< void_ > >
> {
> typedef identity< void_ > type;
> };
IMO we should just stop using 'void_' for internal purposes and give it
up to users :).
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] mpl/loki
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 "algorithm" to give me type
> from type list at a specified position, or NullType (loki's
> internal "null" class) if not found. Now, I need the same for
> mpl:vector, and I tried the following 'naïve' approach:
>
> [TypeVector is boost::mpl::vector]
> enum { numParams = boost::mpl::size::type::value };
> typedef typename boost::mpl::if_c<(numParams > 2),
> typename boost::mpl::at_c::type,
> boost::mpl::void_>::type Param1;
>
> I was expecting to get Param1 to be boost::mpl::void_, but to my
> great surprise, my compiler (VC7.1) decided to fully evaluate
> "then" branch of if_c as well, even though the expression
> numParams > 2 was false, and failed.
It's a pitfall that is easy to fall into even if you've read about
it. The correct way to implement what you want would be
typedef typename boost::mpl::apply_if_c<(numParams > 2),
boost::mpl::at_c,
boost::mpl::identity
>::type Param1;
We have a whole section in the docs devoted to this issue -
http://www.boost.org/libs/mpl/doc/index.html#applyif
> What would be the "right" way to express my intention? Btw, I
> would like to congratulate authors of mpl on the job well done, I am
> most impressed not only with the features that mpl provides but also
> with the errors I get when something goes wrong - they are far more
> readable than most of the STL errors I am used to seeing.
Thank you!
As Dave already mentioned, if you want to see really pretty errors :),
you might want to consider to install STLFilt - see
http://www.bdsoft.com/dist/vcmeta-demo.txt for the MPL-specific example.
HTH,
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] mpl::if_ and ICE triggered on GNU g++-cvs-today
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 type;
> };
>
> template<
> typename T1
> , typename T2
> >
> struct if_c
> {
> typedef T2 type;
> };
>
>
> template<
> typename C = void_
> , typename T1 = void_
> , typename T2 = void_
> >
> struct if_
> {
> private:
> typedef if_c<
> static_cast(C::value)
> , T1
> , T2
> > almost_type_;
>
> public:
> typedef typename almost_type_::type type;
>
>
> };
>
>
> int main() {
> typedef if_::type D;
> D d;
> }
Hmm, seems like a regression to me. The above compiles fine on gcc 3.2. It
won't compile on 2.95.x, but it doesn't matter because for that one the
output would be different - the original line responsible for the static
cast form is
BOOST_MPL_AUX_STATIC_CAST(bool,
BOOST_MPL_AUX_VALUE_WKND(C)::value)
and it will produce either '(bool)(C::value)' or
'static_cast(C::value)' depending on which form the compiler is more
happy with.
I suggest you report the failure as a regression to gcc developers and make
a local modification to "boost/mpl/aux_/static_cast.hpp" to workaround the
bug meanwhile.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] for_each broken with empty list<>'s
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 makes the code compile. It's actually a known issue which I fixed on the branch a couple of weeks ago, but didn't have time to regenerate preprocessed headers and integrate the whole thing into the main trunk then. Now it's there! Thanks once again, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [mpl] ETI problem w/ clear algorithm
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 ETI is to add a correspondingly guarded
'int' specialization for the template where the error occurs. In our case,
it would be something along these lines, in "mpl/aux_/clear_impl.hpp":
#if defined(BOOST_MPL_MSVC_60_ETI_BUG)
template<>
struct clear_traits
{
template< typename Sequence > struct algorithm
{
typedef int type;
};
};
#endif
>
> Below is the error output from the regression tests (variant_test1).
With the above fix (already in the main trunk), the ETI error goes away, but
looks like you will need a little bit more tweaking in other areas to make
the whole test compile.
HTH,
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: compose_f_gxy_hxy
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 compose_f_gxy_hxy. The standard is moving towards 'bind' - http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1455.htm. > If we take bind into account here, we could just as well remove > compose.hpp completly, couldn't we? We might, in a couple of years. Seriously, 'bind' is superior here; it takes some learning to switch over from the 'compose_*' family, but it's worth it. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] compose_f_gxy_hxy
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 changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Current CVS Snapshot or...?
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 to break anything > else in the boost (and by chain reaction in our code). It seems that > variant lib is dependent on (branch of?) mpl, The version of the Variant library in the CVS' main trunk depends (naturally) only on the main trunk components - MPL not being an exception. The question is which parts of the main trunk you need/can get without breaking things. > so what I would like to > know is: what is the most sane branch/snapshot we should take from the > cvs to get reasonably stable boost (overall) with variant in whatever > state it is ATM? As far as MPL goes, I would say you can safely update it from the main trunk - that is, if you are currently using 1.30.0 release. To determine the status of other Variant dependencies you can use our experimental status reports which employ automatically collected 1.30.0-snapshot's failures to highlight the differences between now and then: http://boost.sourceforge.net/regression-logs/user_summary_page.html Basically, 'unexp.' there signals a new failure (or a new library/test case). Of course, you would have to use your own judgment to determine how critical are those to you. HTH, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Experimental audience-targeted regression results
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 transitions emphasized. > > > > Do you mean that there are no expected failures for the smart_ptr > > library (which we'll take care of soon), or something else? 'Cause > > I, for instance, definitely would like to see a CVS health report in > > terms of regressions rather than absolute failures. > > I meant that my objections applied to the user summary, not > the developer summary, OK, I understood that one. > and that I personally don't need a way to mask a 'fail' on the > developer summary, even if I expect a test to fail on this > configuration. Interesting. Given the total number of failures we have, it's practically impossible to track the regressions if the "expected" failures are not masked, though - especially when changes are made to something as basic as 'config' or 'type_traits'. We can easily provide such report, I am just trying to determine what are the use cases. Could you please elaborate on yours? Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Experimental audience-targeted regression results
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 going to show? > > Nothing will go wrong; it's only pass->fail transitions that are > emphasized. But that's my point. If current run was a disaster, in the next one - which can happen an hour later - the new failures won't be emphasized since they are not new anymore - even although they _are_ regressions and need to be fixed! > False pass->fail transitions can only happen for > compile-fail/link-fail tests that aren't that significant. > > >> IMO it can work only if you have a trusted snapshot of what is >> considered a "good" CVS state and you update it "pessimistically" - >> that is, remove the expected failures that are now passing and leave >> everything else intact - automatically, of course. And that's exactly >> what we are going to do. > > I didn't realize that the plan was to automatically manage the expected > failures. It wasn't at the very beginning, but thanks to your and other people's comments our understanding evolved, and so did the plan :). Thank you, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Trouble building latest CVS (Intel 7.1 and VC7)
Beman Dawes wrote: > Intel's 7.1 upgrade doesn't bump their release macro! It is still > reporting 700. > > I tried to update to use Intel 7.1 with VC++ 7.1, but am getting > strange results. The IDE integration doesn't seem to provide a way to > switch to the Intel compiler. Boost tests are getting weird link > failures. No std::endl for example. Either the Intel release isn't > ready for VC++ 7.1 (in spite of claims to the contrary) or I've done > something stupid. > > Which VC++ version are you integrating Intel with? Have you gotten it > to work with VC++ 7.1? > Currently ours is configured to integrate (and be compatible with) MSVC 6.0. We didn't try anything else (yet). > Also, your setup is confusing the bjam automatic version deduction. If you mean all those 'wchar_t'-related failures, it doesn't have anything to do with the bjam version deduction - it's "boost/config/compiler/intel.hpp" that is at fault here. As per http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864, a standalone Intel C++ 7.x does not automatically define _WCHAR_T_DEFINED macro, but then checking just for that one to determine whether we need to set BOOST_NO_INTRINSIC_WCHAR_T is not enough, because the former one is also getting defined in Dinkumware's header, so currently the success of the compilation on Intel 7.x in VC6 compatibility mode very much depends on the order of includes of various boost headers. For instance, this one-liner compiles: #include "boost/type_trais/is_integral.hpp" but this one already does not: #include #include "boost/type_trais/is_integral.hpp" Since the toolset automatically, through the command line, defines _NATIVE_WCHAR_T_DEFINED whenever '/Zc:wchar_t' is specified, I would say that #if BOOST_INTEL_CXX_VERSION < 700 # define BOOST_NO_INTRINSIC_WCHAR_T #else # ifndef _WCHAR_T_DEFINED #define BOOST_NO_INTRINSIC_WCHAR_T # endif #endif lines in "boost/config/compiler/intel.hpp" should look more like #if BOOST_INTEL_CXX_VERSION < 700 # define BOOST_NO_INTRINSIC_WCHAR_T #else # if !defined(_NATIVE_WCHAR_T_DEFINED) #define BOOST_NO_INTRINSIC_WCHAR_T # endif #endif but then the file's history shows that we went through quite a few iterations on this one, so I am not that sure. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Trouble building latest CVS (Intel 7.1 and VC7)
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 http://boost.sourceforge.net/regression-logs/cs-win32_metacomm.html, despite what it says in the table's header (need to research why), already reports for the new compiler. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Experimental audience-targeted regression results
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 to > > stick to. > > Testing on different Intel configurations is a good thing; it has > uncovered a problem in shared_ptr_test. It's just different > configurations need to have different (non-generic) toolset names > (intel-7.1-vc6, intel-7.1-vc7, intel-7.1-vc6-stlport...) Unfortunately the number of tested configurations is somewhat bound by the length of the compilation cycle, but as far as the naming goes, we totally agree. > > 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 transitions emphasized. Do you mean that there are no expected failures for the smart_ptr library (which we'll take care of soon), or something else? 'Cause I, for instance, definitely would like to see a CVS health report in terms of regressions rather than absolute failures. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Experimental audience-targeted regression results
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 > intrusive_ptr_test and shared_ptr_test fail. Well, we didn't do anything special to mis-configure it ;), besides choosing MSVC 6 compatibility mode (during the setup, as opposite to MSVC 7.0 one). Any ideas what's the right way to fix that? > > This also demonstrates a different problem, the ADL-related issue is > masked by the fact that shared_ptr_test is marked an expected failure. Yep. This is a shortcoming of the file-based failure report. Collecting Boost.Test detailed test run results will solve that, and it's on our to-do list. > It's not since I fixed it. ;-) > > Beman's approach, where unexpected failures were automatically > determined by comparing the current run with a previous 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 going to show? IMO it can work only if you have a trusted snapshot of what is considered a "good" CVS state and you update it "pessimistically" - that is, remove the expected failures that are now passing and leave everything else intact - automatically, of course. And that's exactly what we are going to do. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [mpl] workaround needed for Borland
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: > > > > f:\cvs\boost\libs\mpl\preprocessed> preprocess.py > > > > Usage: > > preprocess.py [] > > > > Purpose: > > updates preprocessed version(s) of the header(s) in > > "boost\mpl\aux_\preprocessed" directory > > > > Example: > > the following command will re-generate and update all > 'apply.hpp' > > headers: > > > > preprocess.py all f:\cvs\boost apply.cpp > > > > Well it's called pp.py in the current CVS, and doesn't handle > 3 args, but... Are you using anonymous access? 'preprocess.py' was in the CVS for a couple of hours at the time I posted the reply. 'pp.py' is a pretty-printer, 'preprocess.py' is a driver for batch preprocessing - the part of the chain that had been missing. > > You've actually got a Python-based C++ preprocessor, or what?? Nope, just a pretty-printer. You need gcc or MSVC 7.1 to do the actual preprocessing job (or something else which gives an output that the pretty-printer can eat - the latter is not sophisticated enough to handle an arbitrary misformatted code). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: [mpl] workaround needed for Borland
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 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: f:\cvs\boost\libs\mpl\preprocessed> preprocess.py Usage: preprocess.py [] Purpose: updates preprocessed version(s) of the header(s) in "boost\mpl\aux_\preprocessed" directory Example: the following command will re-generate and update all 'apply.hpp' headers: preprocess.py all f:\cvs\boost apply.cpp ? Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: [mpl] workaround needed for Borland
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 use BOOST_MPL_AUX_COMMON_NAME_WKND to work around this bogus > report. > Fixed in the CVS now. > 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. I've checked in some missing pieces for the preprocessed headers generation, so if somebody feels like doing a similar fix herself in future, she can easily do it - assuming she has Python and gcc installed. See "libs/mpl/preprocessed/preprocess.py" blurb for the details. Thanks for the report, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Experimental audience-targeted regression results
Rene Rivera wrote: > >> So > >> having what is essentially a binary indicator is misleading. > > > >As long as it reports things correctly, it's not. > > I'll only say that I agree with Peter's comments on this point. What do you think of the revision that was run against 1.30.0 sources - http://www.meta-comm.com/engineering/resources/boost_1_30_0/user_summary_pag e.html? > > >> ...Indicators of various kinds: > >> > >> Don't use background colors as indicators. It just obscure any > >> possible information that the text is trying to indicate. > > > > The first thing I would say is that this and most of other points > > below are highly subjective. I would appreciate if we discuss them > > in a less imperative tone ;). > > Sorry I wasn't trying to sound imperative :-\ But I also thought I > wasn't mentioning anything other than established fact. My comments > are things you'll find in most HTML and typography design books. They definitely make sense as general guidelines (and we are well aware of such), but they are in no way dogmatic. > > >Basically, there is a single (and simple!) idea that both motivates > >using of background colors and suggests the particular scheme, that > >is, that you should be able to determine the status of things by > >just glancing over them. You don't have to read (and, ideally, to > >scroll anything). It's especially important and wanted for the CVS > >health (developer) report, which normally should be a full green > >field. We are not pioneers here - see Built Bot > >(http://twistedmatrix.com/~warner.twistd/) or Mozilla > reports, - nor we think we are picking up a bad practice. > > You don't need background color to do what you intend. We believe in our case the background color is the most effective way to show what we want to show. Everything else gives a more cluttered and less comprehensible picture. > I looked at the above pointer and I think the use of background colors > in that sample are also unjustified. Well, we differ in that, then. > But I guess this is a put up or shut up ;-) So here's a reformulation, > style wise, of the user summaray page which I think shows the same > information in a considerably more readable form without loosing the > ability to glance at the results... > > http://redshift-software.com/~grafik/boost-regression/user_summary_page.html > I would say it looks OK, but it doesn't even come close in clearness to this - http://www.meta-comm.com/engineering/resources/boost_1_30_0/user_summary_pag e.html IMO, of course. > >> Even though you did use different terms for the non-working > >> indicator in the user page, the ones you chose are again equivalent; > >> "doesn't work" has the same meaning as "broken". > > > >IMO it doesn't, and the legend tries to explain the difference. > > It's not enough for the legend to explain it. As far as Eglish usage > is concerned they are synonyms. OK, you have a point. The new summary doesn't have either :) - see my reply to Peter. [..] > > >> Unless the number of libraries get's really large, there's > >> no point in having the column labels at the bottom of the table. > > > >It's already large enough to not fit into my screen. Even if you > >have a huge monitor, it doesn't hurt having those, does it? > > OK, understood. Using the more standard header repetition at regular > intercals seems like a possibility. Again see the link. Yep, we considered it. It's not bad, although it does of breaks the picture into pieces a little bit. We plan to implement it some day when the table gets really big. > > >> That alignment also applies to the cell content. Sticking to the > >> language standards (English) for this makes it easier on the reader. > > > >Strongly disagree, here. I definitely want to see the status > centered. > > Well you'll have to tell me if it works on the version I made ;-) It does, but then everything else on your page is different too ;), and a general conclusion among my teammates involved into this project is that our version conveys things better. Thanks for your comments, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Experimental audience-targeted regression results
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 see
> > below). Or, rather, if it still is, then it's the status that is too
> > intimidating, not the report :).
>
> I'm not sure I agree here. The problem is that the user summary says:
>
> Red status basically means that you won't be able to use
> the library.
>
> This is often simply not true.
>
> You do provide me with the tools to eliminate a false red status, but
> this is a "guilty unless proven otherwise" approach; pretty much
> everyone can easily run the regression tests on various broken
> configurations and it is up to me to hunt down every "non-critical"
> failure _and_ extract the relevant toolset name. In the meantime users
> have already rejected the library on the basis of that little red
> rectangle.
You have a point, here. Please note two things, though:
1) Everyone is free to run the regression tests on whatever
configurations they like - since they cannot upload the results, it
doesn't matter. For those who can and do uploads them, we definitely
need to agree on "approved" configurations and toolset names - and the
runner is responsible for making sure that things are not mis-configured.
2) _No matter_ in what format the regression results are reported, it's
simply wrong to send a user to a page reflecting the current CVS state.
Besides the fact that an overwhelming percent of users use, and want to
see the status of the released distributions only, showing them the main
trunk state is also misleading and harmful. While it shouldn't happen too
often, in practice the main trunk is badly broken at least once a week,
and looking at the pile of whatever-color-they-are "fail" cells against
the library tests carries the exact danger that you are worried about.
Having said that, I completely agree that we need to be careful not to
intimidate the user.
>
> Note also that Beman's intel-win32 toolset passed shared_ptr_test but
> your intel-win32 toolset did not, and I can't distinguish the two in
> expected_results.xml.
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 to stick
to.
>
> In short, I think that this approach will result in more relaxed,
> "common denominator" tests, where any failure indeed "basically means
> that you won't be able to use the library". A failure in
> shared_ptr_test (but not in smart_ptr_test) _usually_ means that there
> are some obscure corner cases where this compiler/configuration is
> buggy. A failure in bind_test usually means that you may or may not be
> able to use bind depending on the complexity of the bind expression and
> the phase of the moon _but_ if it compiles it typically runs fine. ;-)
>
> I'm not sure how this can be avoided, but - a hypothetical example -
> if a library passes 29 out of its 30 tests, "BROKEN" simply doesn't
> seem appropriate. I'd also like to see some kind of per-test tagging
> ("brokenness weight") and not per-toolset tagging as the toolset name
> is unreliable.
>
> A way for the test executable to signal "only non-critical
> tests failed" may help, too.
>
> I realize I'm basically reiterating what you wrote in your earlier
> message... I guess the reason is that the system as it stands
> doesn't really accomplish its goals, or I may be misunderstanding how
> it is supposed to work.
Thanks for your thoughts. Here's our current understanding of the whole
thing:
1) Users should be presented with a report against the last official
distribution available for the download.
2) The users report should be conservative in terms of reporting whether
something works or not. Since there is no reliable way to say that for
sure, the most we can do is to provide the users with an easy way to
figure out that for themselves. Summary report is a must, of course.
3) It still makes sense to provide a daily user report against the
current CVS to be able to see how things are going to look as we are
getting closer to the next release.
Turning these into something real, here is our new user report against
the 1.30.0 distribution -
http://www.meta-comm.com/engineering/resources/boost_1_30_0/
RE: [boost] Re: Experimental audience-targeted regression results
Gennaro Prota wrote: > >> More importantly instead, would it be possible to also have a sign > >> indicating regressions? A little gif comes to mind, but even > >> something as simple as an asterisk could be ok. > > > > Hmm, I am not sure I understand what we are talking about here. > > Anyway, ultimately, the developer summary page is supposed to serve > > as a regressions indicator, but for it to work every library author > > need to go through the trouble of specifying the expected failures > > and fixing everything else. > > What I was thinking to is an "automatic" indicator that the result of > a test is different from the previous running or from a "reference > running" (especially when it is worse ;-)). Well, check out the latest developer report - http://boost.sourceforge.net/regression-logs/developer_summary_page.html! The expected failures are taken directly from a tests run on the 1.30.0 snapshot, therefore it shows how we've been doing in keeping the CVS healthy since then. Ideally, we shouldn't release at least until all regressions on this one are cleared. > In practice, I guess, it isn't easy to remember whether for compiler xyz > on platform abc a given library was already failing or not, especially > for those who are authors of several libraries. Yep, and that's exactly what expected failures specifications are for. > Or is it just me and you, guys, all remember such things? :-O Well, I do remember since for MPL it's only a couple of failures, but I still prefer to be able to point to a red cell and say - "see, you broke that" :) Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Experimental audience-targeted regression results
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://boost.sourceforge.net/regression-logs/developer_summar > y_page.html > > > >Please comment! > > On content... > > The summary at the library level is good. But it has one drawback. > If I looked at that table as a user, I would give up in short order > to use Boost at all. It just looks like it's mostly broken. Partially it's due to a misconfigured 'como-win32' toolset setup, and partially because at the moment MPL is the only library with specified expected failures. As more and more libraries will have those, the report will reflect the actual status quo. > So > having what is essentially a binary indicator is misleading. As long as it reports things correctly, it's not. > Parhaps > an indication of how much works and doesn't is more informative to a > user (and developer). Knowing the difference between 1 failure vs. > 50 failures is most times more important. After all many times as a > user I may not need the funcitonality that is failing. And having > just a works/fails discourages further investigation as to what parts > do and don't work. See http://article.gmane.org/gmane.comp.lib.boost.devel/20648 for the discussion on this exact topic. > The results page makes more sense to me than the summary page. Having > the seemingly binary indicator here is OK. > > On HTML/style... > > You really need to work on the HTML. The result pages do strange > overlapping text in some browsers. If you expect the background and > text colors to be a certain way, PLEASE put that in the HTML. My > non-white default background makes the pages look less than > flattering. Yeah, can imagine :). We'll fix these in the next revision. > > ...Indicators of various kinds: > > Don't use background colors as indicators. It just obscure any > possible information that the text is trying to indicate. The first thing I would say is that this and most of other points below are highly subjective. I would appreciate if we discuss them in a less imperative tone ;). Basically, there is a single (and simple!) idea that both motivates using of background colors and suggests the particular scheme, that is, that you should be able to determine the status of things by just glancing over them. You don't have to read (and, ideally, to scroll anything). It's especially important and wanted for the CVS health (developer) report, which normally should be a full green field. We are not pioneers here - see Built Bot (http://twistedmatrix.com/~warner.twistd/) or Mozilla reports, - nor we think we are picking up a bad practice. > And to say nothing about color-blind contention. Stick to using > background colors to delineate sections, or in place of rulers (as in > table borders). > > If you see the need to use an indicator other than text stick to using > shapes. For example you could replace the red/green indicators with X > and + icons, respectively. Using color on the icons then has the same > effect you have now but without the clutter, and without overly relying > on color. > > Be more informative in the text indicators. Using "OK" and "OK*" as > different indicators just looses any meaning that each may have on > thei own. They both look just the same to me. Suggestion use "Supported" > and "Partial". They are close to be the same from a user standpoint, but I like your suggestion. Only those are too long :(. > Even though you did use different terms for the non-working indicator > in the user page, the ones you chose are again equivalent; "doesn't work" > has the same meaning as "broken". IMO it doesn't, and the legend tries to explain the difference. > Pick something that conveys the intended meaning better. In this case: > "Unsupported"/"Fails" seems more appropriate IMO. Not bad, too, but again, too long. It's important to keep the table compact. Any other suggestions? > > The developer summary has one serious problem. You have two OK > indicators for different things. The dark green OK is just wrong. Nope, it's not :). > If a test is supposed to not-succeed having it succeed is a failure. > Or is there some other meaning you intended? A test will be marked as dark green if it was known to fail on the particular toolset, given up upon, specified as a known failure (probably even
RE: [boost] Re: Experimental audience-targeted regression results
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://boost.sourceforge.net/regression-logs/developer_summary >> _page.html > > > > Please comment! > > This is very nice! Thanks! > However: > 1. The developer_result_page.html as well as the user page are rendered > incorrectly, both in Konqueror and Mozillaa. The first table (for "any") is > drawn in the middile of table of content, overlaying it. Thanks for the report, we will look into it. > 2. The way results are computed, and how to inperpret them is still not > clear. For example, I see that "function" is "broken" on borland and mingw. > If I were just a user, I'd give up and resort to function pointers. > But in fact, mingw only fails a single test, so it's basically usable. > Borland fails many more tests, but it works good enough still to allow > program_options library to pass all it's own tests. Yep. Reporting green in these cases is crucial for the user report to be fulfill its promise (and it was one of the goals right from the beginning - http://article.gmane.org/gmane.comp.lib.boost.devel/20648). They _will be_ reported green as soon as somebody with enough knowledge about which tests are critical and which are not will specify it. > Probably, library authors should have a way to specify "critical tests". If > they don't pass, the library is broken. If some other test fails, it's > "partially working". Yep, that's the idea. Specifying the failures is as simple as putting an "expected_results.xml" file into the library's "test" directory: Thanks for the comments, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Experimental audience-targeted regression results
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 > > * developer summary page - > > > http://boost.sourceforge.net/regression-logs/developer_summary > _page.html > > > > Please comment! > > Nice :-) Thank you! > I particularly like the fact that they are organized by > library, rather than by platforms as were the latest regression logs I > have seen. Well, actually at the moment these are for a single platform only (win32). Having the most recent results for each platform collected into a nice single summary table is something that I hope somebody will address further down the road. > Personally I would like the green fail (in the developer summary) to > read 'expected fail', for instance (or an abbreviation, such as 'exp. > fail'). I'm the kind of guy that when faced with a 'fail' in a green > cell begins wondering whether there was an error in the script :-) Understand the sentiment; 'exp. fail' is not bad at all, IMO. > Also, since 'doesn't work' and 'broken' (in the user summary) are > practically synonyms, I would simply use a dash or an empty cell > instead of the former. Uhm, they are not, though! 'broken' on the user summary page indicates that _the current_ CVS state is broken, probably to somebody's erroneous checkin, but, as its legend says, that doesn't at all mean that the library is not usable on that compiler. Basically it says "if you get me know, I won't compile". As soon as the regression is fixed, all broken statuses will become "OK" or "OK*". "doesn't work" means, well, doesn't work, permanently. > But these are really minor points. > > More importantly instead, would it be possible to also have a sign > indicating regressions? A little gif comes to mind, but even something > as simple as an asterisk could be ok. Hmm, I am not sure I understand what we are talking about here. Anyway, ultimately, the developer summary page is supposed to serve as a regressions indicator, but for it to work every library author need to go through the trouble of specifying the expected failures and fixing everything else. Thanks for the thoughts, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Experimental audience-targeted regression results
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://boost.sourceforge.net/regression-logs/developer_summary > _page.html > > > > Please comment! > > Your como-win32 installation is still broken, it seems. Yeah, kind of. Since it's unfair to report any results under these conditions, and we don't have resources to solve the issue at the moment, for the time being Comeau C++ is excluded from the experimental run. > 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 see below). Or, rather, if it still is, then it's the status that is too intimidating, not the report :). > esp. in cases where the library actually works > (everything/como-win32, smart_ptr/intel-win32) but the tests fail for > various obscure reasons (setup issues, nonstandard auto_ptr). I wholeheartedly agree it's important to show green when the library actually works. I was the one who argued for it in the first place :) - once again, see http://article.gmane.org/gmane.comp.lib.boost.devel/20648. If some failures are not really indicative of the library's status, the user summary report will happily show you a green "OK*" thingy - given that the library author specified that these tests are expected to fail for the particular toolset and that the failures are non-critical. The paragraph at the top of http://boost.sourceforge.net/regression-logs/user_result_page.html tries to explain how to do that. Specifying the expected failures will also clear the corresponding reds from the developer pages, bringing it closer to the state when one can use the summary report to monitor new regressions. As for the setup issues, when you have those, you shouldn't publish the results until you solve them. We are guilty we did. Thanks for the comments, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Experimental audience-targeted regression results
... 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 comment! Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: como-win32 toolset help needed
[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 - http://article.gmane.org/gmane.comp.lib.boost.devel/20648. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] mpl size::type varies across compilers
Hugo Duncan wrote: > Aleksey and all, Hi Hugo, > > mpl::size returns integral_c on gcc, vc7.1 but > integral_c on bcc564. > > Is this intentional? Nope, it's a bug. Fixed in the main trunk. Thanks for the report, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Bug: mpl::is_sequence (on MSVC7, at least)
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 certainly seems to be some > problem with class templates from namespace std. (The problem likely > extends to other types in other namespaces, and perhaps other > compilers, but I have not investigated the issue thoroughly enough.) Nope, it doesn't have anything to do with namespaces, see the above. The affected compilers are MSVC 6.5 and 7.0. > > In particular, this is posing a problem for me in incorporating variant > into the next Boost release. Is this a known problem? Nope, it wasn't. > Any insight welcome. Fixed in the CVS. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Command Line & Config review results
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, and > > Completely agree. > > > b) resolving the 'wchar_t' support issue before the library makes > >into official Boost distribution. > > I'm actually not that happy about solving general issue alone... You don't have to. I am sure a lot of people on this list have dealt with the issue and would be happy to help you out. > but let it be. I assume I've not asked to implement any specific > approach, and can decide myself? I think the general conclusion was that one should be able to use both 'char' and 'wchar_t' versions of the library facilities in the same program. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Command Line & Config review results
The Command Line & Config library by Vladimir Prus has been accepted into Boost, pending the incorporation of suggestions brought up in the review. Thanks to everyone for all their comments, and to Vladimir for being open and responsive to them! 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, and b) resolving the 'wchar_t' support issue before the library makes into official Boost distribution. Also, as acting on the review comments should result in large number of interface and design changes, I suggest that after incorporating them in the library and before the public release the author posts a note to the list so that the interested parties have a chance 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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Command Line & Config review comes to an end
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/listinfo.cgi/boost
Re: [boost] Preliminary submission: Finite State Machine framework
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: > > http://groups.yahoo.com/group/boost/files/FSM/ > > There is comprehensive tutorial and rationale documentation. All code > has been tested with MSVC7.1 and boost 1.30.0 > > Features include: > > - Straightforward transformation from UML state chart to executable > C++ code and vice versa > - Comprehensive UML semantics support: >- Hierarchical (composite, nested) states >- Orthogonal (concurrent) states >- Entry-, exit- and transition-actions >- Guards >- Event deferral > - Error handling support > - Full type-safety > - State-local storage > - Customizable resource management It's very exciting to see a FSM framework coming close to the formal submission stage! IMO state machines are something that every software engineer should be famililiar with, because no matter what kind of software you write, if there is any significant amount of logic in it, FSMs can offer you the means to structure and simplify it, improve its adaptability to changes, and ultimately make it more understandable, robust, and easier to maintain, debug, and verify. That is, if you have a tool at hand that makes implementing FSMs as easy and enjoyable as it should be. So, while here at work we have developed an in-house technology that achieves that goal for small-to-medium FSMs (the first prototype of which is outlined in the MPL paper), I am really looking forward to studying experts' work on the subject. Well, meanwhile, besides the above, my first comment is going to be really minor - I browsed over the tutorial (which looks great!), and although I am sure you know it, I thought it would be worth to point out that the 'public' specifier is redundant when the derived class is declared as 'struct'; if you omit those, the examples' syntax would become even more DSL-like (== better :). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL regression tests?
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 the > reporting side of the equation. Perhaps with an intermediate web page > that collapses all a library's tests down to one line. Rene's > summary page shows that a relatively small organization effort can > make reporting much more accessible. > > Ideas appreciated. IMO it's worth to step back and try to answer a couple of "big picture" questions: 1) What are the target audiences for the regression test results? 2) What kind of information these audiences are looking to find in there? Answering these is actually simple - first, as usual, there are two primary audiences here - boost users and boost developers. Now, IMO, when going to the regression results page, these two groups are looking for the answers on quite different questions. I would argue that for a user _the_ dominant motive to study the regression results is to find out whether a particular library works on a particular compiler(s) she uses. What's tricky about it is that often "works" doesn't necessarily equals to "all tests are passing". It's quite common for a library to fail a few corner-case tests, tests of seldom-used functionality, or advanced functionality that demand a high standard conformance, and yet in practice be perfectly usable with many of those compilers. As a matter of fact, if you analyze the current compiler status table for, let's say MSVC 6.5, you will see that _most_ of the boost libraries fall into this "works with caveats" category. Well, except that if you are indeed a user, you don't know that because when looking at the particular tests' failures you have no idea whether these are show stoppers or not, and if not, what do the failures _mean_, in user-level terms. And then of course, even if the tests did provide you with that information, you don't want to browse through several pages of them collecting everything together to make the conclusion. IMO, ultimately, the perfect user report should be a table filled with nice green and red cells on library/compiler crossings which simply said "works", "doesn't work", or "works with caveats" and linked to a more detailed report, still in the user-level terms (something like "pass", "fail, feature X is not available", or "fail, show stopper" for every standalone library test). Now, that was a user position. If you wearing the developer's hat, though, you are not really interested whether a particular library works on a certain compiler; or, rather, you already know it because you are the library author. Instead, here, the primary reason to check regressions results is to make sure that none of the recent changes in the CVS lead to, well, regression in the library's functionality (or better yet, to be automatically notified if this happens). The failures that are known are not nearly as interesting to you as a change in the failures pattern. And just like the user, you don't want to gather this information from pieces. Basically, you want the same field of green/red cells as a user, one row per library, only in this case green would mean "nothing's broken" (comparing to expected failures picture), and red would mean "somebody broke something". Ideally, red on the developers' report would be a quite rare event. Well, anyway, that was my take. I haven't thought through how exactly something like this can be implemented so it's both easy to setup and maintain (per library, especially the user-oriented report), and yet indeed satisfactorily informative. We plan to use MPL as a test-bed for these ideas to see how things work out. Any comments are welcome :). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL regression tests?
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 besides, although not systematic, the tests do cover most of the library's functionality. As Beman already replied, the reason they are not included into the main boost regression run is two-fold - first, due to a large number of tests and the current format of the compiler status table it would make the latter even more uninformative, to the point of being useless (for a human reader, at least). Secondly, many tests are compile-time intensive (and some compilers are notoriously slow with templates), which for a typical regression run on 8-10 compilers means about an hour of additional time. Unless regressions are run on a standalone designated machine, it can be too much. That's not to say that the situation is not going to improve, though - here at Meta we have enough computation resources that the last issue can be ignored, and solving the first one is on our to-do list (we are already running regular nightly regressions - http://boost.sourceforge.net/regression-logs/cs-win32_metacomm.html). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] patch for boost/mpl/joint_view.hpp
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 these typedefs being private - but then the whole #ifdef section needs to be removed as well. I did both and commited it. Thanks for the report, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: CVS status
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 still > running their cron jobs.) > > That is supposed to protect us from total failure, such as > SourceForge going bankrupt and shutting down unexpectedly. > > But it isn't clear what the best procedure is to protect against > partial failure - it seemed easier just to restore file-by-file in > this particular case. Sure, if the files content indeed makes sense. I would characterize our case as malfunctioning with the possible result of the bogus content; in this situation, plain content backup, whether it's intentional or accidental, tarball or separate files, is not a reliable source to restore from. We just happened to be lucky this time (if John will be able to restore his branch). I think Vladimir's suggestion makes sense and is worth doing. It covers what plain backups cannot, and costs nothing in terms of maintenance. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MPL CVS still bustificated?
David Abrahams wrote: > > the following fails to compile. Should it? > > -- > > #include > #include > > namespace mpl = boost::mpl; > typedef mpl::vector v10; > typedef mpl::push_back::type v11; > Contrary to what the docs say, no. Please see http://groups.yahoo.com/group/Boost-Users/message/3852. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [type-traits] Patch to alignment_of.hpp for Sun compiler
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 happening with > type_with_alignment_test, I'll be looking into that next). > > While this hides some gross inadequecies of the Sun compiler, We weren't trying to highlight those :), rather to determine if the code in question needs patching regardless of whether Sun can handle or not. It doesn't, so... > I'm all in > favor of getting Boost to compile reliably for users of this platform. > Can someone make this change to the Sun config? Done. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: CVS status
Gennaro Prota wrote: > Thanks Aleksey. I was particularly interested to stlport.hpp > (incidentally: though that doesn't affect the good functioning of the > file, the space between # and endif: > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/boost/config/stdl ib/stlport.hpp.diff?r1=1.19&r2=1.20 > > surprises me a bit. Don't call me pedantic, but I'm a curious one :-) > I had seen the colored diff before and didn't notice it. Note that > without the space the line shown in green is, I guess, the following > one, so that's unlikely to get unnoticed when you visually try to > match the #if-s) Have no idea about it. I just restored the copy of the 1.20 revision laying on my hard drive. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] CVS status
John Maddock wrote: > That would be a big help - I have about a dozen changes to the regex-4 > branch that have been lost - and I haven't even begun to figure these out > yet :-( Just in case if you missed it - we have an option of getting access to the 2003-05-07 backup: > Additionally: > If you would like access to the backups from 2003-05-03 (known stable), > 2003-05-06/2003-05-07 (made before your repository was restored to > the known state from 2003-05-03), please let us know; if you believe > (based on work in the past few days) that your repository is generally > clean, we can restore the repository to its state as of this morning > and selectively use the 2003-05-03 backup to fill in any gaps/corruption > that you detect. Please let us know if we may be of further assistance > in this matter. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] CVS status
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 collectively we've been able to restore everything. Still, if we have resources for that, may be it's worthy to set up a backup job somewhere to copy everything off-site, nightly or so - we might not be so lucky next time. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [mpl]gcc and bcc link errors
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] When to use which ETI workaround?
Andreas Huber wrote:
> Hi Aleksey,
Hi Andreas,
Sorry for the late reply, got too many things on my plate.
> I've stumbled over ETI again. Browsing through MPL I have found
> different ways to circumvent it. In my case the following workaround
> seems to be sufficient:
>
> template< class State >
> struct get_context_ptr_type
> {
> typedef typename State::context_ptr_type type;
> };
>
> template<>
> struct get_context_ptr_type< int >
> {
> typedef int type;
> };
>
> I.e. by simply specializing a given metafunction with int.
Yep, in most cases that's enough. It's _always_ enough with MSVC 6.0, but
7.0 sometimes uses another, unknown, type for the instantiation's
placeholder argument, so you cannot simply specialize the template anymore,
but have to use 'is_msvc_eti_arg' predicate instead (which is based on the
knowledge that the type is still int-convertible; most probably it's an
enum), e.g.:
template< class State >
struct get_context_ptr_type_impl
{
typedef typename State::context_ptr_type type;
};
template< class State >
struct get_context_ptr_type
: if_c<
is_msvc_eti_arg::value
, identity
, get_context_ptr_type_impl
>
{
};
> How do you decide when to use which workaround? Have you established
> rules or do you simply work your way through them until one works?
The VC 7.0-specific case is rare enough to always try the 'int'
specialization first (which is obviously less painful than the other), and
then switch to the 'is_msvc_eti_arg'-based workaround if that doesn't help.
VC 7.0 is not our production environment here at work, so I didn't have
enough experience with it to be able to figure out when exactly these cases
occur.
HTH,
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL::lambda on MSVC
Jaap Suter wrote:
> Hi,
Hi Jaap,
>
> I apologize, but once again I'm unable to get a lambda
> expression working with the MPL.
>
> The code works fine with the Intel and GCC compiler. On MSVC I get the
> following error:
>
> error C2039: 'lhs_index' : is not a member of 'boost::mpl::arg'
It's the same problem we dealt with here -
http://lists.boost.org/MailArchives/boost/msg41700.php. The easiest way to
fix it within the current code base would be this:
template< typename T > struct lhs_index_impl
: T::lhs_index
{
};
template< typename T > struct lhs_index
: mpl::if_<
mpl::is_placeholder
, T
, lhs_index_impl
>
{
BOOST_MPL_AUX_LAMBDA_SUPPORT(1,lhs_index,(T))
};
template< typename T > struct rhs_index_impl
: T::rhs_index
{
};
template< typename T > struct rhs_index
: mpl::if_<
mpl::is_placeholder
, T
, rhs_index_impl
>
{
BOOST_MPL_AUX_LAMBDA_SUPPORT(1,rhs_index,(T))
};
template < class Signature, class LhsIndex, class RhsIndex >
struct predicate
{
typedef typename mpl::and_<
typename mpl::equal_to<
typename lhs_index::type, LhsIndex
>::type,
typename mpl::equal_to<
typename rhs_index::type, RhsIndex
>::type
>::type type;
BOOST_MPL_AUX_LAMBDA_SUPPORT( 3,
predicate, (Signature, LhsIndex, RhsIndex) )
};
// Test code:
typedef mpl::vector< signature< 1, 1, 1 >,
signature< 4, 4, 0 >,
signature< 5, 5, 0 >,
signature< 4, 5, 1 > > signatures;
typedef mpl::find_if<
signatures,
predicate<
mpl::_1,
mpl::size_t< 4 >,
mpl::size_t< 5 >
>
>::type iter_0;
That's not to say that it's something obvious and easy to figure out - I'll
look if there is a simple way to workaround the compiler's deficiency that
doesn't have this idiosyncrasy.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Doing sets with the MPL
Jaap Suter wrote:
> Hi,
Hi Jaap,
>
> In some of my MPL-using code I needed set-based functionality. So I wrote
a
> function that does an insertion into an ordered list of constants.
However,
> it seems that if I compare a list created from a bunch of constants to an
> explicit list, they don't end up the same. I've attached the example code
> below.
[snip]
> template < class N, class L >
> struct add_to_sorted_list
> {
> typedef typename mpl::if_<
> typename mpl::contains< L, N >::type,
> L,
> typename mpl::insert< L,
> typename mpl::lower_bound< L,
> N,
> mpl::less< mpl::_, mpl::_ >
> >::type,
> N
> >::type
> >::type type;
> };
>
> typedef mpl::list_c< int, 0, 1, 2, 3 > list0;
> typedef mpl::list_c< int, 0, 1, 3 > list1;
> typedef add_to_sorted_list<
> mpl::integral_c< int, 2 >,
> list1,
> >::type result;
>
> BOOST_STATIC_ASSERT( is_same< list0, result >::value ); // THIS FAILS;
The lists _are_ the same, content-wise, and that's what you actually should
be checking for:
BOOST_STATIC_ASSERT(( mpl::equal< list0, result >::type::value ));
Test for two sequences having the same C++ type isn't guaranteed to work, as
any manipulation of sequence content changes the sequence's type, and often
it's not worthy to maintain invariants along the lines of this one:
typedef list_c l0;
typedef list_c l1;
typedef push_front >::type res;
BOOST_STATIC_ASSERT((is_same::value)); // most probably fails
If an analogy can help here, in some sense comparing for type equality
instead of content equality is somewhat similar to writing
std::vector v1;
std::vector v2;
assert(&v1 == &v2);
instead of
assert(v1 == v2);
HTH,
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: RC_1_30_0 still broken (apologies and help!)
Daniel Frey wrote: > I'm still wondering what happened. Please check everything what I say, > as I already made too many errors wrt type-traits: > > John added the test for is_function to the code that was intended for > compilers that don't have partial specialization - which is why it > failed as is_function needs partial specialization to work with > references. But is_class also calls is_reference, so it seems that > this does work, thus I think an implementation could be possible. Most probably. I know that the last time I looked into it (which was right before the 1.29 release) there were some subtleties which I wasn't ready to deal with, not the least because the timing was wrong as well. Don't get me wrong, I would love to see it fixed, just not in 1.30.0. > But there is another point: AFAIK the GCC does support partial > specialization, right? Of course. > Given that this is true, the change in CVS can't fix something > (as it is not used for the GCC) It wasn't supposed to. > or the config for the GCC is broken - or I missed something obvious > (again) :-} Even if we don't take the last point into account as it > was maybe just an overlook from John when he accidentially committed > the code to CVS, That's exactly what happened. > it's still the question whether is_function could be "fixed" given > that is_reference seems to be available for compilers without partial > specialization. Sure. By all means it would be appreciated if someone contributed a comprehensive fix which would close the issue. > > If it was easy enough it would be fixed long before the release. In > > any case, I would be strongly opposite to sticking in a new > > implementation just now. It's bad enough "the patch" got us delayed > >for more than a day. > > I don't really wanted to suppose changes that defer the 1.30.0, I just > tried to find a way to work around the lock-problem of SourceForge. Okay, that's good to hear :), sorry if I overreacted a bit. 1.30.0 preparation period has lasted long enough for some of us to want it to be over already. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: RC_1_30_0 still broken (apologies and help!)
Daniel Frey wrote: > > Still looks broken over here: > > > > http://cci.lbl.gov/boost/results/1047901021/dailylog_win32_vc60 > > I think it's OK to revert the patch to get 1.30.0 out, Which patch? John said the changes that caused the disturbance were never intended to be checked in. > but for the > future, I think we should keep in mind that it's actually is_function > that is broken and needs to be fixed AFAICS. It's not "broken", it doesn't work for reference types on compilers without partial template specialization because at the time it wasn't clear how to make it work. If you have an implementation in mind that would perform better, please post it. > The patch to is_class would work if is_function could be called with > a reference, so I think it's worth to consider fixing is_function. As > John is the expert, I think he can decide whether it's better to wait > for the SourceForge-folks to fix he lock-problem or if it's easy > enought (and thus faster) to fix is_function... If it was easy enough it would be fixed long before the release. In any case, I would be strongly opposite to sticking in a new implementation just now. It's bad enough "the patch" got us delayed for more than a day. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RC_1_30_0 still broken (apologies and help!)
Aleksey Gurtovoy wrote: > Oh, I see. But wait, it seems that it's still there - I can > update from the CVS, but I cannot check in the fix: > > cvs server: [18:53:47] waiting for johnmaddock's lock in > /cvsroot/boost/boost/boost/type_traits FYI, I submitted a SourceForge support request on it. Probably it won't be fixed before Monday morning, though (US time). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RC_1_30_0 still broken (apologies and help!)
Beman Dawes wrote: > At 09:20 PM 3/16/2003, Aleksey Gurtovoy wrote: > > >Beman Dawes wrote: > >> Both the main trunk and RC_1_30_0 are working fine for me as > >> of Sunday 6PM US Eastern time. > > I was unclear; the CVS lock problem was cleared, not the > is_class problems. Oh, I see. But wait, it seems that it's still there - I can update from the CVS, but I cannot check in the fix: cvs server: [18:53:47] waiting for johnmaddock's lock in /cvsroot/boost/boost/boost/type_traits Any ideas what to do about this? Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] 1.30.0 Outstanding patches and fixes - Sunday night update
Beman Dawes wrote: > Here is the current list. The second and third items look to me like > showstoppers. They are. Aleksey > * [Boost.Regex] [PATCH] Fix GCC 3.3 warnings from Lars Gullik Bjønnes. > Awaiting response from John Maddock. > (Since this one just eliminates warnings, the release > won't be held > for it.) > > * [type_traits] is_class.hpp problems > Awaiting response from John Maddock. > > * [type_traits] is_polymorphic_test and stateless_test failures. > Awaiting response from John Maddock. > > --- end --- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RC_1_30_0 still broken (apologies and help!)
Beman Dawes wrote: > Both the main trunk and RC_1_30_0 are working fine for me as > of Sunday 6PM US Eastern time. If you look into error messages for 'is_class_test.cpp' on MSVC 6.5/7.0, you'll see that they are not; the new failures are getting masked by the fact that earlier the test failed at run-time, so it's not getting highlighted as a regression. > Today's Win32 RC_1_30_0 regression tests (just posted) are > showing new fails for VC++ 6 and VC++ 7 on is_polymorphic_test and > is_reference_test. > Are these related to the is_class problem? Yes. We need to revert 'is_class.hpp' to the 1.5 revision, both in the main trunk and in the release branch. I am not sure what's the right way to do that, though. I don't think we need to keep the erroneous version in the history, although it's probably not a big deal. Could our CVS experts advice on the situation? Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: RC_1_30_0 still broken (apologies and help!)
Andreas Huber wrote: > Beman & John, > > > Both the main trunk and RC_1_30_0 are working fine for me > as of Sunday 6PM > > US Eastern time. > > Douglas Gregor has already fixed the is_class.hpp problem, please see > > http://lists.boost.org/MailArchives/boost/msg45230.php That's not the problem that caused the failures Ralf reported; it's the addition of the line "::boost::type_traits::ice_not< ::boost::is_function::value >::value" itself, not the missing comma, that is wrong and needs to be reverted. > > > Today's Win32 RC_1_30_0 regression tests (just posted) are > > showing new fails for VC++ 6 and VC++ 7 on is_polymorphic_test > > and is_reference_test. > > Are these related to the is_class problem? > > I don't think so, is_class.hpp is working just fine for me > now with CVS state from 2 hours ago... I don't see how can it. That's what I get when I compile 'is_class_test.cpp' on MSVC 6.5 (expectedly): Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. is_class_test.cpp F:\cvs_RC_1_30_0\boost\boost/type_traits/is_function.hpp(68) : error C2528: '' : pointer to reference is illegal F:\cvs_RC_1_30_0\boost\boost/type_traits/is_function.hpp(79) : see reference to class template instantiation 'boost::detail::is_function_impl' being compiled F:\cvs_RC_1_30_0\boost\boost/type_traits/is_class.hpp(67) : see reference to class template instantiation 'boost::is_function' being compiled F:\cvs_RC_1_30_0\boost\boost/type_traits/is_class.hpp(82) : see reference to class template instantiation 'boost::detail::is_class_impl' being compiled F:\cvs_RC_1_30_0\boost\libs\type_traits\test\is_class_test.cpp(19) : see reference to class template instantiation 'boost::is_class' being compiled F:\cvs_RC_1_30_0\boost\boost/type_traits/is_function.hpp(68) : error C2528: '' : pointer to reference is illegal F:\cvs_RC_1_30_0\boost\boost/type_traits/is_function.hpp(79) : see reference to class template instantiation 'boost::detail::is_function_impl' being compiled F:\cvs_RC_1_30_0\boost\boost/type_traits/is_class.hpp(67) : see reference to class template instantiation 'boost::is_function' being compiled F:\cvs_RC_1_30_0\boost\boost/type_traits/is_class.hpp(82) : see reference to class template instantiation 'boost::detail::is_class_impl' being compiled F:\cvs_RC_1_30_0\boost\libs\type_traits\test\is_class_test.cpp(38) : see reference to class template instantiation 'boost::is_class' being compiled I am going revert 'is_class.hpp' to the 1.5 revision. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
