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

Now Accepting Mentor Applications for Google Summer of Code 2009
by Hartmut Kaiser 12 Mar '09

12 Mar '09

http://google-code-updates.blogspot.com/2009/03/now-accepting-applications-f or-google.html Will we apply this year? What's the procedure? Can I help? Regards Hartmut

4 10

[Property Tree] Maintenance Takeover
by Sebastian Redl 12 Mar '09

12 Mar '09

Hi, I'd like to officially announce that I have, with Marcin Kalicinski's permission, taken over maintenance of the Property Tree library. Over the next week I'll take a good look at it and see what there is to be done for inclusion in an official release. At the moment, it seems like the main problem is insufficient and outdated documentation. Marcin also had other concerns regarding the library (performance and interface), and I'll see if they should be addressed before an official release as well. (Interface concerns are more pressing, obviously.) If anybody has additional comments on the library, change requests, performance data, or simple discussion of ideas, now is the time to let me now. Sebastian

4 3

[math] calculate derivative automatically.
by Dongfei Yin 12 Mar '09

12 Mar '09

Hi, I notice that some one may not have vc++9 with sp1, if so, there will be many compile errors. because I use #include <tuple>, the earlier version does not have such a library. so I made a version for boost::tuples::tuple. a file named "[math]AD.zip" in vault. BTW: I am wondering whether I do something wrong, there is no responding about this subject for a long time. Dongfei.

4 3

Re: [boost] [math] calculate derivative automatically.
by Dongfei Yin 12 Mar '09

12 Mar '09

Hi, Thank you for your explanation, to simplify a expression somewhat has relationship between philosophy. Any way, just a practice. thank you . Dongfei.

1 0

[Boost][GSoc] boost.crypto
by Kasra 12 Mar '09

12 Mar '09

Hi, I am looking into enrolling for GSoc program. I am checking for interest on a crypto library. The idea is to have a library that provide high level facilities for the user i.e. kernel entropy sources, random pools, CS PRNGs and etc. I am wondering if there is an interested party for mentor ship of the program? With Best Regards -- Kasra

1 0

Is Boost going to participant in this year's Google Summer of Code?
by Haoyu Bai 12 Mar '09

12 Mar '09

Hi, I know Boost is a mentor organization for last year's GSoC, so how about this year? I'm interesting in contribute to Boost.Python's py3k support. Though the project may be mentored under PSF, but it is best if it can be mentored under Boost. The time left for orginazation application it not so much, any ideas? Thanks! -- Haoyu Bai

1 0

Re: [boost] [C++-sig] [Python] GSoC and Python 3.0 Support
by Haoyu Bai 12 Mar '09

12 Mar '09

On Thu, Mar 12, 2009 at 4:50 AM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: > On 11 Mar 2009 at 13:42, Ravi wrote: > >> On Wednesday 11 March 2009 12:38:55 Haoyu Bai wrote: >> > > 1. Thread safety >> > > 2. PyFinalize support >> > > 3. Easier methods to write to_python/from_python converters >> > > 4. Python 3.0 support >> > > 5. Ability to extend the fundamental PyTypeObject used by boost.python > > My thread safety patch is still working to my knowledge. It sure > would be lovely to have it officially integrated. I'd also like to > see PyFinalize working though maybe not "complete" in the sense of a > total cleanup (just "good enough"). > > I would say that any GSoC project should choose *one* of the above > rather than try combining them. Better to do one thing well and in > stages than many things at once (unless you have loads of spare > time!). > > I have been out of commission development-wise during the last few > years as I have been undertaking some very time consuming academic > study - hence I have been very quiet on here. However, I finally > become free come this June and at long, long last I finally can > return to my own self-directed study (but now I have a whole pile of > bits of paper to officially say I can do what I was already capable > of). I will certainly be updating my TnFOX library for sure anyway, > and that means fresh Python bindings. > >> > Thanks! Seems there's a lot of interesting. So would anyone willing to >> > mentor this? >> >> Sadly, I suspect that finding a mentor will be difficult (perhaps even more >> difficult than the actual project). Off the top of my head, the following >> folks come to mind: >> - Dave Abrahams >> - Stefan Seefeld >> - Ralf Grosse-Kunstleve >> - Roman Yakovenko >> You might try contacting them off list or on c++-sig (cc'ed on this email). > > It's not /quite/ as easy as that ... Google want a mentoring > organisation rather than just a mentor and it has to be an approved > one. I could volunteer as mentor but I wouldn't qualify as I don't > come with an organisation attached. I'd need an approved organisation > to adopt me. > >> I did not mean to imply that the features I requested should be part of your >> GSoC. Thread safety & PyFinalize support would each be worth a GSoC project >> just by themselves, IMHO. If you will be tackling python 3.0 support, it might >> be possible to combine it with greater support for embedding python since much >> of the work in both aspects would be about wrapping python C API for C++ >> programmers. > > As mentioned before, thread safety is actually fairly trivial as all > the required work is already done. There is certainly some work > involved in writing a test suite and making my patch much more > generic as my patch was specifically designed to be diff-friendly to > any Boost alterations, and it doesn't make for good code. I would be > happy to mentor this project if we can find an approved mentoring > organisation to adopt me. It certainly would be a good GSoC for a > student programmer. > > PyFinalize() is likely just a hard slog in catching all the code > paths you wouldn't expect. It's harder than thread safety, but doable > as a GSoc. > > Adding Python 3.0 support ... I am afraid I have no idea as I've been > out of the coding scene for two years now, but it does sound big and > complex. But it's something I'm interested in though I'd be not much > use as a mentor except as in general Boost.Python programming. > > So, I guess you got a bit of a mentor if you'd like. BTW, I couldn't > start mentoring till the start of June as I have my final project due > then. But that fits the GSoC timetable just perfect. > > If you want to know more about my suitability, search this mailing > list. > > HTH, > Niall > > > Hi, Thanks Niall, it is great that you are willing to mentor. Also you don't need to worry about the Python 3.0 things, since I have worked on it and have knowledge about the API change. On the other side, I need guidance of Boost.Python internals, which you are familiar. Your time table is OK, but should notice that there's some trival things before the coding started, eg. sign up as mentor and evaluating proposal, hope you have time to do so. Hopefully you will be a great mentor! :-) One issue is that seems Boost is not going to participant in this year's GSoC as a mentor organization. (Anyone knows the real situation please clarify this, thanks!) If so, the project may could be attached to PSF, since it is Python related. We may limit the scope of this project to py3k support and thread-safety. I'll try to learn more about Boost.Python internals and see if the scope is feasible. Thanks you all! :-) -- Haoyu Bai

1 0

Re: [boost] [scope_exit] Boost.ScopeExit capturing 'this'
by Kim Barrett 12 Mar '09

12 Mar '09

At 8:35 AM +0000 3/10/09, adam.butcher(a)selex-comms.com wrote: >The enhancement allows capturing of 'this' in the BOOST_SCOPE_EXIT >capture sequence allowing access to any class members within the body. FWIW I ran into this problem almost immediate upon starting to use BOOST_SCOPE_EXIT, and it seems to be a common situation in my usage. >Member access for the enclosing class can be performed with the >syntax: > > (*this) -- convertible to enclosing 'this' > (**this) -- enclosing 'this' > (*this)->member -- accesses member 'member' of enclosing 'this' > >This syntax is perhaps controversial though I think both Alex and >myself are reasonably happy with it. Alternatives suggested were >'this_', 'this_()', 'enclosing_this', 'enclosing_this()', 'enclosing', >'enclosing()', 'self' and 'self()'. Any access syntax that doesn't have the form of a variable name will go right back to the original problem if one has a scope exit in the body of another scope exit. I've not yet needed to do something like that with BOOST_SCOPE_EXIT, but I know that I've more than once written a try/finally block that was in the finally clause of another try/finally block (in other languages, obviously).

2 2

[thread] performance of thread-local storage implementation
by Alexander Bernauer 11 Mar '09

11 Mar '09

Hi, I did some performance measurements as I wanted to find out, how expensive thread-local storage is. It turned out, that in my tests, boost's thread-local storage implementation is factor 5.5 slower than pthread's one. Why could this be? The test spawns n threads each of which increments a particular 64-bit counter. After 2 seconds the threads are shut down and joined and the counters are summed up. Between the counter objects there is enough space to rule out false sharing. Synchronization is done via a volatile sig_atomic_t, so no locks skew the tests. In the "no tls" test the counters are access directly. In the "pthread" and "boost" test the counters are accessed through thread-local storage, using pthread's and boost's implementation, respectively. The code can be found here [1] The test environment is: - Debian Lenny (gcc 4.3.2) - MacPro, 8 x Intel Xeon 2.80GHz - release variant, i.e. -O3 -finline-functions -fPIC -DNDEBUG The results are: ("factor" is ratio to "no tls" with same number of threads) type # threads counter sum factor no tls 1 558e+07 no tls 2 1116e+07 no tls 3 1674e+07 no tls 4 2237e+07 no tls 5 2811e+07 no tls 6 3372e+07 no tls 7 3943e+07 no tls 8 4784e+07 pthread 1 50e+07 11.16 pthread 2 101e+07 11.05 pthread 3 152e+07 11.01 pthread 4 203e+07 11.02 pthread 5 241e+07 11.66 pthread 6 306e+07 11.01 pthread 7 339e+07 11.63 pthread 8 434e+07 11.02 boost 1 9e+07 62.00 boost 2 18e+07 62.00 boost 3 27e+07 62.00 boost 4 37e+07 60.46 boost 5 46e+07 61.10 boost 6 56e+07 60.21 boost 7 65e+07 60.66 boost 8 79e+07 60.56 My interpretation of the results is, that using thread-local storage is quite expensive. This was somehow expected. But what's surprising is, that the boost lib introduces an other penalty of factor 5.5. Does anybody see any mistake? Or is there an explanation of why using the boost implementation is so expensive. Can it perhaps be done better? regards Alex [1] http://github.com/copton/roadrunner/tree/b2b19d752308c253e42d7c28c86f612aa6…

2 1

Re: [boost] Making friend with boost::interprocess
by Ion Gaztañaga 11 Mar '09

11 Mar '09

Oncaphillis wrote: > Of course somewhere deep in the guts of boost I get an error since > the Foo constructor is private. Who do I have to befriend in order > to make this scheme work ? At this moment you have no possibility of constructing non-constructible objects in shared memory. > Thank you > > O. Best, Ion

2 1