May 2009 - Boost - lists.boost.org

profile-templates
by Stefan Seefeld 30 May '09

30 May '09

Hello, I'v just learned about your template instantiation profiler tool, and I'm very intrigued ! What is the best way to download and build it ? I tried to check out sandbox/tools/profile_templates, but it seems that is not meant to be used stand-alone. Do I really need to check out the entirety of the sandbox (which is huge !) ? Or are there better ways to do it ? (How does that question fit into the current modularization discussion ? :-) ) Many thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 2

[parameter] Preventing instantiation of lazy binding operator() until default is needed
by Jeremiah Willcock 30 May '09

30 May '09

This is a subset of my previous email, with a more specific and concrete example. The following code: #include <boost/parameter/name.hpp> #include <boost/parameter/binding.hpp> BOOST_PARAMETER_NAME(my_param) template <typename T> struct s {}; template <typename T> struct bogus { typedef typename s<T>::type result_type; template <typename U> struct result: public s<U> {}; result_type operator()() const {return 0;} }; template <typename ArgPack> void f(const ArgPack& ap) { const char* cs = ap[_my_param || bogus<const char*>()]; } int main(int, char**) { f(_my_param = "foo"); return 0; } does not work because result_type is invalid when the struct bogus is instantiated when creating the default value used in operator||(). If operator()() was a template, I think the compiler would delay instantiating it until it was called. Is there a way to force operator()() to be a template in Boost.Parameter, allowing its return type to only be instantiated when Boost.Parameter knows that the default will be used? This is a simplified example from a larger piece of code where the lazy default does not have a valid return type in some cases, and the parameter must be explicitly specified in those cases. Thank you. -- Jeremiah Willcock

2 2

[random] fixing uniform_int bias
by Steven Watanabe 29 May '09

29 May '09

AMDG Given that we periodically get complaints about the non-uniformity of uniform_int, I'm going to commit that attached patch if no one objects. I had to modify one of the test cases, because it causes the modified uniform_int to loop forever. I believe that this is acceptable, because the test is giving uniform_int a generator that always returns the same value. The rejection method used currently will also loop under certain similar circumstances. The patch also fixes an operator precedence error. However, looking more closely, there appears to be another bug in that branch, which can cause a loop. Aaaaaargh. I'll probably get a complete patch sometime tomorrow, but in the meantime I'd appreciate having another pair of eyes looking at the fix I have. In Christ, Steven Watanabe

1 3

[inspect][filesystem] libs/filesystem/test/ticket_2260_test.cpp
by Jeremiah Willcock 29 May '09

29 May '09

The file libs/filesystem/test/ticket_2260_test.cpp appears in the Boost trunk inspection report at http://boost.cowic.de/rc/inspect-trunk.html but does not appear in SVN. Is that an old file in the directory where the inspections are taking place? -- Jeremiah Willcock

2 1

[1.39.0] Ready for beta?
by Beman Dawes 29 May '09

29 May '09

I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible. Are there any known showstoppers? If anyone has a few spare minutes, it would help if they could download one of the current release snapshots from http://boost.cowic.de/rc/, browse around and report any problems spotted. Library authors who use Boostbook/Quickbook, but don't have time to look at the full snapshot, might want to check http://boost.cowic.de/rc/boost-docs.7z Known problems/questions: * index.html ??? needs to be replaced by new library count. * pdf docs: Do we want to do anything more for this release? Thanks, --Beman

13 29

[Graph] how to test/submit patch
by Tim Keitt 29 May '09

29 May '09

I would like to submit a patch for the Graph library. (This is the iterator splitting issue I raised some time ago.) So what is the procedure? 1) check out source from sourceforge SVN (done) 2) make changes 3) run tests??? (what is the best way to ensure the behavior has not changed?) 4) generate the patch (use svn diff?) 5) submit somewhere I just want to be sure I'm pulling the correct tree and there is some means to run regressions on my changes. Thanks. THK -- Timothy H. Keitt Associate Professor Section of Integrative Biology University of Texas at Austin http://www.keittlab.org/

3 2

[graph] Request for help with BGL bugs (Bug Sprint)
by Jeremiah Willcock 29 May '09

29 May '09

For those participating in the Boost Bug Sprint, I would appreciate help with the following items to help resolve BGL bugs: 1. Someone who has a copy of LEDA (or is willing to download one) can work on tickets 373, 375, and 1326. Ticket 1326 has an old patch that does not apply cleanly to the current version of BGL in Boost. I would also appreciate knowing which of these issues still exist in current versions of Boost. 2. I would appreciate someone looking at bug 735 and bringing its patch up to date. If there is a way to get a copy of the patch for bug 900 (requested on the Boost list), bringing that up to date would be good as well. 3. Someone should test the patch in bug 1021 and see if it breaks anything else in BGL (and fixes the relevant bug). Also, the copy of reverse_graph in there should be turned into a patch and tested to ensure that it does not undo other changes to BGL since it was created. Any help with these issues would be greatly appreciated. -- Jeremiah Willcock

1 0

request for interest in a garbage collection library
by Achilleas Margaritis 29 May '09

29 May '09

Hi, I have placed in boost vault a garbage collection library: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=gc.zip… The major features of this library are: 1) it supports threads; a thread can allocate gc objects and send them to other threads. 2) it is 100% portable c++; only boost and stl are used. 3) gc pointers can point to middle of objects and arrays. 4) block allocation and finalization are customizable. The collector does not do any allocation actually, it only manages blocks. 5) the collector uses the classic mark & sweep algorithm. 6) it has good (or not that bad :-)) performance. On my test machine (a dual core Pentium at 2.5 GHz with 2 GB ram), 50000 objects out of 100000 are swept in 63 milliseconds. Of course, this is due to boost::pool :-). 7) it works with STL containers (the 'how' is described in the readme). The zip file contains a set of unit tests, the API documentation and a readme file which explains the inner workings and the design of the collector. I would appreciate it if people could take a look and share their opinions on it. Best regards Achilleas Margaritis

22 64

[gsoc] Official list released
by troy d. straszheim 29 May '09

29 May '09

On behalf of the panel of mentors, congratulations to the students listed here: http://socghop.appspot.com/org/home/google/gsoc2009/boost And a sincere thank you to all those who applied. There are a large number of entirely worthy proposals that we received that are not on that list. We had about 75 proposals, 11 willing mentors, and as you can see, Google gave us seven slots. It was very difficult to narrow down the list to these seven, and if we'd been given more slots, of course more of you would be on that list. Unfortunately, due to the sheer number of submissions and various, ahem, technical problems, it would not have been (and will not now be) possible to offer specific feedback on submissions that didn't make the cut. For this we apologize. Accepted students should eventually receive email from Google with further instructions. Per the schedule, the "community bonding" period now begins, time to get your dev. environment set up, get to know the toolchain, write some 'hello world' quickbook docs, etc. Ask for help if you need it. You can also visit some of your fellow summer coders on #boost-soc on freenode. -t

5 4

The Boost Bug Sprint is here!
by Marshall Clow 29 May '09

29 May '09

The boost bug sprint starts today Friday, May 29th, and runs through Sunday June 7th. Status 5/29: 812 open tickets. The goal is to address a large number of open bugs/patches/feature requests in the Trac system at <http://svn.boost.org/trac/report/1>. There are currently 812 open tickets; we'd like to knock that number down _a lot_. What can you do? 1) You can fix bugs. * If you are a library maintainer, you can commit your fixes. ;-) * If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. 2) You can characterize bugs. * You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. * You can write test cases demonstrating the problem, and attach them to the Trac ticket. * You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." 3) You can test patches. * Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." * You can write test cases for the patches, and attach them to the ticket. 4) You can help implement new features. * There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). Every day during the bug sprint, I'll post the # of tickets modified/closed/opened on the previous day, as well as the total number of open tickets. If you aren't sure where to start, you can verify existing patches. Here are a list of patches that have been open at least six months. [ Note: The URL for ticket number XXXX is https://svn.boost.org/trac/boost/ticket/XXXX ] Bug # Library Description 2603 smart_ptr patch for owner_before and owner_less support with shared_ptr/weak_ptr 2581 mpi MPI tutorial sample has missing includes 2509 string_algo case conversion (to_upper) fails in Codegear C++Builder 5.9.3 2484 bimap Const-overload needed for bimap associative_container_adaptor::count() 2482 concept_check msvc-9.0 unreferenced formal parameter warning when using boost::breadth_first_visit 2454 fusion Fusion - MSVC level 1 warnings 2452 fusion Fusion vector warning 4512 supression would be nice, 2390 test "[patch] fix gcc-4.3 ""unused"" warning in floating_point_comparison" 2370 lexical_cast [lexical_cast] Patch to reduce warnings for CodeGear (Borland) 2351 spirit Minor BOOST_SPIRIT_RULE fixes (rule_parser.hpp) 2312 smart_ptr intrusive_ptr::operator= should have by-value argument 2304 spirit Patch to fix warnings in spirit 2297 mpl Workaround for GCC bug 2290 serialization Patch for GCC-4.0.1 compatibility (and better compile time). 2271 serialization Cannot load version 1.35.0 xml archives that contain vectors of primitive types 2208 Python Pyste can use ElementTree from Python 2.5 2149 date_time Updated Daylight Savings Time for Australia/Perth 2142 Python Patch for boost.python - return_pointee_value, 2114 none Patch for export symbols from shared library 2064 tokenizer Interval notation is wrong in tokenizer documentation 2053 threads porting boost to avr32 linux platform 1947 iterator traversal access decoupling 1861 date_time time_duration type can not be correctly written or read of the period spans 24 hours of more (vc9 and probably others). 1850 thread request for unlock_guard (and/or unique_unlock) to compliment lock_guard/unique_lock 1811 Building Boost Help packaging by supporting DESTDIR 1791 lexical_cast fix warning on MSVC warning level 4 1702 random serialization for Mersenne twister 1681 filesystem patch for NTFS symbolic links 1541 parameter [parameter] Patch for missing includes 1535 function [result_of] remove unneeded headers 1534 build Add support for winsdk 6.1.6000 to Boost.Build.v2 1533 iterator boost/function.hpp unneeded in transform_iterator.hpp 1529 fusion Missing include statement 1521 bimap Missing #include statements 1519 iterator lvalue-ness resurrection in transform_iterator 1437 random "normal_distribution.hpp, improvements to distribution and possibly speed" 1418 serialization polymorphic archive performance improvement 1377 GIL Add ability to save RGBA image as TIFF with associated-alpha (premultiplied) transparency channel. 1341 asio unused argument and another g++ warning 1338 numeric g++ warnings and incomplete header inclusions 1271 Python unused parameter warning in release build 1116 build disable some warnings in msvc build 1066 Python Patch to make Boost.Python compile on SunCC 1049 mpl Getting mpl/has_xxx.hpp to compile on AIX 1020 iterator Boost.Iterator proposal to add is_constant_iterator 903 Python inconsistent usage of function pointer typedefs 868 thread [thread] thread_specific_ptr::element_type ? 864 lambda [lambda][utility] Make lambda support result<> 863 [parameter] fix operator|| for lazy binding 861 parameter Detect nested template members with has_template_xxx,mpl 857 Python add shared_ptr< const T> support 827 date_time Unused variable in format date parser, 802 thread [thread] MSVS: Allow use of thread headers with /Za 761 mpl [mpl] evc4 port 717 Python Add operator for __repr__ similar to __str__ 637 mpl Adjusts mpl::pair concept to be compatible with STL pairs --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 2