- Boost - lists.boost.org

Re: [boost] [C++-sig] [Boost.Python] Request to merge some patches from trunk into 1.40 branch (was: Re: PySide has been released)
by Stefan Seefeld 24 Aug '09

24 Aug '09

Anderson, let me forward that mail to the main boost list, and ping Beman (release manager) and David (boost.python maintainer). Beman, David, if it's not too late, I may help merge trunk to the release branch. Let me know... Stefan On 08/21/2009 08:08 AM, Anderson Lizardo wrote: > I think it was not clear in the announcement, but PySide uses Boost.Python. > > And for it to work properly, we need a few patches that are already in > Boost SVN trunk, but in none of the release branches. > > Therefore, is it possible to get these patches merged into the 1.40 > release branch before the final release? That would make life a lot > easier for other distros to try PySide without requiring to apply > patches separately. > > The relevant commits are listed in http://www.pyside.org/downloads/, they are: > > Add generic call operator support. > https://svn.boost.org/trac/boost/changeset/47846 > Support C++ enums which have the same value. > https://svn.boost.org/trac/boost/changeset/53660 > Fix unsigned integer converters. > https://svn.boost.org/trac/boost/changeset/54919 > Fix unsigned integer converters (update). > https://svn.boost.org/trac/boost/changeset/54923 > > IMHO these patches fix important bugs in Boost.Python, and the first > two were in trunk even before the 1.39 release, but were never > merged... > > Thanks in advance, > -- ...ich hab' noch einen Koffer in Berlin...

3 2

[Boost.Python] Request to merge some commits from trunk into 1.40 branch
by Anderson Lizardo 24 Aug '09

24 Aug '09

[I accidentally sent this e-mail to the C++-sig mailing list, please don't consider it a cross-post] As announced on the C++-sig mailing list, PySide was released: www.pyside.org. I think it was not clear in the announcement, but PySide uses Boost.Python. And for it to work properly, we need a few patches that are already in Boost SVN trunk, but in none of the release branches. Therefore, is it possible to get these patches merged into the 1.40 release branch before the final release? That would make life a lot easier for other distros to try PySide without requiring to apply patches separately. The relevant commits are listed in http://www.pyside.org/downloads/, they are: Add generic call operator support: https://svn.boost.org/trac/boost/changeset/47846 Support C++ enums which have the same value: https://svn.boost.org/trac/boost/changeset/53660 Fix unsigned integer converters: https://svn.boost.org/trac/boost/changeset/54919 Fix unsigned integer converters (update): https://svn.boost.org/trac/boost/changeset/54923 I think these patches fix important bugs in Boost.Python, and the first two were in trunk even before the 1.39 release, but were never merged... Thanks in advance, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil

2 1

[persistence] interface overview
by Stefan Strasser 24 Aug '09

24 Aug '09

A while ago, I proposed a persistence library and there was some interest. Since then, the prototype has evolved into a feature-complete, reasonably optimized, implementation. Here's a quick recap of what the library is supposed to do: --------- int main(){ ... shared_ptr<A> shared(new A); db_ptr<A> db(new A); ... } // "shared" is destroyed, "db" is saved to disk to ensure data consistency, there are transactions introduced: transaction tx; //change_objects tx.commit(); if change_objects throws an exception, causing tx to be destroyed without commit() being called, all changes are undone. --------- there is no complete documentation yet, but I've written an overview of the library interface, which can be found here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=overvi… I'd appreciate your comments. please note the "open issues" section.

4 5

[unordered] allocators and EBO
by Thorsten Ottosen 24 Aug '09

24 Aug '09

Hi James, (Sorry I called you Jeremy in the other post). When the allocator is empty, you should avoid storing them as members in different internal structures, and make the allcator a base class of some of these structures. Thanks -Thorsten

2 2

[mpl] patch for non-typeof map::insert
by Steven Watanabe 24 Aug '09

24 Aug '09

AMDG mpl::map insert can fail after an erase, because it uses size instead of order to determine the next order. The patch https://svn.boost.org/trac/boost/attachment/ticket/2042/insert_impl.hpp.pat… fixes this. Okay to commit? In Christ, Steven Watanabe

3 3

bjam - help please
by Edward Grace 23 Aug '09

23 Aug '09

Since I'm trying to Boostify (is that a legitimate word now? - heck you can verb anything these days) my code, I decided to try bjam: Gulp, having been weaned on automake and fiends [sic] it looks like it should be easy enough, but I've fallen at the first hurdle: In Jamroot: using gcc : 4.4 : g++-4 ; exe example_basic : example_basic.cpp : <include>. ; The <include>. line, as I understand it will mean the #include <blah> that I use will pick up stuff in the same directory as the source file (this seems ok). My problem is the link stage, $ bjam example_basic ...found 53 targets... ...updating 1 target... gcc.link bin/gcc-4.4/debug/example_basic /usr/bin/ld: unknown flag: --start-group collect2: ld returned 1 exit status "g++-4" -o "bin/gcc-4.4/debug/example_basic" -Wl,--start- group "bin/gcc-4.4/debug/example_basic.o" -Wl,-Bstatic -Wl,- Bdynamic -Wl,--end-group -g ...failed gcc.link bin/gcc-4.4/debug/example_basic... I've no idea where all this --start-group stuff comes from -- never seen it before. Any ideas? -ed ------------------------------------------------ "No more boom and bust." -- Dr. J. G. Brown, 1997

2 6

regex/ICU fix
by Vladimir Prus 23 Aug '09

23 Aug '09

As reported previously, --build-type=complete does not work if ICU is also configured. The below patch makes build process suppress building static Boost.Regex in this case. The wording is as follows: ghost@wind:~/Work/Boost/boost-svn$ bjam link=static runtime-link=static --with-regex .... warning: when using ICU, Boost.Regex must be a dynamic library warning: forcing link=shared runtime-link=shared for Boost.Regex Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include Note that the warning is printed before the message that we're using ICU, which is ugly, but what I have is a minimal change. I'll tweak those configuration messages for 1.41. Comments? Ok for release branch? - Volodya

3 13

[1.40] PDB fix merge
by Vladimir Prus 23 Aug '09

23 Aug '09

Steven Watanabe has recently reported that a bug in Boost.Build caused boost libraries to be rebuilt when bjam is invoked again after a successful build. This affects msvc. I've just now reproduced and fixed this on trunk: https://svn.boost.org/trac/boost/changeset/55717 Since this fairly annoying behaviour, I would like to merge it to release branch. OK? I'd expect at least on trunk msvc tester to cycle shortly, so I should be able to merge tomorrow morning. Thanks, Volodya

3 3

[mirror] automatic reflection / boost.mirror still in development?
by strasser＠uni-bremen.de 23 Aug '09

23 Aug '09

is boost.mirror (sandbox: https://svn.boost.org/svn/boost/sandbox/mirror/boost/mirror/ ) still in development? looks a bit abandonded to me. when I first saw it I was not too excited about it because I don't think a reflection library that requires the user to register every c++ construct manually is very usable. but GCC recently (finally) integrated a plugin infrastructure, so it would be possible to automatically generate reflection information. I've worked with the GCC internal tree before, it's pretty close to the c++ constructs in the early stages. something like this would be possible: test.cpp: //include result of GCC plugin of test.cpp: #include "test.rpp" class myclass{ int myvar; double myfunction(); }; int main(){ typedef reflection::myclass::myvar::type ret; BOOST_STATIC_ASSERT(is_same<ret,int>::value); typedef reflecton::myclass::myfunction::type::return_type ret; BOOST_STATIC_ASSERT(is_same<ret,double>::value); } //or, lookup in MPL map: template<class T> char const *lookup_name(){ return reflection::type<T>::name; } or anything else you can do with MPL sequences, like iterating over class members. this would have some downsides though: - GCC the library user must install GCC. other compilers can still be used for compilation, but the code to be reflected must be portable to GCC. - license the code generating plugin must be GPLed. that does not affect the license of the user code or other parts of boost though. acceptable downsides imho, given that there are no practical alternatives in sight, like a standard conforming boost C++ parser. what do you think?

4 4

[Exception] Why is there no non-const version of get_error_info?
by Adam Badura 23 Aug '09

23 Aug '09

get_error_info takes a const exception object and returns a pointer to const data object of respective error_info. But why is there no way of getting non-const pointer (which would allow to modify the data)? This is especially strange because operator << can be used to add data to a const exception object so I don't see reason for not being able to get modifiable data back (at least from non-const exception object). Having this would allow me to safely gather exception data before throwing or during exception propagation. What I wanted was to insert an empty vector of data to the preconstructed exception object. Then obtain the vector with get_error_info (since operator << adds a copy I have to get the actual object). Then call reserve on the obtained vector and start the actual operation. During the operation I can gather (possible) error data and safely add it to the vector since memory is already reserved. In the end if any error data was gathered I will throw the preconstructed exception object. In reasonable implementation this should be safe as well. (Similar thing might be done while propagating the exception.) With current code (lack of non-const get_error_info) it is not possible. I have to get the vector from exception object. Then add data to the vector (this may fail). Then again add vector to the exception object (overwriting old vector; this may fail). And in the end throw (if needed). Alternatively I could preconstruct vector, reserve space add data to it. Then in the end if I will throw the data vector is there for me. However I still have to add it to the exception object and this still may fail. Adam Badura

4 15