- Boost - lists.boost.org

Boost bug sprint delayed until Wednesday, November 18th
by Marshall Clow 13 Nov '09

13 Nov '09

To allow time for the 1.41 release to complete, the start of the Boost Bug sprint has been delayed until next Wednesday, November 18th. That doesn't mean you can't work on bugs before that, though - just don't check fixes into svn until then. Find bugs, reproduce them, generate patches - all of those are fine! We started the last bug sprint with just over 800 open tickets. We finished with about 720 open tickets. Now (several months later) there are 854 open tickets. Useful reports: Active tickets https://svn.boost.org/trac/boost/report/1 Ticket counts by milestone https://svn.boost.org/trac/boost/report/21 Ticket counts by component https://svn.boost.org/trac/boost/report/19 Ticket counts by type https://svn.boost.org/trac/boost/report/20 Ticket counts by owner https://svn.boost.org/trac/boost/report/18 With 1.41 about to go out the door, we've still got a _bunch_ of tickets that were "to be resolved" by earlier milestones: Boost 1.36.0 101 Boost 1.37.0 45 Boost 1.38.0 64 Boost 1.39.0 89 Boost 1.40.0 139 That's more than half the active tickets! I'm sure that some of these have been fixed, or no longer apply. But which ones? -- Marshall P.S. If you're going to be participating in the sprint, please drop me a note.

1 0

boost.python problem in release branch (GSoc work)
by Ralf W. Grosse-Kunstleve 13 Nov '09

13 Nov '09

I just found out that two boost.python tests (svn trunk and release) are not valgrind clean. I fear this could be a serious problem, although I've not seen actual failures apart from the valgrind diagnostics. What I know at the moment is: libs/python/test/properties.py libs/python/test/data_members.py produce valgrind errors with trunk revision 56305 but not 56304 (fedora 8 64-bit). The critical revision 56305 is: Merged 2009 GSoC work from sandbox-branches/bhy/py3k branch back into trunk. It is merged into the release branch already. Unfortunately, without revision 56305 boost.python does not work with Python 2.6.3 and 2.6.4, i.e. backing out rev. 56305 and some followup revisions would only replace one problem with another. How far along is the 1.41 release? Is there a chance it could be delayed for a few days? Ralf P.S.: I'll add this issue to the tracker when I get a chance (hopefully tomorrow).

4 7

A fresh approach to iteration (Andrei Alexandrescu)
by Neal Becker 13 Nov '09

13 Nov '09

http://www.informit.com/articles/article.aspx?p=1407357&seqNum=7

1 0

Re: [boost] [msm] Version 2.0 available
by Christophe Henry 13 Nov '09

13 Nov '09

>But you'd have to refactor an equivalent MSM Machine too (you'd need to introduce the flag), right? True, but adding one line to a few states is a lot less work than adding a composite, giving it a transition table and changing the transition table of the state machine.

2 1

Official warnings policy?
by John Maddock 13 Nov '09

13 Nov '09

I'm *not* saying we should do this for 1.41, but should we have an official policy regarding compiler warnings and which ones we regard as "failures"? I realize these can get pretty busy-body at times, but if the user sees several pages of warnings when building Boost it doesn't look so good. So my suggestion would be that we have two test-runners (if we have any spare!) that build with warnings-as-errors, maybe: -Wall -pedantic -Wstrict-aliasing -fstrict-aliasing -Werror For gcc and: /W3 /WX for MSVC? Obviously these may prove to be far too busy-body, but is this worth a try? Cheers, John.

31 202

Re: [boost] GGL Questions
by Bruno Lalande 12 Nov '09

12 Nov '09

Hi Peter, Thanks for your interest in GGL, and for trying to integrate it into your project. Lines and rays don't exist yet in GGL indeed. Adding them would basically consist in defining the corresponding concepts (like for polygon, segment, etc...) and then specialize the distance and intersection (to start with) algorithms for them, which is completely feasible. I'm personnally more video games oriented so I have already thought about the need of such things actually. As for directions, it's not there just because we didn't need it until now (there only exist a notion of orientation for points ranges traversal). I guess it would only be a traits to define and to use in algorithms that needed it. So to summarize, all those things are not yet there, but can easily be added. HTH Bruno

1 1

[iostreams] Is anyone maintaining Boost.IOStreams?
by Richard Smith 12 Nov '09

12 Nov '09

I've just looked through the list of bugs for the iostreams library: https://svn.boost.org/trac/boost/report/14?USER=anonymous&page=4 >From a quick scan, it looks like this library is not being maintained any more. Is this true? Just scratching to scratch the surface, the following dozen bugs seem to be to all be trivial to fix. Many have patches, and the others have a sufficiently clear description that fixing them should only be a couple of minutes' work. 2094 -- has a patch that ought to be uncontroversial 2154 -- relates to code that seems not to exist any longer 2817 -- proposed resolution seems straightforward 2894 -- seems pretty straightforward 2932 -- would be trivial to fix, assuming a fix is desired 3010 -- appears to have been fixed 3011 -- has a patch that ought to be uncontroversial 3197 -- trivial suggestion to remove a compiler warning 3311 -- obviously an error and trivial to fix 3352 -- looks like a genuine subtle bug; includes a patch 3403 -- minor documentation niggle, complete with patch 3505 -- looks a genuine bug and includes patches Some of the other bugs look pretty serious to me, and I might be inclined to spend some time investigating them if I thought there was any realistic chance of the resulting patches being accepted. -- Richard Smith

5 12

[Iostreams] Release notes
by Daniel James 12 Nov '09

12 Nov '09

Hi, I've added some release notes for Iostreams, but I don't really know much about the library so it'd be really helpful if someone who does could take a look at them. http://beta.boost.org/users/news/version_1_41_0 Daniel

3 2

Re: [boost] [msm] Version 2.0 available
by Christophe Henry 12 Nov '09

12 Nov '09

Hi Andreas, >:-) You won't get any flames from me. Yes, I don't agree with some of the >points in MsmSession_Handout.pdf (e.g. 2.4, a user in his right mind would >put Stopped, Open, Paused and Playing into an outer CDLoaded state and then >only say if (state_downcast<const CDLoaded *> != 0)). True, it is a possible solution. But 1) you don't always want to refactor your state machine and 2) sometimes you can't. For example, to take the example in the Statechart documentation(http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/tuto…, if ( ( state_downcast< const NumLockOff * >() != 0 ) && ( state_downcast< const CapsLockOff * >() != 0 ) && ( state_downcast< const ScrollLockOff * >() != 0 ) ) could have been replaced by if(fsm.is_flag_active<IsOffState,Active::Flag_AND>()). And in this case I don't see a working refactoring solution. In my experience, the flag system has proven invaluable (to define, for example, several success states in a test case defined as a state machine). > However, although I haven't yet reviewed anything in-depth so far, I'm definitely impressed by the progress the library has made. I hope I'll find the time to contribute > an in-depth review. This would be great and your experience could prove invaluable. I'd be very thankful for it. > Out of curiosity, have you made any tests how many states compilers can manage without running out of memory? IIRC, a Boost.Statechart FSM with 128 states > and several hundred transitions was the most I was able to fit into one TU. Good point indeed. There are 2 limitations. First, Msm is based on boost::mpl::vector for the transition table and on boost::fusion::set to contain the states. Both have a default limit of 20, which can be extended to 50. This is the theoretical limit. Of course, you can add some vectorxxx.hpp headers (which I did). I tried up to 80 transitions and 80 states in one machine. The second limitation is the compiler. The test compiles on VC and g++, eventhough you might need lots of RAM (1.4GB with VC9, 400MB with g++) and 40-60s. The execution speed stays the same, thus proving the O(1) double-dispatch. I suppose that, while it must be possible to push this further, Boost.Statechart will likely break the compiler later than Msm. Regards, Christophe Henry

2 1

CGL Questions
by Peter Schregle 12 Nov '09

12 Nov '09

Oops, I meant "GGL Questions" of course.

1 0