[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] 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: 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] 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
[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
[boost] bind/lambda - unsupported use case?
Consider the following snippet:
void show_warning( message_dialog const, user_message );
void post_command( boost::functionvoid() );
int main()
{
boost::functionvoid( user_message ) f(
bind( post_command
, ( bind( show_warning, 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
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_ptrstate 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
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?
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: 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
[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?
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
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?
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: [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
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
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
[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
[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
[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?
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?
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: [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_ptrint, my_policy_, my_other_policy_ p; to this: smart_ptrint, my_policy, my_other_policy 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 lambdaPolicy::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?
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] 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?
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] 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] 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::functionvoid() );
int main()
{
boost::functionvoid( user_message ) 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::functionvoid( user_message ) f(
boost::bind(
post_show_warning_command
, message_dialog()
, _1
)
);
}
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 typename Sequence, long n
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:
code
template typename Sequence
class rtts_invokerSequence, 3
{
public:
template typename Operator, typename StoragePtr
static
BOOST_DEDUCED_TYPENAME Operator::result_type
invoke(Operator op, StoragePtr storage, long index)
{
switch (index)
{
case 0:
return op(*(static_castmpl::at_cSequence, 0::type
*(storage)));
case 1:
return op(*(static_castmpl::at_cSequence, 1::type
*(storage)));
case 2:
return op(*(static_castmpl::at_cSequence, 2::type
*(storage)));
}
}
};
/code
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_invokermy_seq, 3, the template
machinery should match the above specialization, and the statement,
n_ary_rtts_invokermy_seq, 3::invoke(my_op, storage, index), will make
a
selection among the first three types in 'my_seq' via a switch statement
(assuming 0=index3).
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
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] 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] 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] 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_ptrstate 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_statefoo
{
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] 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 ?
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: 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: 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:
beginnon-sequence-type::type === void_
orderSet,non-existing-key::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... wink).
I don't _agree_ :).
Observe the definition of identity (comments added for exposition
purposes):
templatetypename T = void_
struct identity
{
typedef T type;
};
// identityvoid_ 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 lambdaidentity 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] 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] 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::vectorbool]
enum { numParams = boost::mpl::sizeTypeVector::type::value };
typedef typename boost::mpl::if_c(numParams 2),
typename boost::mpl::at_cTypeVector, 2::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_cTypeVector, 2,
boost::mpl::identityboost::mpl::void_
::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_cfalse,T1,T2
{
typedef T2 type;
};
template
typename C = void_
, typename T1 = void_
, typename T2 = void_
struct if_
{
private:
typedef if_c
static_castbool(C::value)
, T1
, T2
almost_type_;
public:
typedef typename almost_type_::type type;
};
int main() {
typedef if_true_, double, int::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_castbool(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_traitsint
{
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] 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] 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] 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] 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] 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] 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 mode boost_root [source_file] 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
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] 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] 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
[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
[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 mode boost_root [source_file] 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
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/user_summary_pag e.html The one against the main trunk - with the expected failures automatically extracted from the 1.30.0 results - is available here: http://boost.sourceforge.net/regression-logs/user_summary_page.html I would say we need to eliminate the reds in the latter before we can release. The per-library developer summary is great, though. ;-) Thank you! Aleksey ___ Unsubscribe other changes
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
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] 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: expected-failures !-- Example: test-result library=mpl test-name=is_sequence toolset=borland showstopper=no / test-result library=mpl test-name=is_sequence toolset=cwpro8 showstopper=no / -- /expected-failures Thanks for the comments, 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 critical one), and then suddenly it starts working. [...] ...Table headers/side bars: 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? Repeating the library/toolset column on the right is more debatable as to it's need. Splitting the table in half, when needed
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
[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] 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
[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] 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] MPL CVS still bustificated?
David Abrahams wrote: the following fails to compile. Should it? -- #include boost/mpl/vector.hpp #include boost/mpl/push_back.hpp namespace mpl = boost::mpl; typedef mpl::vectorint[1], int[2], int[3], int[4], int[5], int[6], int[7], int[8], int[9], int[10] v10; typedef mpl::push_backv10, int[11]::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: 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]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] 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::argN'
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_placeholderT
, T
, lhs_index_implT
{
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_placeholderT
, T
, rhs_index_implT
{
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_indexSignature::type, LhsIndex
::type,
typename mpl::equal_to
typename rhs_indexSignature::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
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_argState::value
, identityint
, get_context_ptr_type_implState
{
};
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
[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_cint,0 l0;
typedef list_cint,1,0 l1;
typedef push_frontl0, int_1 ::type res;
BOOST_STATIC_ASSERT((is_sameres,l1::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::vectorint v1;
std::vectorint 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: 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!)
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] 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!)
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] Outstanding patches and fixes
Beman Dawes wrote: * [config] BOOST_DEDUCED_TYPENAME Status currently unknown. John? Aleksey? Dave will take care of it after the release. It's not urgent in any way. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: PRB with type_traits::is_member_function_pointer
Markus Schöpflin wrote: currently, the is_member_func_test fails for VACPP6 with the following error messages: snip When looking at is_mem_fun_pointer_impl.hpp it looks like the Metrowerks compiler has the same problem. Could anyone please add a check for __IBMCPP__ =600 at line 345 of this file and regenerate it? The fix still seems missing. If anyone can please tell me how to correctly regenerate the file I can fix it on my own. Should be as simple as creating a two-line source file: #define BOOST_TT_PREPROCESSING_MODE #include boost/type_traits/detail/is_mem_fun_pointer_impl.hpp preprocessing it, and replacing //: # by # in the resulting output. Well, that won't give you a drop-in replacement for the original detail/is_mem_fun_pointer_impl.hpp header, of course, but instead a re-generated block of 'is_mem_fun_pointer_impl' specializations to copy paste there. HTH, Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: PRB with type_traits::is_member_function_pointer
Markus Schöpflin wrote: Aleksey, thanks for the instructions. Could you tell me which PP you used to generate the file before? I would like to minimize the diff as much as possible? VC 7.1, IIRC, but it shouldn't matter much because the header uses file iteration PP technique, and for most preprocessors that, in particular, means that the generated lines will appear in the resulting output exactly as they are written in the section marked by / iteration comment - comments and multiple empty lines notwithstanding (MW CodeWarrior is probably the only exception here). Because of the latter, if the preprocessor you are going to use offers something like trim multiple empty lines option, you would probably like to use it. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [mpl] Patch for mpl::aux::msvc_eti_base for MSVC7.0
Andreas Huber wrote: Hi Aleksey Hi Andreas, Sometimes I have to pass an abstract class to mpl::aux::msvc_eti_base. On MSVC7.0 the compiler complains with the following error: d:\Data\boostCvsRoot\boost\boost\mpl\aux_\is_msvc_eti_arg.hpp(48) : error C2259: 'boost::mpl::inherit2T1,T2' : cannot instantiate abstract class ... The following patch to the current CVS version seems to fix this: RCS file: /cvsroot/boost/boost/boost/mpl/aux_/is_msvc_eti_arg.hpp,v retrieving revision 1.1 diff -r1.1 is_msvc_eti_arg.hpp 48c48 static T get(); --- static const T get(); Since T is never cv-qualified or a reference, this should work under all circumstances. Uhmm, actually 'is_msvc_eti_arg' can be used in other contexts, including the ones where T can be everything, and in particular a reference; so, in the long run, we'll have to do something a little bit more sophisticated to fix it, but for now 'T' will do. Fixed in the CVS. P.S. Just to make sure you've seen it: http://lists.boost.org/MailArchives/boost/msg44601.php It's definitely low prio because it's a *warning* appearing only on MSVC7.1. There were two issues there - 'distance' returning an unsigned type, and, as you've pointed out, the 'advance' implementation itself. Both fixed in the CVS now. Thanks for the report, Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Aleksey Gurtovoy wrote: If one of the developers could at least comment on this I might give it another try. Otherwise I estimate it would take me weeks to reverse-engineer what is happening here. Ralf, I will definitely look into it tonight and get back to you. OK, I've checked in a fix into the main trunk (see boost/mpl/aux_/lambda_support.hpp). If you could check if it makes the problem go away, I'll integrate the new version into the release branch. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve wrote: OK, I'll wait for a word from Aleksey. If he is happy I'll heck in the eight patches, both into the trunk and the RC_1_30_0 branch. Yep, they all look good to me. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] 1.30.0 Schedule [was: RC_1_30_0 compile error with SGI MIPSpro Compilers]
Ralf W. Grosse-Kunstleve wrote: I've checked in all my patches. I couldn't fully test the C_1_30_0 branch because Aleksey's recent fixes are not there yet. Aleksey, please let me know when the fixes are available on the branch. They there now. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve wrote:
This requires active participation by the developers. We've spent a
lot of time setting up the auto-builds to enable developers to see
immediately when their changes break portability. We've also made a
major effort cleaning up 1.29.0. That seemed like a good start to me,
but it didn't work out for lack of participation from the developer's
side. So now I am stuck with messages like the one posted before:
cc-3192 CC: ERROR File = zzstrip.cpp, Line = 71667
The nontype boost::mpl::fold_backwardT1, T2, T3,
boost::mpl::arg1::rebind
is not a class template.
static const int arity = 3; typedef Sequence arg1;
typedef State arg2;
typedef BackwardOp arg3; struct rebind; }; template
typename T1,typename
T2,typename T3 struct fold_backwardT1,T2,T3 ::rebind {
template typename
U1,typename U2,typename U3 struct apply : fold_backward
U1,U2,U3 { };
^
If one of the developers could at least comment on this I might give it
another try. Otherwise I estimate it would take me weeks to
reverse-engineer what is happening here.
Ralf, I will definitely look into it tonight and get back to you.
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [config] BOOST_DEDUCED_TYPENAME
David Abrahams wrote:
I was just getting ready to propose a new config macro called
BOOST_ARG_DEPENDENT_TYPENAME based on this test:
struct id { typedef int type; };
template class T struct foo;
template class T
void f(T)
{
typedef footypename T::type y;
}
int main()
{
f(id());
return 0;
}
But it turns out that this test is very similar to the one for
BOOST_DEDUCED_TYPENAME, and in fact it finds the same compiler (VC6).
So I guess the question is, do we currently have the right name for
the test and macro?
If BOOST_DEDUCED_TYPENAME was introduced for the sake of MSVC only (which
seems very likely to be the case), then it was given a wrong name, since
there are lots of other situations, besides the deduced typename context,
when the compiler refuses to accept 'typename', incorrectly - in particular,
the one demonstrated by the above test case. Classifying those situations
and introducing a separate macro for each and every of them just isn't worth
the troubles, in particular because MSVC is the only compiler with such
peculiarity with respect to 'typename' in different contexts; IMO what is
needed in place of such artificial classification is a single macro that
explicitly documents that what is being worked around here is a weird
behavior of one particular compiler, e.g. BOOST_MSVC_TYPENAME or something
like it.
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Glitch with mpl::placeholder(s)?
Andreas Huber wrote: Aleksey just did a big round of renaming before the first official release of MPL (including changes like int_c - int_, and placeholder - placeholders); I believe that placeholder.hpp is obsolete and should have been removed from CVS. In this case we could keep it for backwards-compatibility reasons, but in general that was deemed a bad idea for most names. Ok, then I believe it's better to completely remove placeholder.hpp from CVS. Yep, that was the plan, it's just slipped through. Killed now :). Thanks for the report, Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: More metaprogramming problems with MSVC7.0
Andreas Huber wrote: P.S. Is it a good idea to use mpl::aux::msvc_eti_base on all platforms (on conforming compilers I'd expect it to call mpl::identity) or should I #ifdef my way around it? Yep, it's intentionally written in the way so that you don't have to #ifdef in your code. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: partial proposal
Sorry for confusion, the reply below obviously belongs to a different thread. Aleksey Gurtovoy wrote: Andreas Huber wrote: P.S. Is it a good idea to use mpl::aux::msvc_eti_base on all platforms (on conforming compilers I'd expect it to call mpl::identity) or should I #ifdef my way around it? Yep, it's intentionally written in the way so that you don't have to #ifdef in your code. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: More metaprogramming problems with MSVC7.0
Andreas Huber wrote:
Hi Aleksey all other metaprogramming gurus
Hi Andreas,
The attached code compiles just fine with MSVC7.1 but MSVC7.0 once more
has
its problems. This time I'm quite sure it has nothing to do with MPL,
instead VC7.0 seems to get confused and reports the following:
d:\Data\StopWatch\StopWatch.cpp(58) : error C2516:
'state_base_typeDerived,Context,Transitions,InnerInitial::type' : is not
a
legal base class
According to the docs this error is reported when you try to inherit from
built-in types like int.
If you then remove the 3 first characters of the lines marked with // ***
here ***, the program compiles and you can see in the debugger that the
result returned by the metafunction state_base_type is quite a legal base
class (see type of pWhatever).
Has anyone else ever encountered similar problems with either 7.0 or 6.5?
Yep, it's a known bug called early template instantiation (ETI). It's
briefly described here -
http://lists.boost.org/MailArchives/boost/msg39915.php.
Are there any workarounds?
Sure. In your case, it would be as simple as this:
#include boost/mpl/aux_/msvc_eti_base.hpp
...
template class Derived,
class Context,
class Transitions = empty_list,
class InnerInitial = empty_list
class simple_state : public mpl::aux::msvc_eti_base typename
state_base_type
//
Derived, Context, Transitions, InnerInitial ::type ::type {};
You will need the latest CVS for that, though.
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] boost::bind question
Trey Jackson wrote:
Just started using boost::bind, like it a lot.
I'm playing around with a little work crew,
which just queues up data, then calls the function
on them later.
[...]
I'd like to be able to do something like:
,
| work_crew??? mycrew(bind(X::f, x, _1, _2));
|
| mycrew.add( ?? 9 10 ?? );
| mycrew.add( ?? 42 10 ?? );
| mycrew.add( ?? 29232 10 ?? );
|
| // do work
| mycrew.dowork(); // STILL calls x.f(9, 10), x.f(42,10),
x.f(29232,10)b
`
Where obviously I have to do something special to package up the
arguments to the function object that's been created.
Is it possible without a huge amount of coding?
I was doing something like it recently, so, sure:
#include boost/function.hpp
#include boost/bind.hpp
#include boost/tuple/tuple.hpp
#include boost/tuple/apply.hpp
#include list
using namespace boost;
template class DataType, class FunctionType = boost::function1void,
DataType
class work_crew {
std::listDataType queue_;
FunctionType engine_;
public:
work_crew(FunctionType const tocall);
void add(DataType d) { queue_.push_front(d); };
void dowork()
{
typedef typename std::listDataType::iterator iterator_t;
for (iterator_t iter = queue_.begin(); iter != queue_.end(); ++iter)
tuples::apply(this-engine_, *iter); // here
};
};
struct X {
bool f(int a, int b);
};
X x;
int main()
{
work_crew tuples::tupleint,int, boost::function2void,int,int
mycrew(bind(X::f, x, _1, _2));
mycrew.add( tuples::make_tuple(9, 10) );
mycrew.add( tuples::make_tuple(42, 10) );
mycrew.add( tuples::make_tuple(29232, 10) );
// do work
mycrew.dowork(); // STILL calls x.f(9, 10), x.f(42,10), x.f(29232,10)b
}
With a little bit more of coding and Boost.MPL, you can do even better on
work_crew tuples::tupleint,int, boost::function2void,int,int
mycrew(bind(X::f, x, _1, _2));
line:
work_crew mpl::listint,int mycrew(bind(X::f, x, _1, _2));
but I am not sure if you want to dive into it from the beginning.
The only caveat to the above is that tuple/apply.hpp header is not a part
of the Boost yet. Please see
http://www.mail-archive.com/boost@lists.boost.org/msg05246.html for the
source.
We still have a chance to have the facility in 1.30 release, though (it's a
pure extension of Boost.Tuple library) - but I need to hear from Jaakko on
this one.
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] boost::bind question
Trey Jackson wrote:
template class DataType, class FunctionType =
boost::function1void,
DataType
class work_crew {
std::listDataType queue_;
FunctionType engine_;
public:
work_crew(FunctionType const tocall);
void add(DataType d) { queue_.push_front(d); };
void dowork()
{
typedef typename std::listDataType::iterator iterator_t;
for (iterator_t iter = queue_.begin(); iter !=
queue_.end(); ++iter)
tuples::apply(this-engine_, *iter); // here
};
};
Question: does the above work even if my work_crew is still the
vanilla:
work_crew int, boost::functionvoid, int vanillaCrew();
or would I need
work_crew tuples::tupleint, boost::functionvoid, int
closeToVanillaCrew();
Not as I wrote it. It's a relatively easy to achieve, though -
void dowork()
{
this-do_work(is_tupleDataType());
};
void dowork(mpl::false_c)
{
typedef typename std::listDataType::iterator iterator_t;
for (iterator_t iter = queue_.begin(); iter != queue_.end(); ++iter)
this-engine_(*iter);
}
void dowork(mpl::true_c)
{
typedef typename std::listDataType::iterator iterator_t;
for (iterator_t iter = queue_.begin(); iter != queue_.end(); ++iter)
tuples::apply(this-engine_, *iter);
};
... except that you would have to implement 'is_tuple' yourself. Not a big
deal, but definitely an inconvenience; should be in the library.
- I ask b/c of the 'tuples::apply(...)' portion.
At first glance, it's not clear that
int i;
tuples::apply(this-engine_, i)
would not work (b/c i is not a tuple).
It wouldn't, as it is. It's an interesting question if it should. IMO a
separate function, let's say 'as_tuple' (analogous to MPL's 'as_sequence')
would be a cleaner solution here,
int i;
tuples::apply(this-engine_, tuples::as_tuple(i)); // OK
tupleint ti;
tuples::apply(this-engine_, tuples::as_tuple(ti)); // OK, too
since there are other places there one would like to have this machinery. Of
course, 'tuples::apply' still can do this 'as_tuple' call internally. Right
now I don't have a strong opinion whether it should or not.
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] tuples::apply
Attached is an implementation of 'boost::tuples::apply' function template,
providing one with a possibility of function application on a tuple of
arguments:
#include boost/tuple/tuple.hpp
#include boost/tuple/apply.hpp
using namespace boost;
void f(int, char const*);
int main()
{
char const* text = text;
tuples::apply(f, make_tuple(5, text)); // here
}
For those who knows Python, it's an equivalent of Python's built-in 'apply'
function.
IMO it's one of the fundamental tuple facilities, and I would love to
contribute it to the Boost.Tuple library, if it's welcome. Jaakko?
Aleksey
apply.hpp
Description: Binary data
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
