- Boost - lists.boost.org

[1.32 release] ANN: Beta *overall* summary reports
by Aleksey Gurtovoy 19 Jul '04

19 Jul '04

A beta version of Boost-wide, multi-platform regression status reports is available at http://boost.sourceforge.net/regression-logs/developer/. Well, they are not truly multi-platform at the moment -- only one set of results is shown, but they will become such as soon as somebody uploads another set of logs. The details on this and other matters follow. The reports are re-generated every two hours against the test logs collected from http://boost.sourceforge.net/regression-logs/incoming directory. To get their platform/compiler included into the report, the regression runners need to insert "boost\tools\regression\xsl_reports\runner\collect_and_upload_logs.py" script invocation somewhere in their driver scripts (after the bjam has already run, of course). A typical command line for the script is shown below: python collect_and_upload_logs.py --locate-root=C:\Users\Administrator\boost\main\r esults\bin\ --runner=metacomm --tag=CVS-HEAD --platform=win32 --comment=comment.html --timestamp="Sat, 17 Jul 2004 07:09:58 +0000" --user=agurtovoy To be most useful, a timestamp needs to be acquired right before *CVS checkout/update* is started (as opposite to when the test are finished). The script requires Python 2.3 and, for Windows platform, some version of Cygwin. The goal is to have a single page that reflects the status of the CVS across all platforms/compilers we currently test against. Moreover, a separation of test runs from report generation significantly lowers the regression's setup cost. Hopefully with other improvements in that area we will get more volunteers running the tests on a wider range of platforms. As usual, comments/suggestions/bug reports are most welcome. -- Aleksey Gurtovoy MetaCommunications Engineering

3 6

Boost Software License Progress?
by Stephan T. Lavavej 19 Jul '04

19 Jul '04

Hi Boosters, I've started working at Microsoft, and I would like to use Boost at work the way I do in my personal projects. But this isn't possible unless I can get big scary lawyers to bless it first, and /that/ isn't possible unless most or all of Boost is released under a single license. So, could someone summarize the status of the conversion to the Boost Software License? How far along will it be by the time 1.32.0 is released? I'm sure I'm not the only one this makes a difference to - I have a friend at Microsoft who also wants to use Boost. Can a page be put up on the Boost website summarizing the license state of every library in Boost? Then I could point the big scary lawyers at it. How actively are Boost developers being sought out to change their licenses over to the Boost Software License? From the attention I was paying to the list a few months ago, it seemed like the conversion wasn't being pursued very aggressively. I didn't care then, but I care now! It seems to me that the conversion is especially important for the libraries that have been incorporated into TR1. Stephan T. Lavavej

2 1

Re:ANN: Beta *overall* summary reports
by Robert Ramey 19 Jul '04

19 Jul '04

> A beta version of Boost-wide, multi-platform regression status reports > is available at http://boost.sourceforge.net/regression-logs/developer/. > Well, they are not truly multi-platform at the moment -- only one set > of results is shown, but they will become such as soon as somebody > uploads another set of logs. The details on this and other matters > follow. > As usual, comments/suggestions/bug reports are most welcome. When I click on the "fail" I don't get the links.html output as I did before. What are the plans (if any) for this? Robert Ramey

3 2

RE: [boost] This afternoon's test run
by Rozental, Gennadiy 19 Jul '04

19 Jul '04

> ../libs/test/test/ifstream_line_iterator_test.cpp(28): error in > "test_default_delimeter": test it != utf::ifstream_line_iterator() failed I do not understand something in Boost.Build system. This test should pass. Are you sure you did update -d ? Gennadiy.

1 0

graph/adjacency_matrix: iterator goes past end
by Guillaume Melquiond 19 Jul '04

19 Jul '04

Hi, Line 567 of adjacency_matrix.hpp is: typename Graph::MatrixIter l = g.m_matrix.end() + u; Obviously l is an iterator past the end. Looking at the algorithm, it seems to me it shouldn't be g.m_matrix.end() but f. So here comes a patch. Regards, Guillaume

2 7

Re:[boost] Threads Rewrite?
by Tonko Juricic 19 Jul '04

19 Jul '04

I just started using boost on Win32 platform and the lack of the ability to stop the thread is what immediately caught my attention. I understand it is difficult portability issue but I've seen too many uses where stop functionality is necessary. Looking at the current Win32 implementation, I'm afraid that adding thread stop would affect both mutextes and condition: as these call WaitOnSingleObject it seems impossible to stop the thread waiting on some 'external' mutex or condition. Off-hand, maybe TLS for each thread can have a default stop mutex and Win32 implementation of other synchronization primitives would always wait on at least two objects. It would also be nice to be able to start thread suspended, even if I guess it can be done now with mutex at the beginning of custom thread functor. Tony __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/

1 0

Seeking Boost round() function
by Matt Verona 19 Jul '04

19 Jul '04

I was reading the Boost documentation, and couldn't find a function to round floating point numbers (up or down) to the nearest integer. I have my own implementation of this algorithm as follows: #include <math.h> double round(double number) { return number < 0.0 ? ceil(number-0.5) : floor(number+0.5); } This round function produces the following output: round(0.0) = 0 round(1.49) = 1 round(1.5) = 2 round(-1.49) = -1 round(-1.5) = -2 Does Boost contain a simple rounding function like this? Thanks in advance, ~Matt Verona matt_verona(a)acm.org Houston, Texas USA

3 2

Boost.Threads static linking FYI
by Michael Glassford 19 Jul '04

19 Jul '04

I've made some changes to the Boost.Threads static linking support on Win32. Previously I had added back support for static linking, but without thread-specific storage classes. Now I've added the thread-specific storage classes back in, and exposed two functions that need to be called at the appropriate time: The function on_thread_exit() should be called when a thread exists, *in the context of the exiting thread*. The function on_process_exit() should be called when the process exit. If these functions are not called at the appropriate time, leaks may occur. If you know you don't need tss cleanup, of course you can just omit to call these functions. In addition, Boost.Threads static library on Win32 requires the user of the library to define a function called tss_cleanup_implemented(); if it is not defined, a link error results. The only purpose of this function is as a "link-time assertion": the linker error stating that the function is missing warns the the user of the necessity of calling the cleanup functions. In addition, if Boost.Threads later implements tss cleanup in the static library, the linker's duplicate symbol error should warn the user that their custom implementation is no longer needed. Comments? Mike

5 11

Re:[boost] [serialization] CW problems...
by Robert Ramey 19 Jul '04

19 Jul '04

>Rene Rivera wrote: >> Robert Ramey wrote: >> >>> While your looking at CW, might you find the time to look a little bit >>> into >>> the serialization library build problems. The error message is pretty >>> bizarre so I don't think it can be addressed without having CW >>> installed on >>> ones machine. >> >> OK, I'll try... Should I look for anything in specific? Or is it a >> general health issue? >I'm looking at this and one of the basic problems is that you seem to >assume a variety of things are available in the global namespace, >specifically size_t and other std types. Those are easy to fix by >specifying std::size_t. But I do have some questions... >1. Is using an unqualified size_t your intention? And therefore >something else is broken? Wow - its amazing to me I could have come so far and not know that size_t wasn't a built in type or macro - I think it used to be a macro definition. Anyway, I'll qualify this with std::size_t and check that no other compilers complain. If fact, now I can't understand why no other compiler complained since I never included <cstddef> >2. There is a similar problem with mbstate_t, but in this case you >attempt to do something special to handle it (from >boost/archive/codecvt_null.hpp): >#if BOOST_WORKAROUND(__BORLANDC__, <= 0x564) > #ifndef _RWSTD_NO_NAMESPACE > using std::codecvt; > using std::min; > #ifdef _RWSTD_NO_MBSTATE_T > using std::mbstate_t; > #endif > #endif >#elif defined(__COMO__) || defined(_MSC_VER) && _MSC_VER <= 1300 || >defined(__BORLANDC__) > typedef ::mbstate_t mbstate_t; >#elif defined(BOOST_NO_STDC_NAMESPACE) > typedef std::mbstate_t mbstate_t; > namespace std{ > using ::codecvt; > } // namespace std >#endif >And then you go ahead to use an unqualified mbstate_t. This just doesn't >work for CW. And I don't see how this would work for any library runtime >that puts mbstate_t only in the std namespace. Could you explain what >your intent is for this? The situation with mbstate_t is problematic. Some compilers define it in the global namespace while others define it in std::mbstate_t. The intent is to permit the code to use mbstate_t without qualification for those compilers that don't define it as std::mbstate_t. This sort of grew one compiler at time without too much thought. The typedef ::mbstate_t mbstate_t makes me wonder what I was thinking. Following the logic here for CW this would add #elif defined(CW) using std::mbstate_t; so that the rest of the code could use unqualified mbstate_t . I'll fix this (and a bunch other stuff) and we'll try again later. Thanks a lot. Robert Ramey

6 11

Bjam won't build thread static library VC .NET
by Tonko Juricic 19 Jul '04

19 Jul '04

First excuse me if this topic is not appropriate for boost developers list. This is my first post so I decided on asking a question rather than sending an empty message with test as a subject. I just built boost 1.31.0 libraries on Windows XP, using Visual Studio .NET 2003, compiler version 13.10.3077. To build both static libs and dlls I used this bjam command parameter -sBUILD=debug release <runtime-link>static/dynamic. Build worked just fine for all libs (for ex. I got both libboost_signals.lib and boost_signals.dll targets for signals) except for the thread library that created only boost_thread.dll target. What am I missing? Is there a reason that static threads library was not built and is there any way I can help? Tony __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/

3 2