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

Re: [boost] Boost.Array Maintainer
by raindog＠macrohmasheen.com 27 Nov '09

27 Nov '09

*top post* I think that it should be acceptable for other people to have the authority to submit patches and have them reviewed by other people and as long as they submit high quality code there should be the expectation that the code gets merged by someone who has the rights to do so. Look at other open source projects for ideas *end too post* ------Original Message------ From: Vicente Botet Escriba Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Subject: Re: [boost] Boost.Array Maintainer Sent: Nov 27, 2009 7:58 AM John Maddock wrote: > >>> Question: does someone have to be a maintainer of an existing library >>> (or author of one of the accepted libraries) to become a maintainer of >>> an existing (orphaned?) library? >> >> This is a very interesting question. Some lingering tickets with patch >> could be cleared faster if soem orphaned components of bosot were >> assignated new manager. > > Indeed. Something that occurred to me earlier was "how many tickets were > looked at in the last sprint, assigned a patch, but haven't been looked at > since?" That would be a good test of the owner being missing-in-action! > > Re Boost.Array, I seem to remember Alisdair Meredith taking this on, I'm > cc'ing him just in case my memory isn't what it once was ! ;-) > > It seems to me though that the bug sprints would be a good opportunity to > widen the maintainer list a little - what if we assigned an interested > volunteer to act as temporary maintainer for an orphan library during the > sprint. (S)he fixes whatever they can fix, then gets another bug sprint > volunteer to review the changes, if all looks well, and the tests are all > passing on Trunk, only then merge to release. > > Thoughts? John. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > Hi, I don't know if this is the best way, but it is clear that we have a problem with very old tickets. It will be great to identify the libraries that will need this kind of help, and make a call for volunteers. Best, Vicente -- View this message in context: http://old.nabble.com/Boost.Array-Maintainer-tp26534655p26544289.html Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

1 0

warning policy issue
by Robert Ramey 27 Nov '09

27 Nov '09

On page https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines#warn… it's suggested that the following warning at level 4 can be eliminated with a static cast warning C4244: 'argument' : conversion from <type1> to <type2> possible loss of data I've found this not to be true at least with msvc 7.1 Robert Ramey

5 9

Removing LEDA adaptors from Boost.Graph
by Jeremiah Willcock 27 Nov '09

27 Nov '09

Are there any users who are using the LEDA interfaces to Boost.Graph? There are several tickets filed against them but the tickets are all years old. Is it safe to remove them? Do they need a deprecation period first? -- Jeremiah Willcock

2 2

[LibrariesUnderConstruction]Mirror - update
by Matus Chochlik 27 Nov '09

27 Nov '09

Hi, I would like to ask the admins to update the info about the Mirror library on the LibrariesUnderConstruction page in particular to add the links to the C++0x version of Mirror on sourceforce: http://sourceforge.net/projects/mirror-lib/ and to add a link to the online docs for the C++0x version: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ TIA ________________ ::matus_chochlik

2 2

[LibrariesUnderConstruction] Boost.Numeric_Bindings
by Rutger ter Borg 27 Nov '09

27 Nov '09

Hello all, I see the Numeric_Bindings library is missing on the LibrariesUnderConstruction trac page. This library is under development since 2002. Herewith a short description of the library. Boost.Numeric_Bindings is a C++ library for numeric computing. It is a generic layer between data containers and linear algebra algorithms. For the data container part, it supports both compile-time statically sized and run-time dynamically sized vectors, matrices, through a traits system. Currently it includes traits for C-arrays, for standard vectors, for uBLAS' containers, Eigen containers, TNT, Boost.Array, to name a few. It offers compile-time inspection, iterators, and views on all mentioned containers. For the algorithm part, it provides a C++ interface to algorithms offered by BLAS, LAPACK, and more. This covers algorithms from most vendor-provided math libraries, such as the reference BLAS, ATLAS, Intel's MKL, AMD's CML, NVidia's CUDA, etc.. The "stable" release is available at http://svn.boost.org/svn/boost/sandbox/numeric_bindings-v1/ The current development version is available at http://svn.boost.org/svn/boost/sandbox/numeric_bindings/ Questions and/or comments are welcomed. Thanks, Rutger

3 4

Compiler warnings from Macs, IBM acc, Borland, Comeau, Metroworks, et al - are they a Problem?
by Paul A. Bristow 27 Nov '09

27 Nov '09

https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines (bottom of the page) has a collection of suggestions for 'quieting' warnings on MSVC and GCC, but no information on other compilers yet. Can users of these compilers please 1 Assert that they never have a problem with unhelpful compiler warnings from Boost stuff, or 2 Send common warnings and suggestions for dealing with them by suppressing or by 'fixing' the code (so that I can add to the guidelines. Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

1 0

Boost.Array Maintainer
by Dean Michael Berris 27 Nov '09

27 Nov '09

Good day everyone, Does anybody already maintain Boost.Array? I see quite a number of patches and "todo" tickets and am wondering whether someone should be taking care of such a crucial piece of the collection. If there isn't anybody willing to maintain Boost.Array I don't mind looking after it until someone else does. Question: does someone have to be a maintainer of an existing library (or author of one of the accepted libraries) to become a maintainer of an existing (orphaned?) library? HTH -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

6 6

[unordered] 1.41.0 unordered_map doesn't allow declaration with incomplete type.
by Jon Spencer 27 Nov '09

27 Nov '09

The new version of the unordered library doesn't allow you to declare an unordered map with an incomplete type. The following code would compile with the old version but not the new: struct a; struct b { boost::unordered_map<int, a> c; }; Or the more useful: struct d { boost::unordered_map<int, d> e; }; As far as I know these constructs are allowed with the other standard containers. The problem show up in "boost/unordered/detail/fwd.hpp" with the the declaration of value_base, which requires that the value_type of the map not be incomplete at declaration time. Jon.

2 1

Re: [boost] Core libraries should separated from experimental libraries
by Tom Brinkman 27 Nov '09

27 Nov '09

Thomas Klimpel wrote >> Some of the accepted boost libraries seem to >> receive only minimal maintenance by their original authors, >> and making it easier to contribute >> libraries to boost would probably only increase the number of >> libraries in minimal maintenance mode. So I >> guess the recent efforts to encourage the boost >> community members to spend some maintenance time on >> libraries they haven't authored is exactly the >> right thing to do for the current situation. Agreed, that is a problem, but different from the one I'm trying to emphasize here. >> I'm not sure whether you want to highlight the excessive >> quality criteria for acceptance into boost here, >> or the lack of review managers. Probably more the lack of review managers. I wish more of the core boost library developers would step up and mentor new library submissions. Not sure why they don't. Its actually quite fun. >> But the sandbox is actually quite a nice place to flesh out a >> potential library. And there is quite a number of libraries in the >> sandbox that are currently in active flesh out mode, and will stay in >> that mode for quite some time. The sandbox is just a nice place to dump a library. Most are quickly abandoned and receive very little attention. Why? Exposure, they need exposure. Having a place in for the promising experimental libraries to to get some exposure, and where the authors can toot how great their library is would be fun for all involved. That's why I come to boost -- for an exchange of ideas and to be inspired by others. The sandbox does not do that for me. Having libraries in the experimental branch would focus everyone attention on the upcoming libraries. Nothing can focus a library's authors attention if he knows that his library is getting exposure and being noticed by others. I played a part in developing the the review queue, but it never changes. I don't like how its evolved and its stuck in the status quo. The review queue does not give enough exposure and its now taking about a year to get your library reviewed. Uggh. Actually, I would like to see that the review queue is abandoned and replaced with the experimental branch. The only important review would then be when to decide when the library has matured enough to move it from the non-stable to the stable branch of boost. The review wizards would manage this process. It would be much more fun for all involved. The current system is stale and not inspiring the level of innovation that I believe is possible here.

15 21

Re: [boost] Review Queue Needs Attention
by Tom Brinkman 26 Nov '09

26 Nov '09

>> judging by the review schedule (almost no review managers), that would mean >> boost isn't very interested in new libraries in general. It would seem so. >> I would recommend that authors try find a review manager before they request a review. Review managers are generally recruited from people that already have a library that has been approved in boost, that means you luke (hint). The wizards could open it up to anyone. Its been considered, but rejected in the past. I would like to focus attention on something different. That would be creating a "non-stable" branch of boost, where the proposed libraries would live for a while, get some exposure. Since most libraries are header file only, it should not be a problem. While not all will compile on all platforms, and certainly not have perfect documentation, it would be a place for future boost authors to elicit feedback. The experimental libraries would not affect the core boost libraries in any way. I'm absolutely convinced that it would encourage lots more participation. There is so much more to do, we haven't even scratched the surface of what is possible. The core boost authors have put in place a wonderful place to come and share ideas, but we are letting it flounder. Ugh.

7 6