October 2013 - Boost - lists.preview.boost.org

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

[MPL] RFC: An MPL macro to define a has_member_xxx<T> predicate
by Erik Erlandson 31 Oct '13

31 Oct '13

If there's already a boost solution for this, then I have egg on my face, but I can't find one: I'd like an MPL macro that defines a predicate template which inherits from boost::true_type iff the given type defines *any* member with a particular name (false_type otherwise), and which does not assume the member name exists, like this: struct my_class { // foo might be member data, member function, a typedef, etc: int foo; }; CREATE_MEMBER_CHECK(foo); CREATE_MEMBER_CHECK(bar); has_member_foo<my_class> t1; // this inherits from true_type has_member_bar<my_class> t2; // this inherits from false_type I wrote an implementation of the above, and example, here: https://gist.github.com/erikerlandson/7251015 The macro BOOST_MPL_HAS_XXX_TRAIT_DEF produces a predicate class that detects if a nested type exists, but only works for types, not other kinds of defined members. The class is_member_pointer<T>, but appears to require that you already know a symbol exists. I suppose such a macro might be called BOOST_MPL_HAS_XXX_MEMBER_DEF.

2 2

Re: [boost] [asio] Bug: Handlers execute on the wrong strand (Gavin Lambert).
by Marat Abrarov 31 Oct '13

31 Oct '13

> I actually ended up abandoning Asio and rolling my own threadqueue (I > didn't want any of the socket-related stuff so this wasn't as big a job > as it sounds). Mine isn't fully-baked yet (and it's Windows-only for > the moment) and I'm not sure I'd want to show it off either, but on the > upside most of the guts are entirely lock-free (though not wait-free, > since it's based on Boost.LockFree's queue). Asio at Windows uses IOCP (default settings, using asio::io_service for task scheduling) and that is the (theoretical) reason of better thread scheduling for the Asio-based thread pool. Sometimes it's really visible. Regards, Marat Abrarov.

3 6

Reimplementation of the MPL for C++11
by Louis Dionne 31 Oct '13

31 Oct '13

Hi, I am currently working on a reimplementation of the MPL for C++11. Although the library is not complete yet, I would like to gauge interest for the project from the Boost community. I wanted to wait until I have resolved some core issues before posting here, but reading the [modularization] thread made it unbearable to wait any longer :-). The library is available on GitHub: github.com/ldionne/mpl11. If some people happen to be interested by the project and would like to get involved, please get in touch with me. Regards, Louis Dionne N.B.: Some design decisions will be influenced by the community (if there's interest) and I'm experimenting a lot. Don't be put off if you see something that you don't like: it might change.

12 23

[range] RFC: span(iterator, size)
by TONGARI J 31 Oct '13

31 Oct '13

Hi there, I want to query if there's any interest in such a utility: span(iterator, size) : iterator_range which simply returns iterator_range(it, it + size) for RandomAccessIterator; for others modeling ForwardIterator, a special iterator adaptor, say, counted_iterator is used, so we don't have to advance it just for getting the end iterator. Thoughts?

3 15

BOOST ASIO: Having successful READ from the SERVER ..??
by Rahul Mathur 31 Oct '13

31 Oct '13

All, Initially after having done successful CONNECT with the server, sending successful LOGON message and finally KEEP ALIVE status, I tried to read from the server as - -- boost::asio::streambuf data; std::size_t length = boost::asio::read(socket, data, boost::asio::transfer_at_least(socket.available())); -- but was able to partially receive response from remote server which I don't think was completely successful, so to have COMPLETE RESPONSE from the server, tried with below modification - -- boost::system::error_code ec; boost::asio::streambuf data; std::size_t length = boost::asio::read(socket, data, boost::asio::transfer_all(), ec); --- but this modification doesn't work. Any clue what should be the proper way? Thanks!!

1 0

[git help] Cloning the boost git repository recursively seems to have issues.
by Daniel Pfeifer 30 Oct '13

30 Oct '13

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? -- You received this message because you are subscribed to the Google Groups "ryppl-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to ryppl-dev+unsubscribe(a)googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.

1 0

Re: [boost] Introduction and Cray support. [config] [build] [atomic] [interprocess] [asio] [dump] [tr1]
by Brian Wood 30 Oct '13

30 Oct '13

From: Richard Dale > Hello world, > > My name is Richard Dale. I work at Cray, Inc. > My purpose here is to get the boost libraries and Cray C++ compiler to > work and play together better. > > I have a couple of questions, but maybe some background first. Hi, Richard, Would you be willing to check if the archive here: http://webEbenezer.net/build_integration.html builds with the Cray compiler? That software is needed to use the C++ Middleware Writer (CMW). The CMW has marshalling support for some Boost libraries. On a machine here, the software builds in under six seconds. Barring portability problems, I'm sure it would be less than that on one of your machines. Also/alternatively, could I have remote access to one of your machines with your C++ compiler on it? Thank you for considering these requests. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

[build] bootstrap.sh is still broken
by Stephan T. Lavavej 30 Oct '13

30 Oct '13

Hi, For months, I've been pinging the boost-build list about bootstrap.sh being completely broken for MinGW, with no response. As the 1.55.0 branch is closing in just a week, it would be wonderful if somebody could look at and apply my two patches that are ready to go: http://lists.boost.org/boost-build/2013/10/27025.php Note that they will fix this: https://svn.boost.org/trac/boost/ticket/8762 Thanks, STL

15 68