- Boost - lists.boost.org

Re: [testing] Buildbot setup status.
by Rene Rivera 24 Apr '05

24 Apr '05

Robert Ramey wrote: > It looks like it runs even before I finish getting a whole group of changed > checked in. It's on a 10 minute trigger. So it waits for 10 minutes where it hasn't gotten CVS notifications before proceeding. Looks like you had the commits spaced out in 20, or so, minutes. This is one of those, tweak until we get what's appropriate for Boost development. Should I make that longer? 20, 30, 60 minutes? I don't want to make it feel unresponsive though. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 1

Regression testing and BuildBot discussions
by Beman Dawes 24 Apr '05

24 Apr '05

Dave Abrahams, Doug Gregor, Thomas Witt, and I had a discussion last week at the C++ committee meeting about how to improve Boost regression testing, and the whole process of getting ready for releases. Much of what we talked about has already been discussed on this list, so our conclusions shouldn't be much of a surprise: * Making Boost regression testing as robust, automatic, distributed, and timely as possible is the best way to help developers, release managers, testers, and eventually, users. * BuildBot (http://buildbot.sourceforge.net/) looks like best way to achieve those goals, based on experiments to date. * It would be very helpful if a team coalesces around Rene Rivera to develop BuildBot regression testing for Boost. They will need to stay coordinated with the MetaCommunications folks, of course. The rationale behind the "robust, automatic, and distributed" goals is that many people are willing to volunteer machine resources for Boost regression testing, but they say that other than downloading (and perhaps answering a very few startup wizard questions) they don't have any of their own time available. Thus the vision is of something like the SETI@home project which lets people contribute spare machine cycles without burdening them further. The rationale behind the "timely" goal is that developers will benefit tremendously from faster feedback, both for HEAD and active branches. Automating the feedback will free developers from having to track what is happening on many different platforms. The rationale behind encouraging a team to work on BuildBot regression testing is that this is important to Boost, so it will benefit from a team forming. That should improve and speed development, and ensure that several people understand the system and can maintain the internals. Rene is the logical leader since he has already stepped into that role for BuildBot. --Beman

4 6

Re: [network] An RFC - updated
by Don G 24 Apr '05

24 Apr '05

Hi Peter, > FD_SETSIZE only applies to select, and nobody > uses select except in "quick and dirty" servers > (as I did recently). Sadly, select is by far the most portable solution. On Windows, it is the only solution for 9x/Me. We can and should write more efficient impls for platforms that support poll() or epoll() or kqueue, etc.. > The idea of an explicit poll() call is to allow > the implementation to use a single-threaded > dispatch mechanism (select/epoll/kqueue), if one > is available. Without poll() you are forced to > use worker thread(s) and a callback queue to > support a single-threaded application, and this > can be considerably less efficient than > epoll/kqueue (or select in the < FD_SETSIZE > case) (in theory). Yes, indeed. Though I may be missing something in your idea about net::poll(). How would it avoid a queue? > Of course, if the threaded model can be > demonstrated to achieve comparable performance, > there would be no need to complicate the > interface with poll(). The "need" is performance and familiarity (IMO). If performance were taken out of the picture, it would be hard to argue for it. I don't know how the comparison would go which is why I was writing some stuff to try it out and get some measurements. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [network] An RFC - updated
by Don G 24 Apr '05

24 Apr '05

Hi Peter, > I see that you are slowly moving away from your network-centric > scheme after you've already convinced me of its merits. ;-) Not exactly. Just trying to explore it completely :-) In other posts I state that my thinking is still as I originally proposed. I just see some use cases where your approach has merit; perhaps it is best left to the app but could be provided as a library of its own. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Re: TR2 and C++0x heads up
by JOAQUIN LOPEZ MU?Z 24 Apr '05

24 Apr '05

----- Mensaje original ----- De: Thorsten Ottosen <nesotto(a)cs.auc.dk> Fecha: Sábado, Abril 23, 2005 11:32 pm Asunto: [boost] Re: TR2 and C++0x heads up > "Beman Dawes" <bdawes(a)acm.org> wrote in message > news:6.0.3.0.2.20050422110501.042b2a20@mailhost.esva.net... > > | So far there are plans to propose Boost.Threads, > Boost.Filesystem, and > | Boost.Signals. As well as proposals for some of the more major > libraries, I > | personally hope someone will do a sweep through Boost looking at > some of > | the smaller utilities and helpers for a possible "Small Additions" > | proposal. > > I believe Alisdair was considering to work on boost.format. > > Besides, boost.date_time I think these other libs are good > candidates (maybe > with slight modifications): > > 1. conversion > 2. optional > 3. string algorithms > 4. utility > 5. variant > 6. iostreams > I'd add a tokenizer to the bunch. Not specially sexy but massively helpful --the typical impulse of a beginner is to do the tokenizing stuff by hand, many a time resulting in off-by-one errors, mishandling of unexpected separators etc. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Patch for bug in boost/boost/iterator/zip_iterator.hpp
by mstone＠cs.swarthmore.edu 24 Apr '05

24 Apr '05

boost/iterator/zip_iterator.hpp has an incomplete #include guard. This patch adds the necessary define to avoid redefinition errors when zip_iterator.hpp is included more than once. Michael

2 1

lists.boost.org not updated
by Peter Dimov 24 Apr '05

24 Apr '05

http://lists.boost.org still links to the old archives. -- Peter Dimov http://www.pdimov.com

1 0

[smart_ptr] sp_counted_base_cw_x86.hpp for release?
by Rene Rivera 24 Apr '05

24 Apr '05

Peter, Should I add the sp_counted_base_cw_x86.hpp implementation in or not? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

3 3

como toolset failures
by Bronek Kozicki 24 Apr '05

24 Apr '05

I think that big part of failures in como toolset are due to --a (strict mode) option. This unfortunatelly prevents windows headers from being included. Or more precisely, the exact reasult of including windows headers with --a option on is that compiler chokes on __declspec, which is exactly what I see in results. I'd rather not update como toolset to remove this option, maybe someone more familiar with bjam will do this. B.

3 3

Is there an IRC channel discussing boost?
by Schrom, Brian T 24 Apr '05

24 Apr '05

I did a modest amount of Googling and looked through the website for an IRC channel. Did I just miss it, or is there not one? Thanks. Brian S.

3 2