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

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

CGL Questions
by Peter Schregle 12 Nov '09

12 Nov '09

We are thinking about replacing our geometric algorithms with the ones from GGL. We would want to somehow adapt our own geometric primitives so that GGL can work with them, and with points, line segments and polygons this works rather nicely. However, we also have a few other concepts, where we have not found a simple way to adapt them to GGL. 1) Line We consider a line being an infinite line in the mathematical sense, i.e. it does not have endpoints but extends into infinity on both sides. We want to be able to calculate the distance between such a line and a point, or the point of intersection ot two lines if it exists. 2) Ray We consider a ray being a line with one endpoint or origin, and extending into infinity. Here also we want to be able to calculate the distance between a ray and a point, or between two rays, or points of intersections etc. 3) Direction In order to implement a line and a ray as descibed above, we have introduced the concept of direction (which is basically the same as a direction unit vector, or an equivalent angle). Is there a concept like this in GGL? How could we calculate the angle of a line segment in GGL? Best regards Peter PS: By the way: I find the acronym GGL unfortunate. For me it feels a bit awkward, and I was typing it wrong all the time while preparing this text. Everytime I use it I'm forced to think hard about what it means, in order to get it right. I would prefer a more descriptive name like geometry or geolib, or something else that can be memorized better.

1 0

getting started
by anirvana mishra 12 Nov '09

12 Nov '09

hello everybody, I have been using c++ for quite a long time but never thought of doing some development work for it.But now i think is the high time to contribute to this community and am looking forward for some good development work. can anyone tell as how to get started? Thanks -- All the best.

2 1

Boost.Variant is not EqualityComparable
by brook＠biology.nmsu.edu 12 Nov '09

12 Nov '09

I just ran into the case that Boost Variant does not satisfy the EqualityComparable concept. While it provides operator==() and operator<() (and therefore is LessThanComparable), it does not provide operator!=(), which is required for the EqualityComparable concept. Is this by design or oversight? It seems reasonable to expect that a Boost Variant model this concept, but perhaps I am missing something. In case it is by oversight, the following patch seems to provide the missing operator. Cheers, Brook --- boost/variant/variant.hpp.orig 2009-05-13 21:21:59.000000000 -0600 +++ boost/variant/variant.hpp 2009-05-25 19:21:40.000000000 -0600 @@ -1681,6 +1681,8 @@ return rhs.apply_visitor(visitor); } + bool operator!=(const variant& rhs) const { return !(*this == rhs); } + bool operator<(const variant& rhs) const { //

6 7

On Iteration
by Andrei Alexandrescu 12 Nov '09

12 Nov '09

My article with a draft name "Iterators Must Go (Ahead)" is now published on InformIt and mentioned on reddit.com. Due to the vagaries of posting time and reddit dynamics, the article didn't stay long on reddit's programming page so it got very few views and comments. http://www.reddit.com/r/programming/comments/a2hv3/ Please comment here and/or there and vote up if you liked it. Many thanks to the many Boost participants who reviewed the article prior to publication (see the article's last section for a full list). Andrei

4 5

GGL Extensions
by Tom Brinkman 11 Nov '09

11 Nov '09

>> The GGL team proposes an extension model, very similar to what is used by GIL. I'm not sure that the extensions proposal worked very well for GIL. I'm not sure why. Probably it was too ambitious. Initially, just try encourage a small group of interested developers to work with you on extensions. When that number becomes too large, than start thinking about a more formalized system. If people see that there are a couple of really cool extensions that were intergrated, it might just encourage others to add extensions as well.

4 4

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

11 Nov '09

>Apologies if this is a silly question as I'm not familiar with earlier >versions of MSM, but how does this library different from Boost.Statechart? This is not a silly question but one which is begging for controversy ;-) I hope this is not starting a flame war, so from my understanding, there are advantages of using Msm on several points: - speed: Msm is much faster than statechart (see the performance page. Usually more than 20 times faster). - Design: * Msm makes heavier use of metaprogramming = longer compilation, higher speed * No RTTI and no virtual functions * Msm tries to follow the principles of declarativeness described in the book "C++ Template Metaprogramming". This leads to an interface, which is, in my opinion, easier to use. * Again in my opinion, entry/exit/guards are better with Msm. With Statechart, you have to write guard handling yourself and you don't get the event as parameter in the entry/exit. * Actions / guards are more reusable as you can provide a functor object * States are also more reusable as they don't know their containing state machine or other states (due to in-state transition-table definition in Statechart) - UML support. Msm supports forks, UML-conform event dispatching in orthogonal regions (which is that every region gets a chance to handle a given event), entry/exit pseudostates and anonymous transitions (transitions without an event). - Usage: Msm also supports different frontends. For example, eUML tries to hide metaprogramming as much as possible and tries to look like an UML diagram. This also help writing state machines easier with Msm. - Model-Driven approach. You will find in the doc directory my BoostCon paper (the only PDF) where I describe my analysis of MDD with both frameworks. But this is ultimately a matter of taste (as I will of course prefer Msm and Andreas will likely prefer Statechart), and you should take whatever fits your needs better and you are more comfortable with, so I'd advise you to look at both and see what you prefer (and even better, what I could do to improve Msm).

2 1

[1.41.0] Release plans
by Beman Dawes 11 Nov '09

11 Nov '09

The plan to do a Beta 2 has been canceled at the urging of Robert Ramey, Eric Niebler, Paul Bristow, and others. We will stick to more-or-less the same schedule, but do a final release rather than a Beta 2 release. Please complete all merges to branches/release by 9 PM, Friday, November 13th, US Eastern time (02:00, Nov. 14 UTC) That's a day earlier than expected, but will be a lot more convenient for me if we can hold to it. Thanks, --Beman

1 0

[integer] long long warning
by Vladimir Prus 11 Nov '09

11 Nov '09

Hi, if, in SVN trunk as of revision 57535, I go to libs/program_options/test and run: bjam warnings=all cxxflags=-Wextra I get a pile of warnings like this: ../../../boost/integer.hpp:145:24: warning: use of C99 long long integer constant These are actually only warnings that are now printed. Does anybody know what to do with them? Thanks, Volodya

6 11

[BGL] Trying to get a correclty working Parallel BFS code
by Sandeep Gupta 11 Nov '09

11 Nov '09

Hi All, I have spent significant effort on parallel bfs. Currently its almost working. I would really appreciate some help to get it running correctly. I have attached the code (self contained and requires no input file). I think I have followed all the guidelines regarding distributed property maps mentioned in the docs ( http://www.osl.iu.edu/research/pbgl/documentation/graph/breadth_first_searc… ). I am out of ideas of where things can could have gone wrong. The correct output of input graph 0 --> 1 2 1 --> 2 3 2 --> 3 3 --> 4 6 4 --> 5 5 --> 6 --> should be Node ID : Level 0 : 0 1 : 1 2 : 1 3 : 2 4 : 3 5 : 4 6 : 3 But when ran with 2 processes the output comes out to be Node ID : Level 0 : 0 1 : 1 2 : 1 3 : 2 4 : 3 5 : 4294967295 6 : 3 Not sure why this is happening. Any suggestions or pointers would indeed be quite appreciated. Thanks for your time. -Sandeep

3 23

[1.41, thread] small compile fix
by Tim Blechmann 11 Nov '09

11 Nov '09

hi all, trying the lastest release branch, i need the following fix to be able to compile the boost.thread sources ... would be great, if it could make it to the 1.41 release ... thnx, tim diff --git a/libs/thread/src/pthread/timeconv.inl b/libs/thread/src/pthread/timeconv.inl index 5ec3b17..50518c1 100644 --- a/libs/thread/src/pthread/timeconv.inl +++ b/libs/thread/src/pthread/timeconv.inl @@ -6,6 +6,8 @@ // boostinspect:nounnamed +#include <cassert> + namespace { const int MILLISECONDS_PER_SECOND = 1000; const int NANOSECONDS_PER_SECOND = 1000000000; -- tim(a)klingt.org http://tim.klingt.org Relying on the government to protect your privacy is like asking a peeping tom to install your window blinds. John Perry Barlow

1 0

[1.41] cmake references in getting started
by Vladimir Prus 11 Nov '09

11 Nov '09

Hi, I went to fix a broken URL in getting started, and noticed that it now has references to CMake. I have a couple of questions: 1. Why is that reference made inside "Easy Build and Install" section, which was specifically writen by myself to describe the brand new "bootstrap + bjam" procedure? 2. Why is getting started including reference for experimental build system at all? The commit that added this is: r56947 | troy | 2009-10-17 07:33:43 +0400 (Sat, 17 Oct 2009) | 5 lines Replacement for boost.cmake on trunk and release: notices that it exists in the getting started guide. and I don't think the change was discussed. Thanks, Volodya

3 4

Making toolchains easier to use
by Beman Dawes 11 Nov '09

11 Nov '09

I just tried to rebuild the Getting Started Guild on Windows 7, something I had done many times on XP. >cd \boost\trunk\more\getting_started >bjam The build failed. Inspecting the output turned up the message: python: can't open file 'C:/Program Files/Python26/Lib/site-packages/docutils/tools/rst2ht ml.py': [Errno 2] No such file or directory Ah! Because of the Win 7 upgrade, Python was reinstalled, and docutils needs to be installed again, too. Did that, but same problem. Ah! I remember from past pain. The docutils install doesn't install "tools", you have to do that by hand. Did that. That worked. Only half an hour of my time wasted. If I had been a new user or developer, it would have been much longer. Here is what I think should have happened: When the build failed, a dialog box or console message should have popped up telling me that docutils/tools aren't installed, and asking me if I wanted docutils/tools to be installed. If I answered yes, the necessary download and install steps should have been performed automatically. Furthermore, I think the same thing should happen for any tool used by Boost, whether it be for documentation or other purposes. I guess I mean any tool run via bjam, at least at first. This sort of auto install when needed is happens routinely for non-boost apps on my Ubuntu system. It saves much time and aggravation. Thoughts? --Beman

1 0

proposal interval container; ITL moved to the boost sandbox
by Joachim Faulhaber 11 Nov '09

11 Nov '09

Dear boosters, after completion of a lot of boostification work I moved my Interval Template Library to the boost sandbox in the boost project centric form: https://svn.boost.org/trac/boost/browser/sandbox/itl itl boost itl [itl_xt] [validate] libs itl [itl_xt] [validate] I have split up the original library into three parts: (1) itl, (2) itl_xt and (3) validate. Core part 1 'ITL' contains all interval container class templates. Only this part will be prepared for a formal submission. Part 2 'itl_xt' contains extended parts of the original library that do not belong to the core interval container data structures and might be proposed for later extensions. Part 3 'validate' contains the sources for the law based test automaton 'LaBatea' that has been used for an automated check of the ITLs correctness. Parts 2 and 3 do not yet conform boost standards and naming conventions and are not yet intended as contributions to boost. On the core ITL-part I have done the following: + Removed all virtual functions via introduction of mixins + Integrated deeper into boost libraries replacing own code by e.g. boost::type_traits and boost::mpl + Minimized the class template interfaces by transforming member functions into non member function templates. + Made interval containers more interoperable by overloading operators and global function templates. + Wrote a test suite using boost unit test tools. Tested for boost-instance types boost::date_time and boost::rational + Provided jamfiles to build and run examples and tests. + All examples and tests have been compiled, linked and run successfully with msvc_9.0 and gcc_3.4.4(cygwin). Next I am going to write boost style html-documentation. >From the boost web page I don't see a clear recommendation for a preferable way of doing that. Handcoded? Generated with BoostBook? Is there a reference library that has an exemplary standard documentation? Cheers Joachim

3 4

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

11 Nov '09

Hi Eric, > Congrats! So is this a review request? Nudge, nudge. :) Yes. As soon as a review date is decided, there will be an announcement. Msm already has a review manager (Dave), we now have a powerful version, we just need a review date. >Do we really need another lambda? I hope that with a proto-based >Phoenix, we can retire all the mini-lambdas that have been >proliferating. (I'm guilty of this, too.) I expected that one :) Right now, yes I need. I need a tool to generate an mpl::vector of transitions (meaning with actions and guards), which I didn't manage to get to work with phoenix (maybe there is a way but I didn't see it). Of course, a proto-based phoenix would be of great help and if needed, I'd be happy to help on this. Regards, Christophe

2 1

GGL Review
by Tom Brinkman 11 Nov '09

11 Nov '09

GGL Review I'm very happy to see that that GGL is now ready for inclusion into boost. I have been following this library for the last couple of years. During that time, I have spent probably 5 hours looking over the code, reading the documentation and compiling the samples. I have a background in GIS applications. Count me as an enthusiastic supporter of this library and as a "yes" vote for inclusion into boost. I have no doubt that GGL will become one of the more popular libraries in boost. Thank you to Barend Gehrels, Bruno Lalande and Mateusz Loskot for submitting it to the public domain and to boost. The samples and tests are thorough and compile without errors or warnings on the latest version of the Intel compiler. The code follows all expected boost conventions. Tom Brinkman

2 1

Confused by regression testing "release" branch summary and unresolved issues
by Phil Richards 10 Nov '09

10 Nov '09

I expect the answer is blindingly obvious, but I've read http://www.boost.org/development/testing.html#Understanding and I don't understand. I'm looking at: http://www.boost.org/development/tests/release/developer/summary.html and: http://www.boost.org/development/tests/release/developer/issues.html I would expect that issues.html would list all the non-expected failures shown in the summary.html page, but it doesn't. (Even tough that's what the "Purpose" seems to claim.) The are a raft of gcc 4.4 failures (not marked as expected - some of them should be, btw), but there are no gcc 4.4 failures at all shown on the issues.html page. What is the relationship between these two pages? Is it documented anywhere? Is it actually an issue that the release has quite a lot of unresolved issues for gcc 4.4? Phil -- Phil Richards, <news(a)derived-software.ltd.uk>

3 4