- Boost - lists.boost.org

Current cvs build broken (/boost/python/detail/signature.hpp)
by Neal D. Becker 15 Sep '04

15 Sep '04

/usr/local/src/boost.cvs/boost/python/detail/signature.hpp: In static member function `static const boost::python::detail::signature_element* boost::python::detail::signature_arity<11>::impl<Sig>::elements()': /usr/local/src/boost.cvs/boost/python/detail/signature.hpp:34: error: syntax error before `;' token...interrupted .

2 1

serialization tests with intel 8.0 on linux
by Robert Ramey 15 Sep '04

15 Sep '04

There are a group of test failures of the serialization library on intel 8.0 on linux. See http://www.meta-comm.com/engineering/boost-regression/developer/serializatio n.html These are all associated with serialization of collections. I would guess that these are probably all variant manifestations of the same problem. Other interesting facts are: a) intel 7.1 passes on linux and win32 b) intel 8.0 passes on win32 Is there someone who has an interest in this platform would like to look into this? It would be very helpful. Robert Ramey

2 1

spirit 1.8 / vc 8.0 test results
by Robert Ramey 15 Sep '04

15 Sep '04

Spirit 1.8 with vc 8.0 is showing some test failures which impact the serialization library. In particular, the chest test is failing. Is this going to be addressed? Perhaps the vc 8.0 compiler being used for the test should be updated to the latest version if it hasn't been already. I think this would be very useful. Robert Ramey

3 2

problems with serialization regression tests
by Bronek Kozicki 15 Sep '04

15 Sep '04

I have a problem when running regression tests on Comeau compiler (toolset como- win32- 4.3.3- vc7.1) . Three tests: test_set_text_archive test_set_binary_archive test_set_xml_archive are taking above 1.5GB memory when running, thus my machine is slowing to crawl due to memory trashing (I have only 1GB RAM). I think there's something wrong with these tests? B.

1 0

Boost License Permission
by Kevlin Henney 15 Sep '04

15 Sep '04

I give permission for all my contributions to Boost to be moved to the Boost Software License Version 1. Kevlin Henney -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

1 0

[filesystem]: bug and patch in path_posix_windows.cpp
by Angus Leeming 15 Sep '04

15 Sep '04

There are lots of "#ifdef BOOST_WINDOWS ... #endif" blocks wrapping code to handle the ':' in libs/filesystem/path_posix_windows.cpp. In one place only is the preprocessor block missing, which I believe is a bug. Patch attached. Silly test case. Without the patch, this: #include <boost/filesystem/path.hpp> #include <iostream> #include <string> namespace fs = boost::filesystem; int main() { std::string const PATH="/usr/local/bin:/usr/bin:/bin"; fs::path const path(PATH, fs::no_check); std::cout << PATH << '\n' << path.native_file_string() << std::endl; return 0; } Produces /usr/local/bin:/usr/bin:/bin /usr/local/bin:usr/bin:bin under *nix. Regards, Angus

2 1

recursive mutex and condition
by James Ahlborn 15 Sep '04

15 Sep '04

hey, I was wondering if any of the boost developers could tell me if recursive mutexes are supposed to work with conditions? From the code, it would seem to be the case, however in reality things aren't so happy. I have a fairly small test case which shows that the locking doesn't work if you recursively lock a mutex and then try to do a condition wait/notify. I'm testing this on red hat 7.3 and fedora core 2. My guess as to why it's broken is because the boost condition uses posix recursive mutexes internally, which also seem to fail the recursive mutex/condition test (at least on the OS's mentioned above). Anyone have any thoughts on this? I'll include my test case below. The error (for me) happens that when Thread2 releases the "inner" lock, Thread1 proceeds, even though Thread2 should still be holding the lock. (ps- i'm aware that there are some mem leaks in the program, i just simplified it for testing). thanks, -james ------------------------------------------------------- #include <string> #include <iostream.h> #include <boost/thread.hpp> #include <boost/smart_ptr.hpp> #include <boost/bind.hpp> using namespace boost; using namespace boost::detail::thread; class ThreadBase : private boost::noncopyable { public: void start() { m_thread.reset(new boost::thread(boost::bind(&ThreadBase::run, m_weakThis.lock()))); } void join() { m_thread->join(); } protected: virtual void run() = 0; ThreadBase() : m_thread(), m_weakThis() {} virtual ~ThreadBase() {} void initWeakThis(boost::weak_ptr<ThreadBase> weakThis) { m_weakThis = weakThis; } boost::shared_ptr<boost::thread> m_thread; boost::weak_ptr<ThreadBase> m_weakThis; private: }; class Thread2 : public ThreadBase { recursive_mutex* _mutex; condition* _cond; protected: Thread2(recursive_mutex* mutex, condition* cond) : ThreadBase(), _mutex(mutex), _cond(cond) {} public: static shared_ptr<Thread2> create(recursive_mutex* mutex, condition* cond) { shared_ptr<Thread2> tmp(new Thread2(mutex, cond)); tmp->initWeakThis(tmp); return tmp; } virtual ~Thread2() { cerr << "Thread2 dying\n"; } virtual void run() { cerr << "Thread2 acquiring lock(1)\n"; recursive_mutex::scoped_lock sl1(*_mutex); cerr << "Thread2 acquiring lock(2)\n"; { recursive_mutex::scoped_lock sl2(*_mutex); cerr << "Thread2 sleeping...\n"; ::sleep(5); cerr << "Thread2 signalling...\n"; _cond->notify_all(); cerr << "Thread2 releasing lock(2)\n"; } cerr << "Thread2 sleeping (again)...\n"; ::sleep(5); cerr << "Thread2 releasing lock(1)\n"; } }; class Thread1 : public ThreadBase { recursive_mutex _mutex; condition _cond; protected: Thread1() : ThreadBase() {} public: static shared_ptr<Thread1> create() { shared_ptr<Thread1> tmp(new Thread1()); tmp->initWeakThis(tmp); return tmp; } virtual ~Thread1() { cerr << "Thread1 dying\n"; } virtual void run() { cerr << "Thread1 acquiring lock(1)\n"; scoped_lock<recursive_mutex> sl1(_mutex); cerr << "Thread1 acquiring lock(2)\n"; { scoped_lock<recursive_mutex> sl2(_mutex); cerr << "Thread1 starting Thread2\n"; shared_ptr<Thread2> t2 = Thread2::create(&_mutex, &_cond); t2->start(); t2.reset(); cerr << "Thread1 waiting\n"; _cond.wait(sl2); cerr << "Thread1 releasing lock(2)\n"; } cerr << "Thread1 releasing lock(1)\n"; } }; int main(int argc, char** argv) { cerr << "Main Starting...\n"; shared_ptr<Thread1> t1 = Thread1::create(); t1->start(); t1->join(); cerr << "Main First Run\n"; // run it again t1->start(); t1->join(); t1.reset(); cerr << "Main Done\n"; return 0; }

1 0

Re:Re: [boost] Re: mpl apply_if.hpp question
by Robert Ramey 15 Sep '04

15 Sep '04

Aleksey wrote >> But, really, how hard can a global search/replace be? Or is Spirit >> 1.6.1 archived? >No, it's not. Or, to be exact, the latest 1.6.x version which we are >supposed to compile against is not -- >http://article.gmane.org/gmane.comp.parsers.spirit.devel/1964. >I'd _much_ prefer to have this fixed by search & replace, more so because >it'd have to be done eventually sooner or later anyway, if Spirit 1.6.x is >meant to live past this release. I'm agnostic on this - I just want to be able to run the serialization library on all the platforms its designed to run on. If spirit 1.6.x gets fixed to use eval_if - the issue disappears. I don't have the access to fix it and wouldn't do so anyway. I'm afraid to touch it - If I break it then I have to buy it. So, I've checked in apply_if pending fixup in spirit 1.6.x at which point the apply_if can be removed (again). This is just a spirit issue - no changes in the serialization library itself are indicated. Robert Ramey

4 3

Explicit test markup problems
by Vladimir Prus 15 Sep '04

15 Sep '04

Hello, the colors on http://www.meta-comm.com/engineering/boost-regression/developer/program_opt… seems to be incorrect: 1. I've tried to mark all *dll tests on como as failing, but they are still yellow. 2. I never marked vc7 as failing, but still it's deep green (unexpected pass). Any ideas what's wrong? - Volodya

2 1

program_options problem on platforms with incomplete wchar_t
by Harri Pasanen 15 Sep '04

15 Sep '04

Hello, Looking at program_options headers, it does not appear to guard against BOOST_NO_STD_WSTRING being defined? This poses a problem when using gcc on platforms such as Solaris, HP-UX, as functions like std::codecvt<wchar_t, char, __mbstate_t>::do_length(...) are not defined in the libstdc++. Is this a know problem, should I come up with a patch, or what? Regards, Harri Pasanen This message, including any attachments, is intended only for the person(s) to whom it is addressed. If you received it in error, please let us know and delete the message from your system. This message may be confidential and may fall under the duty of non-disclosure. Any use by others than the intended addressee is prohibited. Trema shall not be liable for any damage related to the electronic transmission of this message, such as failure or delay of its delivery, interception or manipulation by third parties, or transmission of viruses or other malicious code. This message, including any attachments, is intended only for the person(s) to whom it is addressed. If you received it in error, please let us know and delete the message from your system. This message may be confidential and may fall under the duty of non-disclosure. Any use by others than the intended addressee is prohibited. Trema shall not be liable for any damage related to the electronic transmission of this message, such as failure or delay of its delivery, interception or manipulation by third parties, or transmission of viruses or other malicious code.

2 1