October 2013 - Boost - lists.boost.org

[math] Contribution and TODO-list implementation.
by Bikineev 06 Nov '13

06 Nov '13

Hello. I'm russian student. My department is Applied Math. I need to make my magister work and I would like to relate it with Boost.Math development. I think this work could be something like implementation of tasks mentioned in TODO-list. New feature development may take a long time. In the best case, I would be glad to take job and reviewer for it. If anyone has an idea - I'm ready to take serious and big job for 1,5 years. Thanks.

5 11

[unordered] Visual C++ 2013 initializer_list overload failure.
by Daniel James 05 Nov '13

05 Nov '13

Hi, I'm getting some test failures for inserting an initializer_list into the unordered containers: http://www.boost.org/development/tests/trunk/developer/output/teeks99-10-wi… I don't have access to Visual C++ 12 to investigate this. This is just a guess, but I think the problem is converting an initializer_list of string literals to an initializer list of std::string. This works okay with clang and g++ so I assume it's allowed. A minimal test might be something like the following (although it might not). #include <initializer_list> #include <string> template <typename T> struct thing { void insert(T const&) {} void insert(T&&) {} void insert(std::initializer_list<T>) {} }; int main() { thing<std::string> x; x.insert("a"); x.insert({"a"}); x.insert({"a", "b"}); }

5 13

[tweener] Doxygen documentation issues
by Julien Jorge 05 Nov '13

05 Nov '13

Hi, I am writing the documentation of Boost.Tweener and I encounter various difficulties. One of them is the generation of the class documentation with doxygen. It seems that it cannot extract the class and member documentation from .ipp files. I like to document the methods of my classes near the implementation. In Boost.Tweener, most of the class documentation is then in the .ipp files and I have written the following lines in the Jamfile.v2: import quickbook ; using boostbook ; using doxygen ; doxygen reference : [ glob ../../../boost/tweener/*.hpp ] [ glob ../../../boost/tweener/detail/*.hpp ] [ glob ../../../boost/tweener/detail/impl/*.ipp ] [ glob ../../../boost/tweener/detail/impl/easing/*.ipp ] [ glob ../../../boost/tweener/easing/*.hpp ] But when I try to build the documentation, I have the following error: boost_1_52_0/tools/build/v2/build/generators.jam:1085: in ensure-type from module generators error: target { ../../../boost/tweener/detail/impl/tweener_group.ipp. } has no type Moreover, if I remove the ipp files, the generation of the documentation does not fail but the doxygen documentation is not extracted, except for the private members. So, how can I also disable the extraction of the private members in the documentation? You can check the Jamfile.v2 in the git repository of the project: http://libclaw.git.sourceforge.net/git/gitweb.cgi?p=libclaw/boost-tweener;a… Regards, Julien

4 6

[modularization] Modularizing Boost (modularization)
by Stephen Kelly 05 Nov '13

05 Nov '13

Hi there, my plan for modularizing and modernizing Boost was roughly this: * Phase 0 - remove dead weight by bumping compiler feature requirements * Phase 1 - move some files around so that the modularized repos form a mostly directed graph * Phase 2 - Form some kind of 'boost core library' or 'boost feature normalization library' from the guts of existing libraries like type_traits, static_assert, config mpl and utilities. * Phase 3 - Try to port the mpl to variadic templates so that the dependency on Boost.PP is not needed when variadic templates are available. I recommend completing up to phase 2 before migrating to git, as otherwise files will have to be deleted from one repo, and added to another without history. Phase 0 is aborted, so let's look at phase 1. [Note: This should go without saying, but my experience on this list tells me it needs to be said: * I do not propose making many commits with the commit message 'migrate' * The below is scripted for your understanding only. Scripting gives an exactness which prose does not, and allows reproducibility. Don't take it too literally. * Of course, forwarding headers should be understood to be left behind when a file is moved, where possible. * Don't cry too loudly about where I'm moving files to. See Phase 2 above, and understand that this is partly only an experiment to see how modularization can be done. EndNote] If the dependencies between repositories are analysed, the result is this graph: http://steveire.com/boost/graph_all.dot http://steveire.com/boost/graph_all_small.png There are 104 nodes and 1159 edges. Each edge is a real dependency which exists between repos, and which will exist between boost modularized packages. They should not be considered optional. If we remove any nodes which are not strongly connected, we are left with a new graph of nodes which are all strongly connected: http://steveire.com/boost/graph_strong.dot http://steveire.com/boost/graph_strong_small.png There are 68 nodes and 675 edges. Move enable_if from utility to type_traits: git submodule foreach 'git grep -l -P utility/enable_if.hpp -- include/boost | xargs sed -i "s|utility/enable_if.hpp|type_traits/enable_if.hpp|" || echo' mv libs/utility/include/boost/utility/enable_if.hpp libs/type_traits/include/boost/type_traits git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 670 edges and 68 nodes. Next, move boost/detail/workaround.hpp to the config library/repo: git submodule foreach 'git grep -l -P boost/detail/workaround.hpp -- include/boost | xargs sed -i "s|boost/detail/workaround.hpp|boost/config/workaround.hpp|" || echo' mv libs/detail/include/boost/detail/workaround.hpp libs/config/include/boost/config/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 661 edges and 68 nodes. Next, move boost/limits.hpp to the config library/repo: git submodule foreach 'git grep -l -P boost/limits.hpp -- include/boost | xargs sed -i "s|boost/limits.hpp|boost/config/limits.hpp|" || echo' mv libs/detail/include/boost/limits.hpp libs/config/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 653 edges and 68 nodes. Next, move boost/detail/iterator.hpp and boost/iterator/iterator_traits.hpp to the type_traits library/repo: git submodule foreach 'git grep -l -P boost/detail/iterator.hpp -- include/boost | xargs sed -i "s|boost/detail/iterator.hpp|boost/type_traits/detail/iterator.hpp|" || echo' git submodule foreach 'git grep -l -P boost/iterator/iterator_traits.hpp -- include/boost | xargs sed -i "s|boost/iterator/iterator_traits.hpp|boost/type_traits/iterator_traits.hpp|" || echo' mv libs/detail/include/boost/detail/iterator.hpp libs/type_traits/include/boost/type_traits/detail/ mv libs/iterator/include/boost/iterator/iterator_traits.hpp libs/type_traits/include/boost/type_traits git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 650 edges and 68 nodes. Next, move boost/iterator.hpp from iterator to the utility library/repo: mv libs/iterator/include/boost/iterator.hpp libs/utility/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 649 edges and 68 nodes. utility no longer depends on iterator. Move boost/version.hpp to config: mv libs/detail/include/boost/version.hpp libs/config/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 512 edges and 64 nodes. The config, integer, io and static_assert libraries are no longer part of the mesh Next, move boost/pointee.hpp from iterator to detail: mv ./libs/iterator/include/boost/pointee.hpp libs/detail/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' Move exception/detail/attribute_noreturn.hpp into config: git submodule foreach 'git grep -l -P boost/exception/detail/attribute_noreturn.hpp -- include/boost | xargs sed -i "s|boost/exception/detail/attribute_noreturn.hpp|boost/config/attribute_noreturn.hpp|" || echo' mv libs/exception/include/boost/exception/detail/attribute_noreturn.hpp libs/config/include/boost/config/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' Move boost/throw_exception.hpp and exception.hpp into utility: mv libs/exception/include/boost/throw_exception.hpp libs/utility/include/boost mv libs/exception/include/boost/exception/exception.hpp libs/utility/include/boost/utility git submodule foreach 'git grep -l -P boost/exception/exception.hpp -- include/boost | xargs sed -i "s|boost/exception/exception.hpp|boost/utility/exception.hpp|" || echo' git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 485 edges and 64 nodes. Several libraries form an inner mesh: $ grep -P "^\s*(type_traits|mpl|detail|utility|smart_ptr|typeof)" output.dot detail->mpl detail->type_traits detail->smart_ptr detail->utility utility->mpl utility->type_traits utility->detail type_traits->detail type_traits->mpl type_traits->typeof type_traits->utility smart_ptr->type_traits smart_ptr->detail smart_ptr->utility mpl->type_traits mpl->detail mpl->utility typeof->mpl typeof->type_traits If we treat them as one element for now, we get a new graph from the rest http://steveire.com/boost/graph_with_corelib.dot http://steveire.com/boost/graph_with_corelib.png There are now 138 edges and 39 nodes Move parts of {vector_,}property_map into graph_parallel: sed '1,/BOOST_GRAPH_USE_MPI/d;/BOOST_GRAPH_USE_MPI/,$d' libs/property_map/include/boost/property_map/property_map.hpp > tmp.hpp sed -i '/BOOST_GRAPH_USE_MPI/,/BOOST_GRAPH_USE_MPI/d' libs/property_map/include/boost/property_map/property_map.hpp sed '1,/BOOST_GRAPH_USE_MPI/d;/BOOST_GRAPH_USE_MPI/,$d' libs/property_map/include/boost/property_map/vector_property_map.hpp >> tmp.hpp sed -i '/BOOST_GRAPH_USE_MPI/,/BOOST_GRAPH_USE_MPI/d' libs/property_map/include/boost/property_map/vector_property_map.hpp sed -i '/#undef PBGL_DISTRIB_PMAP/r tmp.hpp' libs/property_map/include/boost/property_map/parallel/distributed_property_map.hpp rm tmp.hpp git submodule foreach 'git grep -l -P boost/property_map/parallel/distributed_property_map.hpp -- include/boost | xargs sed -i "s|boost/property_map/parallel/distributed_property_map.hpp|boost/graph/parallel/distributed_property_map.hpp|" || echo' git submodule foreach 'git grep -l -P boost/property_map/parallel/impl/distributed_property_map.ipp -- include/boost | xargs sed -i "s|boost/property_map/parallel/impl/distributed_property_map.hpp|boost/graph/parallel/detail/distributed_property_map.hpp|" || echo' mv libs/property_map/include/boost/property_map/parallel/distributed_property_map.hpp libs/graph_parallel/include/boost/graph/parallel mv libs/property_map/include/boost/property_map/parallel/impl/distributed_property_map.ipp libs/graph_parallel/include/boost/graph/parallel/detail git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' http://steveire.com/boost/graph_after_parallel.dot http://steveire.com/boost/graph_after_parallel.png There are now 95 edges and 33 nodes The remaining problematic edges are: conversion->range conversion->math range->algorithm math->multiprecision concept_check->parameter Assuming they can be broken by moving some files aroung (I believe they can be), we end up with a small graph of strongly connected components: http://steveire.com/boost/graph_after_remaining.dot http://steveire.com/boost/graph_after_remaining.png There are now 18 edges and 11 nodes. Looking at the entire graph again, we get this: http://steveire.com/boost/graph_final.dot http://steveire.com/boost/graph_final_small.png Obviously, this is not perfect, but it is a beginning, and it is mostly now a directed graph. Any comments? Thanks, Steve.

29 162

[config] clang deleted functions bugged
by Vicente J. Botet Escriba 04 Nov '13

04 Nov '13

Hi, Clang has a bug with deleted functions (see http://stackoverflow.com/questions/7754564/clang-error-message-when-using-c…) Please, could we comment these two lines until clang fixes the bug //#if !__has_feature(cxx_deleted_functions) # define BOOST_NO_CXX11_DELETED_FUNCTIONS //#endif Thanks, Vicente

3 8

[git] open an "admin" link doesn't works
by Vicente J. Botet Escriba 01 Nov '13

01 Nov '13

Hi, I tried to gain write access to a particular Boost library but the link *open an "admin"* issue <https://github.com/boostorg/admin/issues> in https://svn.boost.org/trac/boost/wiki/ModAdmin . doesn't works for me. Could someone help me? Vicente

8 10

[git help] Cloning the boost git repository recursively seems to have issues.
by Cox, Michael 01 Nov '13

01 Nov '13

On Wed, Oct 30, 2013 at 11:16 PM, <boost-request(a)lists.boost.org> wrote: > Date: Wed, 30 Oct 2013 23:31:25 +0100 > From: Daniel Pfeifer <daniel(a)pfeifer-mail.de> > To: Boost Developers List <boost(a)lists.boost.org> > Cc: Mike <mhcox(a)bluezoosoftware.com> > Subject: [boost] [git help] Cloning the boost git repository > recursively seems to have issues. > Message-ID: > <CANZMcXrkLdL7-ax9CUnaySwJB4-=fSt3n627n3bdj_LF0Yp-KA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Mike, > > Thanks for reporting that issue. > Migration if Boost to modularized Git has been decoupled from Ryppl. > I forward your message to the Boost Developers List. > > -- Daniel > > ---------- Forwarded message ---------- > From: Mike <mhcox(a)bluezoosoftware.com> > Date: 2013/10/29 > Subject: [ryppl-dev] Cloning the boost git repository recursively > seems to have issues. > To: ryppl-dev(a)googlegroups.com > > > I ran the following git command to retrieve the latest modularized > boost code in github.com/boostorg: > > $ git clone --recursive https://github.com/boostorg/boost > > The boost repository and all its submodules were recursively cloned as > expected, but bootstrap.bat in the boost repository and some library > submodules were marked as modified. Not what I expected. I ran the > following command to get a list of the modified files in the > submodules: > $ git submodule foreach --recursive 'git status --short' > > I got the following output: > Entering 'libs/accumulators' > Entering 'libs/algorithm' > Entering 'libs/any' > ... > Entering 'libs/geometry' > M example/ml02_distance_strategy.cpp > Entering 'libs/gil' > ... > Entering 'libs/interprocess' > M proj/vc7ide/doc_managed_grow.vcproj > M proj/vc7ide/managed_shared_memory.vcproj > M proj/vc7ide/offset_ptr_test.vcproj > Entering 'libs/intrusive' > M proj/vc7ide/avl_multiset/avl_multiset.vcproj > M proj/vc7ide/avl_set/avl_set.vcproj > M proj/vc7ide/sg_multiset/sg_multiset.vcproj > M proj/vc7ide/sg_set/sg_set.vcproj > M proj/vc7ide/splay_multiset/splay_multiset.vcproj > M proj/vc7ide/splay_set/splay_set.vcproj > Entering 'libs/io' > ... > Entering 'libs/math' > M doc/equations/gamm1.svg > M doc/equations/gamm2.svg > M doc/equations/gamm3.svg > M doc/equations/gamm4.svg > M doc/equations/gamm5.svg > M doc/equations/gamma_dist_ref1.svg > M doc/equations/gamma_dist_ref2.svg > M doc/equations/gamma_ratio0.svg > M doc/equations/gamma_ratio1.svg > M doc/equations/hankel1.svg > M doc/equations/hankel2.svg > M doc/equations/hankel3.svg > M doc/equations/hankel4.svg > M doc/equations/hankel5.svg > M doc/equations/hazard.svg > M doc/equations/hermite_0.svg > M doc/equations/hermite_1.svg > M doc/equations/hypergeometric1.svg > M doc/equations/hypergeometric2.svg > M doc/equations/hypergeometric3.svg > M doc/equations/hypergeometric4.svg > M doc/equations/hypergeometric5.svg > M doc/equations/hypergeometric6.svg > M doc/equations/hypot.svg > M doc/equations/hypot2.svg > M doc/equations/ibeta1.svg > M doc/equations/ibeta10.svg > M doc/equations/ibeta11.svg > M doc/equations/ibeta12.svg > M doc/equations/ibeta2.svg > M doc/equations/ibeta3.svg > M doc/equations/ibeta4.svg > M doc/equations/ibeta5.svg > M doc/equations/ibeta6.svg > M doc/equations/ibeta7.svg > M doc/equations/ibeta8.svg > M doc/equations/ibeta9.svg > M doc/equations/ibeta_inv1.svg > M doc/equations/ibeta_inv2.svg > M doc/equations/ibeta_inv3.svg > M doc/equations/ibeta_inv4.svg > M doc/equations/ibeta_inv5.svg > M doc/equations/ibeta_inv6.svg > M doc/equations/ibeta_inv7.svg > M doc/equations/ibeta_inv8.svg > M doc/equations/igamma1.svg > M doc/equations/igamma10.svg > M doc/equations/igamma11.svg > M doc/equations/igamma11b.svg > M doc/equations/igamma12.svg > M doc/equations/igamma13.svg > M doc/equations/igamma16.svg > M doc/equations/igamma17.svg > M doc/equations/igamma18.svg > M doc/equations/igamma19.svg > M doc/equations/igamma1f.svg > M doc/equations/igamma2.svg > M doc/equations/igamma2f.svg > M doc/equations/igamma3.svg > M doc/equations/igamma4.svg > M doc/equations/igamma5.svg > M doc/equations/igamma6.svg > M doc/equations/igamma7.svg > M doc/equations/igamma8.svg > M doc/equations/igamma9.svg > M doc/equations/jacobi1.svg > M doc/equations/jacobi2.svg > M doc/equations/jacobi3.svg > M doc/equations/jacobi4.svg > M doc/equations/laguerre_0.svg > M doc/equations/laguerre_1.svg > M doc/equations/laguerre_2.svg > M doc/equations/laguerre_3.svg > M doc/equations/lanczos0.svg > M doc/equations/lanczos0a.svg > M doc/equations/lanczos0b.svg > M doc/equations/lanczos1.svg > M doc/equations/lanczos2.svg > M doc/equations/lanczos3.svg > M doc/equations/lanczos4.svg > M doc/equations/lanczos5.svg > M doc/equations/lanczos6.svg > M doc/equations/lanczos7.svg > M doc/equations/laplace_pdf.svg > M doc/equations/legendre_0.svg > M doc/equations/legendre_1.svg > M doc/equations/legendre_1b.svg > M doc/equations/legendre_2.svg > M doc/equations/legendre_3.svg > M doc/equations/legendre_4.svg > M doc/equations/legendre_5.svg > M doc/equations/lgamm1.svg > M doc/equations/lgamm2.svg > M doc/equations/lgamm3.svg > M doc/equations/lgamm4.svg > M doc/equations/lgamm5.svg > M doc/equations/lgamm6.svg > M doc/equations/log1pseries.svg > M doc/equations/lognormal_ref.svg > M doc/equations/mbessel1.svg > M doc/equations/mbessel10.svg > M doc/equations/mbessel11.svg > M doc/equations/mbessel12.svg > M doc/equations/mbessel13.svg > M doc/equations/mbessel14.svg > M doc/equations/mbessel15.svg > M doc/equations/mbessel16.svg > M doc/equations/mbessel17.svg > M doc/equations/mbessel2.svg > M doc/equations/mbessel3.svg > M doc/equations/mbessel4.svg > M doc/equations/mbessel5.svg > M doc/equations/mbessel6.svg > M doc/equations/mbessel7.svg > M doc/equations/mbessel8.svg > M doc/equations/mbessel9.svg > M doc/equations/nc_beta_ref1.svg > M doc/equations/nc_beta_ref2.svg > M doc/equations/nc_beta_ref3.svg > M doc/equations/nc_beta_ref4.svg > M doc/equations/nc_chi_squ_ref1.svg > M doc/equations/nc_chi_squ_ref2.svg > M doc/equations/nc_chi_squ_ref3.svg > M doc/equations/nc_chi_squ_ref4.svg > M doc/equations/nc_chi_squ_ref5.svg > M doc/equations/nc_chi_squ_ref6.svg > M doc/equations/nc_chi_squ_ref7.svg > M doc/equations/nc_f_ref1.svg > M doc/equations/nc_f_ref2.svg > M doc/equations/nc_t_ref1.svg > M doc/equations/nc_t_ref2.svg > M doc/equations/nc_t_ref3.svg > M doc/equations/nc_t_ref4.svg > M doc/equations/nc_t_ref5.svg > M doc/equations/neg_binomial_ref.svg > M doc/equations/normal_ref1.svg > M doc/equations/poisson_ref1.svg > M doc/equations/roots1.svg > M doc/equations/roots2.svg > M doc/equations/roots3.svg > M doc/equations/roots4.svg > M doc/equations/sbessel1.svg > M doc/equations/sbessel2.svg > M doc/equations/sbessel3.svg > M doc/equations/sbessel4.svg > M doc/equations/sbessel5.svg > M doc/equations/special_functions_blurb1.svg > M doc/equations/special_functions_blurb15.svg > M doc/equations/special_functions_blurb17.svg > M doc/equations/special_functions_blurb18.svg > M doc/equations/special_functions_blurb20.svg > M doc/equations/special_functions_blurb22.svg > M doc/equations/special_functions_blurb5.svg > M doc/equations/special_functions_blurb6.svg > M doc/equations/special_functions_blurb7.svg > M doc/equations/spherical_0.svg > M doc/equations/spherical_1.svg > M doc/equations/spherical_2.svg > M doc/equations/spherical_3.svg > M doc/equations/students_t_dist.svg > M doc/equations/students_t_ref1.svg > M doc/equations/zeta1.svg > M doc/equations/zeta2.svg > M doc/equations/zeta3.svg > M doc/equations/zeta4.svg > M doc/equations/zeta5.svg > M doc/equations/zeta6.svg > M doc/graphs/acosh.svg > M doc/graphs/airy_ai.svg > M doc/graphs/airy_aip.svg > M doc/graphs/airy_bi.svg > M doc/graphs/airy_bip.svg > M doc/graphs/asinh.svg > M doc/graphs/atanh.svg > M doc/graphs/bernoulli_cdf.svg > M doc/graphs/bernoulli_pdf.svg > M doc/graphs/beta.svg > M doc/graphs/beta_pdf.svg > M doc/graphs/binomial_pdf_1.svg > M doc/graphs/binomial_pdf_2.svg > M doc/graphs/cauchy_pdf1.svg > M doc/graphs/cauchy_pdf2.svg > M doc/graphs/cbrt.svg > M doc/graphs/chi_squared_pdf.svg > M doc/graphs/cyl_bessel_i.svg > M doc/graphs/cyl_bessel_j.svg > M doc/graphs/cyl_bessel_k.svg > M doc/graphs/cyl_neumann.svg > M doc/graphs/digamma.svg > M doc/graphs/ellint_1.svg > M doc/graphs/ellint_2.svg > M doc/graphs/ellint_3.svg > M doc/graphs/ellint_carlson.svg > M doc/graphs/erf.svg > M doc/graphs/erf_inv.svg > M doc/graphs/erfc.svg > M doc/graphs/erfc_inv.svg > M doc/graphs/expint2.svg > M doc/graphs/expint_i.svg > M doc/graphs/expm1.svg > M doc/graphs/exponential_pdf.svg > M doc/graphs/extreme_value_pdf1.svg > M doc/graphs/extreme_value_pdf2.svg > M doc/graphs/fisher_f_pdf.svg > M doc/graphs/gamma1_pdf.svg > M doc/graphs/gamma2_pdf.svg > M doc/graphs/gamma_p.svg > M doc/graphs/gamma_q.svg > M doc/graphs/hermite.svg > M doc/graphs/hypergeometric_pdf_1.svg > M doc/graphs/hypergeometric_pdf_2.svg > M doc/graphs/ibeta.svg > M doc/graphs/jacobi_cd.svg > M doc/graphs/jacobi_cn.svg > M doc/graphs/jacobi_cs.svg > M doc/graphs/jacobi_dc.svg > M doc/graphs/jacobi_dn.svg > M doc/graphs/jacobi_ds.svg > M doc/graphs/jacobi_nc.svg > M doc/graphs/jacobi_nd.svg > M doc/graphs/jacobi_ns.svg > M doc/graphs/jacobi_sc.svg > M doc/graphs/jacobi_sd.svg > M doc/graphs/jacobi_sn.svg > M doc/graphs/laguerre.svg > M doc/graphs/laplace_pdf.svg > M doc/graphs/legendre_p.svg > M doc/graphs/legendre_q.svg > M doc/graphs/lgamma.svg > M doc/graphs/log1p.svg > M doc/graphs/logistic_pdf.svg > M doc/graphs/lognormal_pdf1.svg > M doc/graphs/lognormal_pdf2.svg > M doc/graphs/nc_beta_pdf.svg > M doc/graphs/nc_f_pdf.svg > M doc/graphs/nc_t_pdf.svg > M doc/graphs/nccs_pdf.svg > M doc/graphs/negative_binomial_pdf_1.svg > M doc/graphs/negative_binomial_pdf_2.svg > M doc/graphs/normal_pdf.svg > M doc/graphs/pareto_pdf1.svg > M doc/graphs/pareto_pdf2.svg > M doc/graphs/poisson_pdf_1.svg > M doc/graphs/powm1.svg > M doc/graphs/rayleigh_cdf.svg > M doc/graphs/rayleigh_pdf.svg > M doc/graphs/sinc_pi.svg > M doc/graphs/sinhc_pi.svg > M doc/graphs/sph_bessel.svg > M doc/graphs/sph_neumann.svg > M doc/graphs/sqrt1pm1.svg > M doc/graphs/students_t_pdf.svg > M doc/graphs/tgamma.svg > M doc/graphs/tgamma_delta_ratio.svg > M doc/graphs/triangular_cdf.svg > M doc/graphs/triangular_pdf.svg > M doc/graphs/uniform_cdf.svg > M doc/graphs/uniform_pdf.svg > M doc/graphs/weibull_pdf1.svg > M doc/graphs/weibull_pdf2.svg > M doc/graphs/zeta1.svg > M doc/graphs/zeta2.svg > Entering 'libs/move' > ... > Entering 'libs/multiprecision' > M doc/floating_point_eg1.svg > M doc/floating_point_eg2.svg > M doc/floating_point_eg3.svg > Entering 'libs/numeric/conversion' > ... > Entering 'libs/pool' > M doc/images/mb1.svg > M doc/images/mb2.svg > M doc/images/mb3.svg > M doc/images/mb4.svg > M doc/images/pc1.svg > M doc/images/pc2.svg > M doc/images/pc3.svg > M doc/images/pc4.svg > M doc/images/pc5.svg > Entering 'libs/predef' > ... > Entering 'tools/inspect' > Entering 'tools/litre' > Entering 'tools/quickbook' > > All the "modified" files appear to be .bat, .vcproj, and .svg files > (although there was one file, example/ml02_distance_strategy.cpp in > libs/geometry). I thought it might be a problem with .gitattributes > files. When I looked at them, I noticed an unfamiliar attribute, > svneol=native. I expected to find eol=crlf for the .bat and .vcproj > files. I don't have autocrlf or safecrlf set in my ~.gitconfig file > (should I?). What is the svneol attribute? What am I missing? > > -- Some more info that I should have included: - Fedora 20 - git version 1.8.3.1 Mike

3 5

[1.55.0] Release candidates available
by Marshall Clow 01 Nov '13

01 Nov '13

Release candidate files for 1.55.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: ba1ae723b8b4d1edeca684bb14b3213b *boost_1_55_0_rc1.tar.gz 66e01be2f328c556835c42be7b6d17d5 *boost_1_55_0_rc1.tar.bz2 925bb6c96082033687e5742b4e77af7b *boost_1_55_0_rc1.zip 830d61075ecf7d5ebf7c0843033393bf *boost_1_55_0_rc1.7z Thanks! -- The release managers

8 9

Re: [boost] [git help] GitHub boostorg library authentication
by Cox, Michael 31 Oct '13

31 Oct '13

On Wed, Oct 30, 2013 at 12:00 AM, <boost-request(a)lists.boost.org> wrote: > > Date: Tue, 29 Oct 2013 21:03:01 -0700 > From: Dave Abrahams <dave(a)boostpro.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [git help] GitHub boostorg library authentication > Message-ID: <m27gcv76dm.fsf(a)papi.luannocracy.com> > Content-Type: text/plain > > Daniel Pfeifer <daniel(a)pfeifer-mail.de> writes: > > > 2013/10/29 Daniel James <daniel(a)calamity.org.uk>: > >> On 29 October 2013 04:36, Dave Abrahams <dave(a)boostpro.com> wrote: > >>> > >>>> The super-project can't use github's git urls as they don't > >>>> allow anonymous access. I believe the super-project should be using > >>>> https for submodules, rather than http. > >>> > >>> Why is that? Because it's possible to commit through https? > >> > >> Yes. > >> > >>> But won't someone complain that they can't access https behind their > >>> corporate firewall? It always seems like there's no right answer in > >>> this territory. > >> > >> Oh right, I hadn't thought of that. Making it easy to check out > >> probably should be the priority. > > > > I am behind a corporate firewall and I cannot access git repositories > > through ssh. > > https works in both directions (pull and push). > > Yes, different corporate firewalls block different protocols. But I'm > happy to change to https if everyone believes that will work better > overall. In the .gitmodules file you can use relative urls, e.g. [submodule "smart_ptr"] path = libs/smart_ptr url = ../smart_ptr # url = http://github.com/boostorg/smart_ptr.git fetchRecurseSubmodules = on-demand The protocol used to access the super-project boost is what will be used to retrieve the submodule projects. This might help with issues accessing the repositories, although the super-project will have to accessed via http/https (or whatever ports are open through the firewall). This also makes the whole repository structure relocatable, e.g. a development team using boost can clone all the repositories to their local development server without having to modify the .gitmodules file in the boost super-project. Unfortunately, there's no good way I'm aware of to clone all the repositories as bare repositories. Maybe the latest changes in how git submodules are stored (i.e. under .git/modules) will help. Michael

2 1

Fwd: [Boost-users] [test] floating point comparison
by Matthijs Möhlmann 31 Oct '13

31 Oct '13

Hello all, I already posted this to the boost users list, because I thought it was a problem in my code, but I think its a bug in boost test (unit tests) Versions: Boost: 1.54 GCC: 4.8.1 Does someone have an answer to this? -------- Original Message -------- Subject: [Boost-users] [test] floating point comparison Date: Wed, 30 Oct 2013 14:40:07 +0100 From: Matthijs Möhlmann <matthijs(a)cacholong.nl> Reply-To: boost-users(a)lists.boost.org To: boost-users(a)lists.boost.org Hello all, I've the following test program: #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MAIN #define BOOST_TEST_MODULE Master test suite #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE(TestCase) { BOOST_REQUIRE_CLOSE_FRACTION(45.00f, 45.17f, 0.004f); } When I compile it with the following line: g++ -o main.o -c -Werror -Wall -std=c++11 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_SPIRIT_USE_PHOENIX_V3 -DUTEST -g main.cpp g++ -o main main.o -lboost_unit_test_framework I get the following output: Running 1 test case... *** No errors detected If I lower the tolerance to 0.0004f then I'll get the following: Running 1 test case... main.cpp(8): fatal error in "TestCase": difference{0.00376352} between 45.00f{45} and 45.17f{45.1699982} exceeds 0.00039999999 *** 1 failure detected in test suite "Master test suite" Why does it say that the difference is 0.00376352 and not 0.17....... ? Regards, Matthijs Möhlmann _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

3 2