February 2010 - Boost-users - lists.preview.boost.org

[Boost.Asio] Compiling Boost.Asio with OpenMPI
by vibhor aggarwal 15 Feb '10

15 Feb '10

Hello, I am trying to write a program which runs using OpenMPI on our cluster and communicates the results using TCP/IP to another machine which has a network connection to the cluster. I am using Boost.Asio for the TCP/IP connection. If I remove the MPI code from the executable and compile it with g++, it connects to the remote machine without a problem. But when I add a simple MPI code to it and compile with mpicxx and execute using mpirun, it generates a connection time out in the call to socket.connect(). Any idea what might be going wrong ? Thanks. Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/

3 6

[Serialization] crash in boost::serialization::extended_type_info::key_unregister ()
by Avi Bahra 15 Feb '10

15 Feb '10

> Hi, > I had the same problem... > > This problem was fixed in the next release (1.40) > Regards, > Damien. Ok I tried this and found: a/ whereas 1.39 serialisation compiles with out _any_ warnings. 1.40 has a _blizzard_ sorry I meant avalanche of warnings on building boost and on my application of the kind: /var/tmp/ma0/boost/boost_1_40_0/boost/archive/basic_binary_oarchive.hpp:88: warning: comparison between signed and unsigned integer expressions This makes it extremely difficult to see my own warnings. Is 1.40 really production quality ? We have a policy of no warnings, so the obvious question now, is what release are these warning's fixed ? b/ Still get the same crash on program exit. Program received signal SIGSEGV, Segmentation fault. 0xb7ce3a08 in strcmp () from /lib/libc.so.6 (gdb) bt #0 0xb7ce3a08 in strcmp () from /lib/libc.so.6 #1 0x083c814d in boost::serialization::extended_type_info::key_unregister () #2 0x083c8407 in boost::serialization::extended_type_info::~extended_type_info () #3 0x081bf8cc in ~extended_type_info_typeid (this=0x8789604) at /var/tmp/ma0/boost/boost_1_40_0/boost/serialization/extended_type_info_typeid.hpp:80 #4 0x081bf98e in ~singleton_wrapper (this=0x8789604) at /var/tmp/ma0/boost/boost_1_40_0/boost/serialization/singleton.hpp:104 #5 0x0819f508 in __tcf_25 () at /var/tmp/ma0/boost/boost_1_40_0/boost/serialization/singleton.hpp:121 #6 0xb7ca3599 in exit () from /lib/libc.so.6 #7 0xb7c8cfe8 in __libc_start_main () from /lib/libc.so.6 #8 0x08053921 in _start () Oh well! I will have to go back placing all the serialisation in one translation unit and stick with 1.39. Best regards, Ta, Avi

2 1

[Serialization] crash in boost::serialization::extended_type_info::key_unregister ()
by Avi Bahra 15 Feb '10

15 Feb '10

I am using boost 1.39 on suse linux with gcc 4.2.1 and using a debug build. In order to rationalize the long compile times, I was attempting to split a file into multiple translation units. When I ran my tests, they all passed, but then crashed with a memory fault. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7cd26d0 (LWP 21897)] 0xb7d40a08 in strcmp () from /lib/libc.so.6 (gdb) bt #0 0xb7d40a08 in strcmp () from /lib/libc.so.6 #1 0x08e19924 in boost::serialization::extended_type_info::key_unregister () #2 0x08e19ace in boost::serialization::extended_type_info::~extended_type_info () #3 0x08c41afc in ~extended_type_info_typeid (this=0x92179cc) at /var/tmp/ma0/boost/boost_1_39_0/boost/serialization/extended_type_info_typeid.hpp:80 #4 0x08c41bbe in ~singleton_wrapper (this=0x92179cc) at /var/tmp/ma0/boost/boost_1_39_0/boost/serialization/singleton.hpp:104 #5 0x08c209e0 in __tcf_25 () at /var/tmp/ma0/boost/boost_1_39_0/boost/serialization/singleton.hpp:121 #6 0xb7d00599 in exit () from /lib/libc.so.6 #7 0xb7ce9fe8 in __libc_start_main () from /lib/libc.so.6 #8 0x08a833f1 in _start () It appears that boost serialisation type registration has problems when it is split into multiple files. Also it appears that most of serialisation test all appear in a single file, hence these kinds of issues can easily be missed. Is there any work around to this problem ? Best regards, Ta, Avi

2 1

[Boost Graph] Two-graphs common spanning tree problem: generic algorithm (with concept checking, of course)
by Michele Caini 15 Feb '10

15 Feb '10

Hi all, my name is Michele Caini, I write from Italy, Florence, and this is my first mail on this list. I'd like to propose a new generic implementation of the two-graphs common three algorithm, proposed first by Grimbleby and then modified by Schach, that made a revolution on the first idea basing his algorithm on the solution for the single spanning three problem proposed and developed by Mint, Read and Tarjan. This algorithm is mainly used in symbolic circuit analysis, and I develop a generic solution for my symbolic solutor: QSapecNG, Qt-based frontend for symbolic circuit solution. If Boost Graph library mantainers are interested on publishing this algorithm with the next release of library, I'm happy to submit it, and to work on to optimize the code. Thanks to all, Michele ps: sorry for my English. :-)

2 2

Re: [Boost-users] [Serialization] crash in boost::serialization::extended_type_info::key_unregister ()
by dada＠lamef.bordeaux.ensam.fr 15 Feb '10

15 Feb '10

Hi, I had the same problem... This problem was fixed in the next release (1.40) Regards, Damien. Le lundi 15 février 2010 à 10:30 +0000, Avi Bahra a écrit : > I am using boost 1.39 on suse linux with gcc 4.2.1 and using a debug > build. > In order to rationalize the long compile times, I was attempting to > split a file > into multiple translation units. When I ran my tests, they all passed, > but then > crashed with a memory fault. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb7cd26d0 (LWP 21897)] > 0xb7d40a08 in strcmp () from /lib/libc.so.6 > (gdb) bt > #0 0xb7d40a08 in strcmp () from /lib/libc.so.6 > #1 0x08e19924 in > boost::serialization::extended_type_info::key_unregister () > #2 0x08e19ace in > boost::serialization::extended_type_info::~extended_type_info () > #3 0x08c41afc in ~extended_type_info_typeid (this=0x92179cc) > at /var/tmp/ma0/boost/boost_1_39_0/boost/serialization/extended_type_info_typeid.hpp:80 > #4 0x08c41bbe in ~singleton_wrapper (this=0x92179cc) > at /var/tmp/ma0/boost/boost_1_39_0/boost/serialization/singleton.hpp:104 > #5 0x08c209e0 in __tcf_25 () > at /var/tmp/ma0/boost/boost_1_39_0/boost/serialization/singleton.hpp:121 > #6 0xb7d00599 in exit () from /lib/libc.so.6 > #7 0xb7ce9fe8 in __libc_start_main () from /lib/libc.so.6 > #8 0x08a833f1 in _start () > > It appears that boost serialisation type registration has problems > when it is split into multiple files. Also it appears > that most of serialisation test all appear in a single file, hence > these kinds of issues can easily be missed. > Is there any work around to this problem ? > > Best regards, > Ta, > Avi > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[Python]
by Oliver Rudolph 15 Feb '10

15 Feb '10

Hi folks! When trying to run Python-wrapped C++ code, I receive the following message (this was a simple call to one of the c'tors of class TextFile): Traceback (most recent call last): File "./FileTest.py", line 5, in <module> t_out = TextFile("sample.txt", "This is some sample text. It says:\n\nHello world!") Boost.Python.ArgumentError: Python argument types in TextFile.__init__(TextFile, str, str) did not match C++ signature: __init__(_object*, std::string filename, dretchy::io::DeviceDataType type, std::string content, dretchy::io::CompressionType zipper) __init__(_object*, std::string filename, dretchy::io::DeviceDataType type, dretchy::io::CompressionType zipper) __init__(_object*, std::string filename, dretchy::io::DeviceDataType type, std::string content) __init__(_object*, std::string filename, dretchy::io::DeviceDataType type) __init__(_object*, std::string filename, std::string content, dretchy::io::CompressionType zipper) __init__(_object*, std::string filename, dretchy::io::CompressionType zipper) __init__(_object*, std::string filename, std::string content) __init__(_object*, std::string filename) Strangely enough, this only happens when doing so on my openSuSE 11.0 machine. If I try the same thing on my Ubuntu 9.10 notebook, it works perfectly. What could be the source of this problem? The code is a bit lengthy, so I attached the non-compilable headers only. Personally, I presume the error is rooted in the C-string / C++ std::string conversion. The Python wrapping itself was done via Py++, the boost libs in use are of version 1.41.0. Thanks a lot and best regards, Oliver

1 0

[accumulators] question
by Neal Becker 15 Feb '10

15 Feb '10

If I have: typedef accumulator_set<el_t,stats<tag::mean> > accum_t; Is there a way to get the count of the number of samples?

2 3

installing boost 1.34.0 in snow leopard
by Murali Krishna Pusala 15 Feb '10

15 Feb '10

Hi every one, I am trying to install boost 1.34.0 on snow leopard, it is able to build .a files but it is not building .dylib libraries. It giving an error ld: unknown option: -h krishna

5 6

Asio exception handling
by Matthias Vallentin 15 Feb '10

15 Feb '10

Hi, Consider the example where an io_service objects is used as scheduler, with tasks handed to io_service::post(). According to the manual [1], exceptions should propagate to the caller of io_service::run. However, this does not seem to be the case with the attached example. Essentially, I am doing the following: while (true) { try { io_service.post(task(&work)); io_service.post(task(&work)); io_service.post(task(&work)); io_service.run(); break; } catch (...) { // Never reached! std::cout << "catching exception" << std::endl; } } I attached a minimal example that demonstrates this issue. Any help would be appreciated. Matthias [1] http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_servi… -- Matthias Vallentin vallentin(a)icsi.berkeley.edu http://www.icir.org/matthias

2 2

[filesystem] Mac OS default codecvt facet
by Beman Dawes 14 Feb '10

14 Feb '10

On Mac OS, Boost.Filesystem currently uses std::locale() as the default, since Apple doesn't see fit to support std::locale(""). There has been a request (ticket #3928) to change the codecvt facet to UTF-8 for the Boost.Filesystem default on Mac OS. This would at least potentially be a breaking change, so I wanted to ask other's opinions before making it. Questions: * Is UTF-8 OK with Mac OS users as the Boost.Filesystem default? * Would Linux users also prefer UTF-8 as the Boost.Filesystem default? Thanks, --Beman

1 0