May 2006 - Boost - lists.preview.boost.org

[1.34] Regression Failure io state saver
by Thomas Witt 25 May '06

25 May '06

Daryle, the io_state_saver test fail on all platforms on RC_1_34_0. This needs to be dealt with before we can release 1.34.0 Thanks Thomas -- Thomas Witt witt(a)acm.org

1 0

[Boost.Random]Comments/Questions
by Darren O'Driscoll 25 May '06

25 May '06

Hi all, I'm a relatively recent discoveror of these libraries, and for the last few weeks I've been like a kid in a toy shop as I've worked through them, and discovered the joys of the shared_ptr,bind,lambda,function libraries, etc. I've just arrived at the Boost.Random library, an area quite close to my heart as I make a lot of use of random deviate generators in my work in Financial Mathematics. I really like the set up and design of the libraries, but I have a few suggestions for additions which might be nice to have. Apologies in advance if these have already been discussed here, I haven't quite got the hang of searching through old posts in an efficient way. I hope noone's switched off during my long pre-amble, on to the meat of my post: 1. In general I've noticed that deviates for specific distributions are generated in one of two ways - a) according to a special algorithm, which usually involves generating one or more uniforms and doing some optimised transforms, or b) by generating a (0,1) uniform, and inverting the Cumulative distribution function. Method a), which seems to have been stuck to in Boost.Random is generally the more efficient of the two methods, but there are a number of cases where b) is necessary, specifically when using low-discrepancy sequences such as SOBOL as a base for the generation, of when using the stratified sampling technique in Monte Carlo. Would it be beyond the scope of this library to provide this kind of support? 2. Following on from the last point, it would be very useful if SOBOL sequence generation was included in the library. 3. I've noticed that at least one of the generators (Normal) uses a sub-optimal generator. I've attached an alternative implementation which I knocked together this evening which in my tests is about 30% faster. Note this was heavily influenced by an algorithm described in "Numerical Recipies in C". 4. The list of distributions where deviate generators are provided is quite short. As mentioned before, I'm quite interested in this area, and would be happy to help with algorithms for some other distributions, though sadly I would estimate that my C++ skills are still quite a lot below the median here. All comments welcome, Cheers Darren

2 1

New Boost RPM spec file
by Patrick Hartling 25 May '06

25 May '06

In my company's use of Boost, we have found that the Boost RPM installed with Linux distributions such as Fedora Core and Red Hat Enterprise Linux does not quite meet our needs. This happens because that RPM does not install the multi-threaded versions of the libraries, nor does it preserve the version information on the installed libraries. I have attached an RPM spec file that addresses these issues and that allows targeting 32-bit Linux from an x86_64 installation (though it has to exclude Boost.Python and Boost.iostreams). Personally, I would like to see Boost RPMs built that follow the existing Boost conventions more closely, but that may not be a popular view. If nothing else, I thought that posting this file would be helpful to people who have run into the same issues that we have seen. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/ %define tarball_name boost_1_33_1 %define python_arch %(python -c 'import os; print os.uname()[4]') %if %{python_arch} == %{_arch} %define build_python 1 %else %define build_python 0 %endif Name: boost Summary: The Boost C++ Libraries Version: 1.33.1 Release: 1 License: Boost Software License URL: http://www.boost.org/ Group: System Environment/Libraries Source: %{tarball_name}.tar.bz2 BuildRoot: %{_tmppath}/boost-%{version}-root Prereq: /sbin/ldconfig BuildRequires: libstdc++-devel python Obsoletes: boost <= 1.33.0 Obsoletes: boost-devel <= 1.33.0 Obsoletes: boost-doc <= 1.33.0 %if %{build_python} Obsoletes: boost-python <= 1.33.0 %endif %description Boost provides free peer-reviewed portable C++ source libraries. The emphasis is on libraries which work well with the C++ Standard Library. One goal is to establish "existing practice" and provide reference implementations so that the Boost libraries are suitable for eventual standardization. (Some of the libraries have already been proposed for inclusion in the C++ Standards Committee's upcoming C++ Standard Library Technical Report.) %package devel Summary: The Boost C++ Headers Group: System Environment/Libraries Requires: boost = %{version}-%{release} %if %{build_python} Obsoletes: boost-python-devel <= 1.33.0 Provides: boost-python-devel = %{version}-%{release} %endif %description devel Headers for the Boost C++ libraries %package doc Summary: The Boost C++ html docs Group: System Environment/Libraries Requires: boost = %{version}-%{release} %if %{build_python} Provides: boost-python-docs = %{version}-%{release} %endif %description doc HTML documentation files for Boost C++ libraries %prep rm -rf $RPM_BUILD_ROOT %setup -n %{tarball_name} -q %ifarch i386 i486 i586 i686 %define arch_args <cflags>-m32 <cxxflags>-m32 <linkflags>-m32 <linkflags>-L/usr/lib %else %ifarch x86_64 %define arch_args <cflags>-m64 <cxxflags>-m64 <linkflags>-m64 <linkflags>-L/usr/lib64 %endif %endif %build without_libs='' %if %{build_python} == 0 without_libs="$without_libs --without-python" %endif # This is a hack. A better way needs to be devised for determining when # the local architecture does not match the target architecture. %if %{python_arch} != %{_arch} without_libs="$without_libs --without-iostreams" %endif #build bjam (cd tools/build/jam_src && ./build.sh) #build boost with bjam BJAM=`find tools/build/jam_src/ -name bjam -a -type f` PYTHON_VERSION=`python -V 2>&1 |sed 's,.* $[0-9]\.[0-9]$$\.[0-9]$\?.*,\1,'` PYTHON_FLAGS="-sPYTHON_ROOT=/usr -sPYTHON_VERSION=$PYTHON_VERSION" $BJAM $PYTHON_FLAGS "-sTOOLS=gcc" "-sBUILD=release <threading>single/multi %{arch_args}" "--prefix=$RPM_BUILD_ROOT%{_prefix}" $without_libs stage %install mkdir -p $RPM_BUILD_ROOT%{_libdir} mkdir -p $RPM_BUILD_ROOT%{_includedir} mkdir -p $RPM_BUILD_ROOT%{_docdir} mkdir -p $RPM_BUILD_ROOT%{_docdir}/boost-%{version} tar -C stage/lib -cvf - . | tar -C $RPM_BUILD_ROOT%{_libdir} -xpf - # install include files for i in `find boost -type d`; do mkdir -p $RPM_BUILD_ROOT%{_includedir}/$i done for i in `find boost -type f`; do install -m 644 $i $RPM_BUILD_ROOT%{_includedir}/$i done #install doc files cd doc/html; for i in `find . -type d`; do mkdir -p $RPM_BUILD_ROOT%{_docdir}/boost-%{version}/$i done for i in `find . -type f`; do install -m 644 $i $RPM_BUILD_ROOT%{_docdir}/boost-%{version}/$i done cd ../..; %clean rm -rf $RPM_BUILD_ROOT %post /sbin/ldconfig %postun /sbin/ldconfig %files %defattr(-, root, root) %{_libdir}/*.so.%{version} %files devel %defattr(-, root, root) %{_includedir}/boost %{_libdir}/*.a %{_libdir}/*.so %files doc %defattr(-, root, root) %{_docdir}/boost-%{version} %changelog * Apr 14 2006 Patrick Hartling <patrick(a)infiscape.com> 1.33.1-1 - Update to 1.33.1 - Install single- and multi-threaded libraries - Install fully versioned libraries - Allow 32-bit build to be made on 64-bit architecture (currently without Boost.Python or Boost.iostreams) * Mon Nov 29 2004 Benjamin Kosnik <bkoz(a)redhat.com> 1.32.0-1 - Update to 1.32.0 - (#122817: libboost_*.so symlinks missing) * Wed Sep 22 2004 Than Ngo <than(a)redhat.com> 1.31.0-9 - cleanup specfile - fix multiarch problem * Tue Jun 15 2004 Elliot Lee <sopwith(a)redhat.com> - rebuilt * Wed May 05 2004 Warren Togami <wtogami(a)redhat.com> 1.31.0-7 - missing Obsoletes boost-python * Mon May 03 2004 Benjamin Kosnik <bkoz(a)redhat.com> - (#121630: gcc34 patch needed) * Wed Apr 21 2004 Warren Togami <wtogami(a)redhat.com> - #121415 FC2 BLOCKER: Obsoletes boost-python-devel, boost-doc - other cleanups * Tue Mar 30 2004 Benjamin Kosnik <bkoz(a)redhat.com> - Remove bjam dependency. (via Graydon). - Fix installed library names. - Fix SONAMEs in shared libraries. - Fix installed header location. - Fix installed permissions. * Fri Feb 13 2004 Elliot Lee <sopwith(a)redhat.com> - rebuilt * Mon Feb 09 2004 Benjamin Kosnik <bkoz(a)redhat.com> 1.31.0-2 - Update to boost-1.31.0 * Thu Jan 22 2004 Benjamin Kosnik <bkoz(a)redhat.com> 1.31.0-1 - Update to boost-1.31.0.rc2 - (#109307: Compile Failure with boost libraries) - (#104831: Compile errors in apps using Boost.Python...) - Unify into boost, boost-devel rpms. - Simplify installation using bjam and prefix install. * Tue Sep 09 2003 Nalin Dahyabhai <nalin(a)redhat.com> 1.30.2-2 - require boost-devel instead of devel in subpackages which require boost-devel - remove stray Prefix: tag * Mon Sep 08 2003 Benjamin Kosnik <bkoz(a)redhat.com> 1.30.2-1 - change license to Freely distributable - verify installation of libboost_thread - more boost-devel removals - deal with lack of _REENTRANT on ia64/s390 - (#99458) rpm -e fixed via explict dir additions - (#103293) update to 1.30.2 * Wed Jun 04 2003 Elliot Lee <sopwith(a)redhat.com> - rebuilt * Tue May 13 2003 Florian La Roche <Florian.LaRoche(a)redhat.de> - remove packager, change to new Group: * Tue May 06 2003 Tim Powers <timp(a)redhat.com> 1.30.0-3 - add deffattr's so we don't have unknown users owning files

8 13

Proposal for radically altered approach to releases
by Beman Dawes 25 May '06

25 May '06

The current approach to getting releases ready is completely broken in my opinion. Each release requires heroic efforts by the release manager, careful attention by many developers, and endless delays until everything is just right. This is discouraging to developers and, worse yet, important library upgrades and bug fixes are taking far too long to get into user's hands. The problems with the current release approach are not caused by release managers or developers, but rather by the release system itself. It just doesn't scale up to the number of libraries now in Boost, since every library has to be ready before a release can occur. These problems will only grow worse as more libraries are added. I propose changing to a different release model, one based on always maintaining a release-ready stable branch and merging updates for individual libraries into it asynchronously. A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html. I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly. What do others think? --Beman

19 55

[vc6] LNK1179 Workaround Found
by David Abrahams 24 May '06

24 May '06

http://tinyurl.com/moxw8 (http://groups.google.com/group/microsoft.public.vc.language/ browse_frm/thread/811cc53a3d36d276/44768de68d91a640) describes a long list of vc6 bugs along with workarounds, but the workaround for this message's title bug is not transparent: the static member of the function will not necessarily be constructed during the program's dynamic initialization. This problem has reared it's ugly head many times for the serialization library, but I've just found a fix: http://tinyurl.com/ljdp8 (http://groups.google.com/group/microsoft.public.vc.language/ browse_frm/thread/90354d2e722c7d99/d42bff533ccdf364) Just to make sure this information doesn't get lost, I'm also posting a copy of the workaround as applied to the OP's example here. Enjoy, (if you run into this problem). -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[serialization] vc6 and Header Ordering
by David Abrahams 24 May '06

24 May '06

Hi Robert, The header ordering issue is solved... except on vc6. Unfortunately the technique depends on instantiating static members of templates with more than two dependent types, which leads ultimately to the same problem described here: http://www.boost.org/libs/serialization/doc/implementation.html#vc6. I've made lots of clever attempts at workarounds, but this compiler bug is etremely stubborn. If you're interested in a fix for the issue that doesn't work on vc6, or if you're ready to drop support for vc6, then I'll proceed. Otherwise, please let me know and I'll check my work in on a branch for posterity. Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 4

Re: [boost] [spirit] Ternary Search Tree (TST) revisited
by rasmus ekman 24 May '06

24 May '06

Joel de Guzman wrote: > > As many of you might not know, there's a nice TST(*) > implementation in the Spirit CVS written by Steve Rowe > I would want to use it as the basis for Spirit-2's symbol > table. The objective is to optimize the code and do some > benchmarks with it. You may want to look at http://www.abc.se/~re/code/tst It's not finished, but may be usable in present state. The unfinished interface bit is: defining subkey iterators, and rewrite the imprecise matching algorithms as nonmember functions. I define the TST containers as Associative Sorted with internal structure in the keys - the keys are Forward Containers. (hence the name Structured Containers, but this may be an overstatement, suggestions welcome) So iterators should perhaps use a variant of segmented iterators - though not for performance purposes. I haven't found time to finish it (I just use it as is), but with some suggestions for interface and implementation I could perhaps get going again. The implementation is needlessly messy in spots, as I tried to do without Boost.Iterator and MPL. > (*) > Ternary Search Tree implementation. The data structure is faster than > hashing for many typical search problems especially when the search > interface is iterator based. Searching for a string of length k in a > ternary search tree with n strings will require at most O(log n+k) > character comparisons. TSTs are many times faster than hash tables > for unsuccessful searches I have not found this to be generally true, at least not the "many times faster" claim, at least not for the implementations I've seen. "About as fast as hashed containers" is a more reasonable statement. Please see http://www.abc.se/~re/code/tst/tst_docs/tst_perf.html re

3 2

Google Summer of Code -- 10 Projects Assigned!
by Jeff Garland 24 May '06

24 May '06

Hi All - Just a quick note to let everyone know that Boost has been assigned 10 SOC projects! This is more than we expected and I'm hopeful will result in some great work. Even so, there are many excellent students and projects that applied for Boost projects and were NOT selected. The competition for these 10 slots was quite brutal. The choices were extremely difficult to make. It was often very hard to decide between a totally novel, high risk, project proposal and a fairly straight-forward extension to a current library. As you'll see, we ended up with some of both. The mentors have been trying to reach everyone with a notification one way or another, but it's a large list. All applicants should have heard from Google by now. If you have questions you can post to boost_soc2006(a)crystalclearsoftware.com and someone should get back to you. I'm not going to publicy share the details of the list just yet -- until we are sure all the administrative items are confirmed (google apparently accidently informed 1800 people they were accepted and then had to retract). Eventually the list should show up here: http://code.google.com/soc/boost/about.html Jeff

2 1

[range] atl/mfc support
by Shunsuke Sogame 24 May '06

24 May '06

Hi, I wrote an "interest" version of Boost.Range support for ATL/MFC: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… or http://tinyurl.com/evddv There are *40* ranges. The test is problematic... It is possible to fail to complete. :-( They are roughly tested under: VC7.1 + ATL7 + MFC7 VC8 + ATL3 and Boost.Range at cvs BTW, I found a bug: <boost/range/concepts.hpp> seems to apply 'boost::size' to Forward Range. Thanks! -- Shunsuke Sogame

3 10

[SoC][misc] Project Accepted!
by Matias Capeletto 24 May '06

24 May '06

Boost.Misc, (M)ulti (I)ndex (S)pecialized (C)ontainers, is in SoC 2006! I want to thank boost mentors for trust in me, I will work very hard! Good luck to the other applicants! (accepted and rejected ones) I have set up some online resource to start my project. MC++ Blog [ matiascpp.blogspot.com ] ---------------------------------------------------------------------- This is my blog, and I will use it to post no so technical information about the project. Online Docs [ h1.ripway.com/mcape/boost/libs/misc ] ---------------------------------------------------------------------- The original proposal docs will be filled with new stuff during the project. The idea is that in the end it will be the user manual, a SoC project related information repository and library history reference. Discussion Group [ groups.google.com/group/boostMiscSoC ] ----------------------------------------------------------------------- In order to avoid polluting the boost developer list, I have created a group where to discuss technical details about the project. Please join the group if you are interested in the project, I will really appreciate your comments. When a thread is interesting enough I will post it here for a deeper and broader discussion. I have already post my mentor ( Joaquin Lopez Muñoz) questions and my responses to start discussing. boost rocks! Best Regards Matias Capeletto

1 0