- Boost - lists.preview.boost.org

Re: Re: Re: IOStreams formal review -- extended
by Jonathan Turkanis 15 Sep '04

15 Sep '04

"Jonathan Turkanis" <technews(a)kangaroologic.com> wrote in message news:... > (i) buffering will be omitted, since it's hard to do correctly. > (ii) buffering will be provided, but mistakes in pointer arithmetic will cause > subtle errors > (iii) sub-optimal algorithms will be used. > > Note that two of Daryle's stream buffers suffer from defect (i). I didn't mean to imply that Daryle omitted buffering because it was hard -- I assume he had some other reason. Jonathan

1 0

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