November 2008 - Boost - lists.preview.boost.org

[unordered] Buffered functions?
by David Abrahams 29 Dec '08

29 Dec '08

Hi all, Can someone please explain why the unordered containers store two copies of the hash and equality functions, and why they aren't using compressed_pair to take advantage of the EBO for these? Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

6 21

Tests are a mess
by Gennaro Prota 23 Dec '08

23 Dec '08

Few questions: * BGD-Ubuntu is among tested platforms for release, but not for trunk. How is a poor fellow supposed to test on trunk first? * Same as above for BGD-Windows, with the fellow getting poorer and poorer * Are RW_WinXP_VC and RW_WinXP_VCrtl the same? * Can anyone please have a look at the trunk failures for HP-UX_ia64_aCC? For a bunch of libraries I've looked at it gives an Unsatisfied symbol "boost::exception_detail::refcount_ptr<..." What's that? Compiler bug, misconfiguration, phase of the moon? Sorry, but if this is the status quo I'm just going to merge to branches/release and be done with it. -- Genny

11 44

tweaking the review process (was: signals2 review results)
by Stjepan Rajko 20 Dec '08

20 Dec '08

On Thu, Nov 20, 2008 at 11:40 PM, vicente.botet <vicente.botet(a)wanadoo.fr> wrote: > > I would like to make some suggestion to improve the review management: > Thank you for starting this discussion. > * I had notice only at the end of the the review that the review tokes place on two mailing lists (devel ans user). Maybe this is usaual on Boost reviews but I was not aware. It will be more transaparent if all the reviews were posted to the same mailing list, maybe a specific one should be created. Yes, this is a bit of an issue. I mentioned that both lists are used in my post that opened the review (in my notes to first-time reviewers) to try to give people a heads-up (but... I often get long-winded and I'm sure it's easy to miss parts of my posts :-)). Having a dedicated, or at least recommended mailing list (either dev or user) might be a good thing. The only problem I see regarding a completely separate mailing list is that it requires active effort to sign-up for and follow. I think that for many people (even those that are genuinely interested in the library), the fact that the review is happening at time X-Y very easily slips off the radar. Having the e-mails constantly appear in the common lists also serves to remind everyone of the ongoing review, and I suspect it leads to many valuable impromptu comments and even full reviews from people that perhaps weren't originally planning on participating in the review, but end up following the review because it happens on the list (I recall being in this situation myself several times). > > * From the 5 committing reviewers making this review possible only 3 made a review and 2 of them late. I'm wondering if this new rule must be preserved as the review can be accepted without the commiting reviewers review. Trying to use committed reviewers was a new thing for this review (it was proposed by others in http://tinyurl.com/48tdjs) Now that it has been tried out, it would be good to reflect on how things went. For the reviews that were late, the reviewers were very diligently contacting me about their changing time constraints and offered times that would work for them, and I found those times acceptable. Out of the two committed reviewers that did not submit, one also diligently worked with me on setting up an alternative timeline, but in the end contacted me saying that a full review would not be possible after all, and offered a brief report of looking into the library and a brief rationale for acceptance (as the points matched those of other reviewers, I didn't forward it to the list). I was not able to contact the final reviewer after a certain point. I think the major benefit of the committed reviewers is the high probability that they actually will submit a review. Things always happen, and boost contributions are all volunteer time, but I found that overall the committed reviewers *very responsibly* succeeded in keeping their commitment as well as they could. Were they not committed reviewers, I suspect many of them would have considered giving up. In addition, the extensions that the committed reviewers negotiated gave other reviewers a chance to contribute. So, I feel that committed reviews are a good way of reasonably making sure that a certain number of reviews will be submitted. I'm not sure that the library acceptance / rejection should be influenced by the number of committed reviews (reviews from others are a perfectly good substitute). While we're on this topic... The one thing that the number of committed reviewers should definitely influence is whether the review happens in the first place. We were fortunate to get 5 people sign up, which was the only threshold proposed, so we followed through with the review. I was wondering what to do if the threshold wasn't crossed, and I think what I would have proposed is some sort of a holding pattern, where the review schedule page is updated to say something like "signals2 - reviewers needed, contact review manager to sign up as a reviewer". Once the threshold is crossed, the reviewers, manager and author can schedule a time. Another thing... many of the committed reviewers reported that they were first time reviewers (and the reviews they submitted were impressively detailed and very valuable). Personally, I was thrilled by this, since getting new participation in boost is critical to sustaining its quality . Perhaps some combination of allowing reviewers to commit beforehand, and explicitly encouraging reviews focused on the user perspective (another suggestion from the http://tinyurl.com/48tdjs thread), helped in getting first-time reviewers (perhaps the reviewers can comment on this?). > > * There were some reviews that came into this list by the intermediation of the review manager with a delay between the posting of the reviwer and forward from the RM. One negative review posted the 4th and reveived in this list the 11th other positive posted the 2nd and received in this list 3rd. I think that the review manager should not encourage the reviewers to send the reviews to himself. This will avoid this kind of delays. So I purpose that only the reviews sent to this single mailing list must be taken in account. Yes, this particular delay is entirely my fault. I can't explain why I didn't notice this email until so late (which is the point where I contacted the poster notifying him I would like to forward the mail, and forwarded it the following morning). Allowing reviews to be sent to the review manager is straight from http://www.boost.org/community/reviews.html (Introduction paragraph). There are two valid reasons for this, IMO: * the reviewer is only subscribed to one of {boost, boost-user, boost-announce} lists, and would like the reviewer to be forwarded to both boost and boost-user lists (if there was a dedicated review list, like you suggest, that was also open to all posters, then this reason would go away) * the reviewer would like to remain anonymous to the list (granted, this could also be accomplished by sending from an anonymous e-mail). If this stays as it is, the RM should be more diligent about monitoring her personal mail, which I apparently wasn't. > > * Even if the review was over the 10th there were 2 accepting reviews comming from the commiting reviewers just some hours before the review result annoncement 19th. I think that the review manager must state clearly when the review is over and do not accept any review after. This do not means that the RMcannot change this date, but annnce it clearly. I tried to keep my timeline as transparent as possible. In my review-closing email, I asked people to let me know if they were considering writing a review. Those that contacted me were informed of the timeline of pending reviews. When the last promised review was submitted, I set a hard deadline. Given the uncertainty in people's schedules, I decided to approach this in a flexible way. That was just my personal preference - I'm sure setting a hard deadline earlier would have been a fine choice as well. > > I hope this will help to improve future reviews, > Thanks again for starting this discussion and for your suggestions - I also hope good improvements will come out of it. Stjepan

5 8

[swap] How to fix ADL barrier for XL, Intel, GCC, Sun and Como?
by Niels Dekker - mail address until 2008-12-31 19 Dec '08

19 Dec '08

The boost::swap utility from Joseph Gauterin has an ADL barrier against infinite recursion or ambiguity, as recommended by Steven Watanabe and David Abrahams, last year at the mailing list: "Re: [boost] Koenig lookup swap." http://lists.boost.org/Archives/boost/2007/08/125938.php Last Friday I added "test_adl_barrier" to test this ADL barrier. Unfortunately it fails on many compilers, including XL (AIX), Intel (version 9 and 10), GCC, Sun and Como: http://www.boost.org/development/tests/trunk/developer/utility-swap_.html While I usually use MSVC, and for that specific compiler, the ADL barrier appears successful! Do you know how to fix the ADL barrier for the other compilers? I'm afraid we'll need to have #if BOOST_WORKAROUND statements in there... FYI, the boost::swap utility is at: http://svn.boost.org/svn/boost/trunk/boost/utility/swap.hpp The ADL barrier test is at: http://svn.boost.org/svn/boost/trunk/libs/utility/swap/test/test_adl_barrie… Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

5 26

[test][doc] non-working link
by Rutger ter Borg 19 Dec '08

19 Dec '08

Dear Gennadiy, the link in http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/utf/intro.html to "collection of examples", pointing to http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/example-toc.html, seems to be broken. Kind regards, Rutger

3 2

Re: [boost] [utility/swap] Internal compiler error Siliconmanborland-6.10.0 (CodeGear?)
by Niels Dekker - mail address until 2010-10-10 18 Dec '08

18 Dec '08

David (siliconman) wrote: > It had already been logged when I got to looking: > <http://qc.codegear.com/wc/qcmain.aspx?d=68959> Thanks, David. I've been searching through qc.codegear.com before, but I hadn't found it. I guess I just chose the wrong keyword to search for, e.g., "template", and "Fatal F1004". BTW, I decided to submit the report myself, because I don't have access to borland-6.10.0. As far as I know, it isn't available for free. (I do have the free Turbo C++ 2006 Explorer installed, though.) If I had access to borland-6.10.0, I would have tried to make a smaller test program to reproduce the internal compiler error. Because I wonder if it is specific to the current implementation of the boost::swap utility... Please let me know if you have any suggestion for boost::swap (or its specialized_in_std.cpp test) to work around the compiler error. Kind regards, Niels PS Your replies don't appear on the mail archives: http://lists.boost.org/Archives/boost/2008/11/index.php http://thread.gmane.org/gmane.comp.lib.boost.devel/182214 Is that intentional?

2 6

tweaking the review process (was: signals2 review results)
by Stjepan Rajko 16 Dec '08

16 Dec '08

Hi Paul, On Fri, Nov 21, 2008 at 1:00 AM, Paul Baxter <pauljbaxter(a)hotmail.com> wrote: > On Thu, Nov 20, 2008 at 11:40 PM, vicente.botet <vicente.botet(a)wanadoo.fr> wrote: >> I would like to make some suggestion to improve the review management: > > <valid points snipped> > > Whilst I understand your points, unlike our day job, people do have other > more pressing commitments and, for many, the extensive effort given to > reviewing boost libraries is time given in an ad-hoc manner. > > Whilst it is good to have the timetable and a specific method for submitting > reviews, I don't think we need to go further and be more regimented. The > existing flexibility is a positive part of the process, IMHO. I also tend to prefer flexibility when people are volunteering their time. > > [ I do have problems with some libraries actually getting to the point of > review before interest, maturity of interface or implementation are right, > but that doesn't apply here and has been covered in previous discussions.] > I think I was guilty of this / have been bit by this myself. Anyway, there are two things that I think can help here: * requiring a certain number of committed reviewers before scheduling a review * the review manager being more active in examining the library before the actual review About the latter - in both reviews I managed, there was a number of issues (e.g., documentation shortfalls) that came up during the review that I, as review manager, could have discussed privately with the author beforehand had I done a more thorough review of the library. These issues could have been fixed before a review was scheduled, and the reviews could have been more focused on other issues. The review process page states: "The Review Manager... Checks the submission to make sure it really is complete enough to warrant formal review. See the Boost Library Requirements and Guidelines. If necessary, work with the submitter to verify the code compiles and runs correctly on several compilers and platforms." Well, in both cases I had examined the library, tried it on several compilers, read the docs, glanced at the implementation, etc. But it wasn't a thorough review. I think, had I actually gone through the reviewer's list of questions and wrote a full review, it would have given the authors some idea of possible areas that can be improved before the review (being careful not to react prematurely in possibly contentious areas where the opinion of just one person is not enough). Doing something like this would require additional effort from the review manager, but I think it would result in a much better review (and one where it is possibly easier to make a decision because there are fewer remaining problems). Best, Stjepan

3 4

Measuring compile time performance
by dan marsden 15 Dec '08

15 Dec '08

Hi We're looking at optimizing some of the compile time performance in Boost.Fusion. I'm looking for any experience in Boost of measuring build times / compile time cost, how to structure tests that cover it etc. Does Boost.Build provide any support for measuring compile time for example? I'm aware there's a Perl script by Steven Watanabe that measures template instantiations if I understand correctly. Are there any other techniques that are being used that I should be aware of? Cheers Dan Send instant messages to your online friends http://uk.messenger.yahoo.com

9 14

[proto][design]why unary_expr,binary_expr; but no nullary_expr?
by Larry Evans 14 Dec '08

14 Dec '08

Although there's unary_expr<Tag,*>, binary_expr<tag.*,*> in traits.hpp there's no nullary_expr<Tag>. I realize this would be a replacement to the current terminal template but with a user specified tag. After all, if a user specified tag for n-ary (where n>0) expressions *is* desirable, why is a user specified tag for 0-ary expressions *not* desirable? On case where this would be useful is for algebraic morphisms where n-ary ops in a source algebra are mapped to n-ary ops in a target algebra. This *includes* 0-ary ops. An op would be the equivalent to proto tags. I think this could be done by another transform similar to the pass_through transform but allowing transformation of the tag. Currently pass_through just uses the source tag in the target expression. It seems like it should be pretty easy to allow transformation on the tag also.

2 3

[Review] UUID library (mini-)review starts today, November 23rd
by Hartmut Kaiser 09 Dec '08

09 Dec '08

Hi all, The mini-review of Andy Tompkins UUID library starts today, November 23rd 2008, and will end on November 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! The library can be downloaded from the vault here (it's the file uuid_v13.zip in the topmost directory): http://tinyurl.com/6xx28b The initial review of the UUID library ended with a provisional acceptance (read here: http://article.gmane.org/gmane.comp.lib.boost.user/27774/) This mini review is meant to allow for a final decision after looking at the changed parts of the library. Here is a list of things fixed and changed: - fixed the licensing issues revealed by the initial review - fixed the security vulnerability revealed by the initial review - renamed to uuid, moved all classes, functions, etc. to namespace boost::uuids - implemented sha1 hash function (thus no license problem) - new class basic_uuid_generator to create random-based uuids. The random number generator is no longer hard coded. It can use any random number generator, default is boost::mt19937 - implemented a good seed function for random number generators - all functions are now reentrant, all classes are as thread safe as an int and the library is no longer dependent on Boost.Thread --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

11 25