I am pleased to formally announce that the Typeof library has been
accepted into
Boost.
Congratulations Arkadiy and Peder.
There were 3 reviews, all in favour of accepting the library.
While I'm not questioning the value of accepting this library specifically, doesn't it seem less than ideal to accept a library that -- for whatever reasons -- garnered only three reviews?
Yes.
While the library was truly peer reviewed, and the reviews were by knowledgeable folk, the base of input is narrow as a result. Should this be the norm?
No. Not sure what we can do about it. I think the review wizard should weigh in here.
Three positive reviews is not sufficient in my opinion. However, the precedent has already be set, as other libraries have been approved on a similar limited number of reviews. I'm sure most would agree that the review situation is not ideal and could be improved. However, it has worked to some extent and the boost c++ libraries, are arguably among the best available. One easy improvement would be to require that each approved library be endorsed/sponsered by a least one prominent boost member, such as Dave Abrahms, Jeff Garland or Thorsten Ottosen. Another easy improvement would be to add accepted libraries under a probation or beta period of say six months. The library would remain beta until its stable enough and has additional time for more user scrutiny. A prominent boost member would make the judgement about when to remove the library from its beta period. During the beta period, the library author would be asked to complete the libraries documentation, examples and requested changes from the additional user scrutiny. If there are no objections, I will start requesting that libraries under review be sponsered by at least prominent boost member. This would ensure that accepted libraries meet the approval of a least one prominent boost member. Review Wizard, Tom Brinkiman
"Tom Brinkman" <reportbase@gmail.com> wrote
If there are no objections, I will start requesting that libraries under review be sponsered by at least prominent boost member. This would ensure that accepted libraries meet the approval of a least one prominent boost member.
Are we going to have an election on which boost member is considered "prominent"? Or is there such division already? :-) Seriously, I think the number of reviews is most closely related to the the interest, and so the problem may actually be at much earlier stage. Theoretically the libraries that don't raise enough interest should not reach the review stage. Also, please note, that in case of typeof, a very active support of a very prominent boost member, didn't ensure large number of reviews. Meanwhile I am very much puzzled with the inconsistency of rather high download activity and relatively low amount of feedback the Typeof library has received on the list. If somebody could offer a reasonable explanation of this fact, it would help us a lot in our future work with boost. Best regards, Arkadiy
On Wed, 1 Jun 2005 13:29:27 -0400 "Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote:
Also, please note, that in case of typeof, a very active support of a very prominent boost member, didn't ensure large number of reviews.
Meanwhile I am very much puzzled with the inconsistency of rather high download activity and relatively low amount of feedback the Typeof library has received on the list. If somebody could offer a reasonable explanation of this fact, it would help us a lot in our future work with boost.
As discussed in the past, I think the review period is way too short. I would much rather we have multiple reviews going on at the same time, with each one alloting about a month, rather than the 10 day period we now have. I think it would garner much more feedback, and the quality of the reviews would improve as well. Go back and look at the recent library reviews (not just typeof), and you will see that very few people have time to do really in-depth reviews. Yes, I know everyone handling the reviews is a volunteer, but so are the individuals attempting to do a review. I have barely participated in any reviews, not because of interest, but because I can not manage to download, read, test, review, code examples, write my questions, consider the feedback, etc. in such a short timeframe. The one time I tried to start working on a review well ahead of the scheduled start time, the library changed significantly right before the review started. Thus, for the most part, I end up reviewing stuff well after it has been accepted (and, sadly, there are some libs that I just will not use, though I may have used them if I would have offered input and gotten changes during the review). Unfortunately, once a library is accepted, getting changes to interfaces or design is near impossible, as evident by several recent threads. Please don't take me wrong... I love boost, and I use some of it. However, I think the review process could be vastly improved by significantly lengthening the review timeframe. If that is not possible, then we should freeze a lib once it has been submitted for review. It gets reviewed as submitted. This would provide a built-in lengthening of the review, basically from the point in time where the lib is placed on the queue, until the time the review is finished. If the lib needs to be changed before the review, then it should be removed from the queue, and placed at the back. My $0.02, FWIW
"Jody Hagins" <jody-boost-011304@atdesk.com> wrote
Thus, for the most part, I end up reviewing stuff well after it has been accepted (and, sadly, there are some libs that I just will not use, though I may have used them if I would have offered input and gotten changes during the review). Unfortunately, once a library is accepted, getting changes to interfaces or design is near impossible, as evident by several recent threads.
The Typeof library was accepted at the moment when a new boost release is being prepared, and is obviously not going in until the next one. Which probably gives us more time than average when making changes is relatively easy. Therefore, if you have an interest in this library, please make sure to take a look at it, and send us your feedback -- it is welcome, and will definitely be considered. Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
Therefore, if you have an interest in this library, please make sure to take a look at it, and send us your feedback -- it is welcome, and will definitely be considered.
Hi, I have not reviewed the source code, and just downloaded it today in fact. However, I do have some questions after reading the documentation, and some suggestions for it. 1) The docs say that the BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() macro is used in .hpp or .cpp files. I'm curious how it works in a .hpp file if that file is included in multiple .cpp files. Does it create a new group for the same types in each file? 2) In the reference section, sample code for BOOST_AUTO and for LVALUE_TYPEOF, the code shows a declaration for main with a return type of "void", but that is not valid C++. main must be declared to return an integer. (Yeah, I'm pedantic.) 3) In the reference section, for INTEGRAL, there is a user-defined enum named "color", but it is not registered with the typeof library. However, in the tutorial section, the text reads, "If your define your own type, the Typeof Library cannot handle it unless you let it know about this type." So either there are some cases where it's not necessary to register, or perhaps the sample code is wrong? NOTE: under the REGISTER_TYPE section, it does show an enum being registered. Thus, now I'm confused. :) 4) In the reference section, LIMIT_FUNCTION_ARITY has a typo: "... are supported for functios," "functions" is missing the 'n'. 5) The REGISTER_TEMPLATE sample code does not show how to register a template with template-template parameters, but it describes it. Later, under the docs for TEMPLATE there is an example. Perhaps REGISTER_TEMPLATE should indicate that an example for template-template parameter usage appears there, or somehow these could be tied together more. 6) Thats all for now. :) This library looks pretty cool. -- Chris
On 6/2/05, Chris Uzdavinis <chris@uzdavinis.com> wrote:
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
Therefore, if you have an interest in this library, please make sure to take a look at it, and send us your feedback -- it is welcome, and will definitely be considered.
Hi, I have not reviewed the source code, and just downloaded it today in fact. However, I do have some questions after reading the documentation, and some suggestions for it.
1) The docs say that the BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() macro is used in .hpp or .cpp files. I'm curious how it works in a .hpp file if that file is included in multiple .cpp files. Does it create a new group for the same types in each file?
Yes. That is where the basis for possible ODR violations arises. We have tried testing if this causes any problems for the compilers we support, but it seems to work ok.
2) In the reference section, sample code for BOOST_AUTO and for LVALUE_TYPEOF, the code shows a declaration for main with a return type of "void", but that is not valid C++. main must be declared to return an integer. (Yeah, I'm pedantic.)
Will change this :)
3) In the reference section, for INTEGRAL, there is a user-defined enum named "color", but it is not registered with the typeof library. However, in the tutorial section, the text reads,
"If your define your own type, the Typeof Library cannot handle it unless you let it know about this type."
So either there are some cases where it's not necessary to register, or perhaps the sample code is wrong?
No, the sample is correct. If color is used as a type, it needs to be registered. If used as an integral constant, it does not need to be registered. enum color {red,green,blue}; tempate<typename T> struct X; X<color> a; typedef BOOST_TYPEOF(a) type; Both X<T> and color needs to be registered. template<color I> struct Y; Y<red> b; typedef BOOST_TYPEOF(b) type2; Only Y<color> needs to be registered. red is handled as an integer constant.
NOTE: under the REGISTER_TYPE section, it does show an enum being registered. Thus, now I'm confused. :)
4) In the reference section, LIMIT_FUNCTION_ARITY has a typo:
"... are supported for functios,"
"functions" is missing the 'n'.
5) The REGISTER_TEMPLATE sample code does not show how to register a template with template-template parameters, but it describes it. Later, under the docs for TEMPLATE there is an example. Perhaps REGISTER_TEMPLATE should indicate that an example for template-template parameter usage appears there, or somehow these could be tied together more.
Good idea. Will do.
6) Thats all for now. :) This library looks pretty cool.
Thanks.
-- Chris
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Peder Holt" <peder.holt@gmail.com> wrote
On 6/2/05, Chris Uzdavinis <chris@uzdavinis.com> wrote:
1) The docs say that the BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() macro is used in .hpp or .cpp files. I'm curious how it works in a .hpp file if that file is included in multiple .cpp files. Does it create a new group for the same types in each file?
Yes. That is where the basis for possible ODR violations arises. We have tried testing if this causes any problems for the compilers we support, but it seems to work ok.
A registration group is just a number. At the moment of registration we combine this number with __LINE__, thus getting a unique id for each type or template. A registration macro expands into a number of template specializations that help us to encode and decode the registered type/template (hence the requirement to specify it in the context of global namespace). In different translation units, depending on the order of #includs, the same types may have different ids, and so the same specializations -- different bodies. This is technically an ODR violation. To work this around, the encoding/decoding templates were placed into an unnamed namespace, so that they are different in different TUs, and not a subject to ODR. Unfortunately this doesn't fix the problem completely. Since typeof now relies on different templates in different TUs, it itself becomes a subject of ODR violation, if used in a header: TU1 struct A { typedef BOOST_TYPEOF(1 + 0.5) type; /*double*/ }; TU2 struct A { typedef BOOST_TYPEOF(1 + 0.5) type; /*also double, but calculated through different set of templates */ }; This issue was discussed at some point in the past. The decision was made to ignore this ODR violation, as long as compilers don't care. Fortunately, the compilers don't seem to care. We have a specific test that reproduces this situation as a part of our test rutine. Also, Martin Wille helped me to run this through como, strict mode, which is considered to be the strictest compiler around. Como didn't complain either. The only way to avoid the ODR violation seem to be to assign registration group numbers explicitly, and this would seriously reduce the usability of the library. Regards, Arkadiy
Hi Chris,
1) The docs say that the BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() macro is used in .hpp or .cpp files. I'm curious how it works in a .hpp file if that file is included in multiple .cpp files. Does it create a new group for the same types in each file?
2) In the reference section, sample code for BOOST_AUTO and for LVALUE_TYPEOF, the code shows a declaration for main with a return type of "void", but that is not valid C++. main must be declared to return an integer. (Yeah, I'm pedantic.)
3) In the reference section, for INTEGRAL, there is a user-defined enum named "color", but it is not registered with the typeof library. However, in the tutorial section, the text reads,
"If your define your own type, the Typeof Library cannot handle it unless you let it know about this type."
So either there are some cases where it's not necessary to register, or perhaps the sample code is wrong?
NOTE: under the REGISTER_TYPE section, it does show an enum being registered. Thus, now I'm confused. :)
4) In the reference section, LIMIT_FUNCTION_ARITY has a typo:
"... are supported for functios,"
"functions" is missing the 'n'.
5) The REGISTER_TEMPLATE sample code does not show how to register a template with template-template parameters, but it describes it. Later, under the docs for TEMPLATE there is an example. Perhaps REGISTER_TEMPLATE should indicate that an example for template-template parameter usage appears there, or somehow these could be tied together more.
Thanks for these suggestions. I have to admit that, since we had committed to re-work the docs during the review period, we did it in a haste, especially since most time was spent setting up the Boost.Book environment. AFAICT, Peder may still not have it setup... Once the review was over, and the pressure off, we kind of diverted to some optimization opportunities that were found during the review. This opportunities seem so attractive (about 60% performance improvement) that we put off the docs. Which was probably wrong, since people continue looking at them. So I think we need to get back to docs and polish them ASAP. Thanks for this reminder :) Regards, Arkadiy
Jody Hagins wrote:
As discussed in the past, I think the review period is way too short. I would much rather we have multiple reviews going on at the same time, with each one alloting about a month, rather than the 10 day period we now have. I think it would garner much more feedback, and the quality of the reviews would improve as well.
I agree with the sentiment, but I'm not sure it would work. The problem with volunteer projects is that we participate in our spare time. That means time-consuming tasks like reviews get pushed back until we have sufficient time spare to do the necessary research and evaluation. Typically, it keeps getting put off until there is a better time. Then you run into the deadline, and that focusses the mind. If you extend the review period to 1 month, I suspect you will still see the majority of activity in the last days, after an opening surge by the early adopters. What is needed is a way to get people on board and actively preparing for the review period in that month leading up to the formal review itself. Regular posting of the review queue should help, but we seem to have that now and still only got 3 reviews in the last round. I am wondering if something like the regression testing pages would help. Not specifically for testing, but some kind of always-available dynamic web page which reflects status of the review queue, and progress of each review. Some artefact outside the list to help focus the mind and gain attention. I was going to suggest perhaps a Wiki for each review. but I think that would take focus away from this list, and that is where discussion seems to work well. Anything that takes focus away from this list will probably have an adverse effect on review quality, not matter how well intended. I'm afraid I don't have any more realistic answers to offer. It doesn't help that I have been off-list and way overcommitted recently myself :?( AlisdairM
On Jun 1, 2005, at 12:29 PM, Arkadiy Vertleyb wrote:
"Tom Brinkman" <reportbase@gmail.com> wrote
If there are no objections, I will start requesting that libraries under review be sponsered by at least prominent boost member. This would ensure that accepted libraries meet the approval of a least one prominent boost member.
Are we going to have an election on which boost member is considered "prominent"? Or is there such division already? :-)
If you have to ask, we can't tell you :)
Seriously, I think the number of reviews is most closely related to the the interest, and so the problem may actually be at much earlier stage. Theoretically the libraries that don't raise enough interest should not reach the review stage.
At one point we had discussed--maybe even decided on--a policy whereby a review request had to be "seconded" by someone that had looked over the library to be sure that it was in good shape. Obviously, that "someone" would be an interested third party that was not involved in development of the library. If nobody is interested, nobody will second.
Also, please note, that in case of typeof, a very active support of a very prominent boost member, didn't ensure large number of reviews.
Meanwhile I am very much puzzled with the inconsistency of rather high download activity and relatively low amount of feedback the Typeof library has received on the list. If somebody could offer a reasonable explanation of this fact, it would help us a lot in our future work with boost.
I think Jody is right on. I know that I really wanted to review the typeof library, but the upcoming release has sucked up what little time I've been able to spare for Boost. More time for reviews may be the answer. Doug
Doug Gregor <dgregor@cs.indiana.edu> writes:
I think Jody is right on. I know that I really wanted to review the typeof library, but the upcoming release has sucked up what little time I've been able to spare for Boost. More time for reviews may be the answer.
I agree as well. To do a fair review takes quite a committment, and done over only 10 days is too much time per day to justify to my family. But spread over a month or so, sneaking away for a few hours in the evening is much more reasonable. -- Chris
Doug Gregor wrote:
Meanwhile I am very much puzzled with the inconsistency of rather high download activity and relatively low amount of feedback the Typeof library has received on the list. If somebody could offer a reasonable explanation of this fact, it would help us a lot in our future work with boost.
I think Jody is right on. I know that I really wanted to review the typeof library, but the upcoming release has sucked up what little time I've been able to spare for Boost. More time for reviews may be the answer.
Same here. I really wanted to do a review but I got neck deep on other activities. I'm very interested with the typeof library from the very start. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On Thu, 02 Jun 2005 07:13:36 +0800, Joel de Guzman wrote
I think Jody is right on. I know that I really wanted to review the typeof library, but the upcoming release has sucked up what little time I've been able to spare for Boost. More time for reviews may be the answer.
Same here. I really wanted to do a review but I got neck deep on other activities. I'm very interested with the typeof library from the very start.
Lots of interesting suggestions in this thread, but.... My conclusion is that this review was impacted by lots of people working on the release. Of course it's easy to say let's hold up the review queue while we do a release. Problem is that since releases tend to stretch over a couple months it isn't so easy. Even so, I'd suggest the review wizard and the release manager work together to adjust the reviews to avoid scheduling reviews during the release crunch period. Again not easy, but I suspect things can be worked out. Jeff
Tom Brinkman wrote:
One easy improvement would be to require that each approved library be endorsed/sponsered by a least one prominent boost member, such as Dave Abrahms, Jeff Garland or Thorsten Ottosen.
This is an easy improvement only if you're not Dave, Jeff or Thorsten ;-)
Another easy improvement would be to add accepted libraries under a probation or beta period of say six months. The library would remain beta until its stable enough and has additional time for more user scrutiny. A prominent boost member would make the judgement about when to remove the library from its beta period. During the beta period, the library author would be asked to complete the libraries documentation, examples and requested changes from the additional user scrutiny.
Why make a library which has been in development for a long time and has received intense scrutiny undergo a probationary period?
If there are no objections, I will start requesting that libraries under review be sponsered by at least prominent boost member. This would ensure that accepted libraries meet the approval of a least one prominent boost member.
This sounds similar to the mentoring idea that was proposed after the OOPSLA meeting. I think it's a good idea, as long as you expand the list of "prominents" to include all active library authors and maintainers.
Review Wizard, Tom Brinkiman
Jonathan
"Tom Brinkman" <reportbase@gmail.com> wrote
Three positive reviews is not sufficient in my opinion. However, the precedent has already be set, as other libraries have been approved on a similar limited number of reviews.
Obvious questions in response to this... How many reviews are sufficient? What proportion in favour/against acceptance is acceptable? regards Andy Little
participants (11)
-
Alisdair Meredith -
Andy Little -
Arkadiy Vertleyb -
Chris Uzdavinis -
Doug Gregor -
Jeff Garland -
Jody Hagins -
Joel de Guzman -
Jonathan Turkanis -
Peder Holt -
Tom Brinkman