- Boost - lists.boost.org

Can't build docs in downloaded Boost 1.66 sources
by Zach Laine 15 Feb '18

15 Feb '18

I came across this while trying to build the Yap docs, outside the Boost source tree. It turns out it doesn't work in the Boost source tree either. This: cd ~/boost_1_66_0 ./bootstrap.sh cd libs/units/doc ~/boost_1_66_0/b2 used to work (not sure how long ago). Now it says this: tzlaine@linux-desk:~/boost_1_66_0/libs/units/doc$ ~/boost_1_66_0/b2 Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) BoostBook warning: no DocBook XSL directory specified. If you have the DocBook XSL stylesheets installed, please set DOCBOOK_XSL_DIR to the stylesheet directory on either the command line (via -sDOCBOOK_XSL_DIR=...) or in a Boost.Jam configuration file. The DocBook XSL stylesheets are available here: http://docbook.sourceforge.net/ Stylesheets will be downloaded on-the-fly (very slow!) ...patience... ...patience... ...patience... ...found 2671 targets... ...updating 2 targets... xslt-xsltproc ../../../bin.v2/libs/units/doc/gcc-gnu-7/debug/threadapi-pthread/units.docbook http://docbook.sourceforge.net/release/xsl/current/common/common.xsl:1: parser error : Start ta g expected, '<' not found Project web is currently offline pending the final migration of its data to our ^ compilation error: file /home/tzlaine/boost_1_66_0/tools/boostbook/xsl/docbook.xsl line 12 elem ent import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/common/common.xs l XML_CATALOG_FILES="../../../bin.v2/boostbook_catalog.xml" export XML_CATALOG_FILES "xsltproc" --stringparam boost.defaults "Boost" --stringparam boost.root "../../../.." --strin gparam chunk.section.depth "8" --stringparam toc.max.depth "1" --stringparam toc.section.depth "8" --xinclude -o "../../../bin.v2/libs/units/doc/gcc-gnu-7/debug/threadapi-pthread/units.docbo ok" "/home/tzlaine/boost_1_66_0/tools/boostbook/xsl/docbook.xsl" "../../../bin.v2/libs/units/do c/gcc-gnu-7/debug/threadapi-pthread/units.xml" ...failed xslt-xsltproc ../../../bin.v2/libs/units/doc/gcc-gnu-7/debug/threadapi-pthread/units. docbook... ...skipped <phtml>standalone_HTML.manifest for lack of <p../../../bin.v2/libs/units/doc/gcc-gnu -7/debug/threadapi-pthread>units.docbook... ...failed updating 1 target... ...skipped 1 target... That's the full output from doing the build a second time, FWIW. Some of the steps the first time said the same thing, but it seemed too much to post. Anyone know what's doing on? Zach

2 2

New developer interested in working on the Project 1 of Boost.ublas for GSoC18
by pranay gupta 14 Feb '18

14 Feb '18

Hello everyone, My name is Pranay Gupta I am a second year computer science undergrad at IIIT Hyderabad, Im new here at Boost. I was very much interested in doing the first project of Boot.uBLAS which was about adding statistical and machine learning functions to Boost.uBLAS and have started with the competency test. Can someone please guide me as to how should I share my competency test with the mentors and improve it further. Thank You, Yours Sincerely, Pranay Gupta

2 1

Re: [boost] [yap] Review
by P F 14 Feb '18

14 Feb '18

> On Feb 14, 2018, at 1:38 PM, Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Tue, Feb 13, 2018 at 8:24 PM, P F <pfultz2(a)yahoo.com <mailto:pfultz2@yahoo.com>> wrote: > >> On Feb 12, 2018, at 7:57 PM, Zach Laine via Boost <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: >> >> On Mon, Feb 12, 2018 at 4:15 PM, P F via Boost <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> >> wrote: >> >> I actually experimented with trying to remove the Hana bits for this exact >> reason. The conclusion I came to was that writing the library was quite a >> bit harder in a couple of places, but that's not too bad. The bigger >> problem is that the lack of algorithms over std::tuple for users of the >> library when they write transforms. Maybe we should talk offline about how >> to do things that are done now with Hana, with Fit instead. > > Actually, the main algorithms you use are transform, for_each, and unpack, which is trivial to do with Fit. Doing a `zip` or `filter` is a little more complicated, but grepping the source code, I did not see that. I discuss how thats done here: > > http://pfultz2.com/blog/2015/09/12/power-of-unpack/ <http://pfultz2.com/blog/2015/09/12/power-of-unpack/> > > Which we can discuss more offline. > > I also use Hana constants all over the place. Yes, but it should be simple to move from `0_c` to `c<0>{}`. Ultimately, it really should be moved to a separate library, because even Boost.TypeTraits could use these “enhanced” integral constants(but that is another discussion). >>> by just taking it as a type and using something similiar to `mp_transform` >>> to change the parameters. Or even change `Kind` to be a type of >>> `std::integral_constant<boost::yap::expr_kind, Kind>` so `mp_transform` >>> could be used directly: >>> >>> template <typename Kind, typename Tuple> >>> struct user_expr : logical_not<user_expr> >>> { >>> static const boost::yap::expr_kind kind = Kind{}; >>> >>> Tuple elements; >>> }; >>> >> >> You certainly could. What does this buy, though? > > Being able to use `mp_assign` to change the parameters to `user_expr`. Although, you could write your own version which allows the first parameter to be an integral. > > Ok, but all of the above is still the "what". I want the "why". Why is it better to be able to use mp_assign? >> I'm not getting that >> part yet. One thing this give up is the inability to write functions in >> terms of chained >> >> constexpr if (kind == expr_kind::foo) >> >> statements, which I quite like. You can do this with is_same<> of course, >> but at the cost of 45 extra template instantiations and a lot more noise. > > That should still work. I dont see why it wouldn’t. In fact, you should be able to do all of these: > > template<boost::yap::expr_kind Kind> > using expr_kind_c = std::integral_constant<boost::yap::expr_kind, Kind>; > > constexpr if (kind == expr_kind_c<foo>{}) > constexpr if (Kind{} == expr_kind_c<foo>{}) > constexpr if (kind{} == expr_kind::foo) > > What may not work is doing something like `fit::if_(Kind{} == expr_kind_c<foo>{})`(due to lack of operator overloading for integral_constant), but using `fit::if_c<Kind{} == expr_kind_c<foo>{}>` still does work. > > Right, but all of that is noisier than what I currently have. Not really because `constexpr if (kind == expr_kind::foo)` will still work. > If there are advantages to using mp_assign, maybe this extra noise in a few places is worth it. I still have no idea what the mp_assign advantages are though. The point is to be able to get rid of `::` at the beginning in `BOOST_YAP_USER_UNARY_OPERATOR_MEMBER(logical_not, ::user_expr)`. If the user forgets those, you need to have a clear way to tell the user they need to add them, because it may not be obvious from the compiler error without understanding the implementation details. One way to solve this is to avoid it altogether by not passing a template, which you can try to utilize something like mp_assign. Another possible solution may be to add a static_assert with a message like “you are passing a type instead of template, you may need to prepend :: to the parameter to this macro". I think you can use function overloading to distinguish between a type and a template, but I am not sure. Paul

4 3

We need more mentors for GSoC
by David Bellot 14 Feb '18

14 Feb '18

Hi Boost community, we have already a few mentors, but we need more. If you're interested working with top-level C++ students from all around the world, please contact me and I'll add you to the list of mentors. We need more mentors now ! Best regards, David

2 2

[gsoc-18] enhancing boost.intrusive library
by Anurag Tangri 14 Feb '18

14 Feb '18

Hello Boost Community. My name is Anurag Tangri. I am a 3rd year student at Thapar university patiala. I have good knowledge of C++ programming knowledge because of my competitive programming background. I am interested in “Enhancing Boost.Intrusive Library” project so i am a looking for mentor to guide me.

2 1

Yap review extended until Feb 19th
by Louis Dionne 14 Feb '18

14 Feb '18

Dear Boost community, The review of Zach Laine's Yap library was supposed to conclude today, Wednesday February 14th. To give more people the chance to review the library, and since there's no review scheduled directly after Yap, the review period will be extended until (and including) Monday February 19th. Thanks, Louis Dionne

1 0

[gsoc-18]
by Anurag Tangri 14 Feb '18

14 Feb '18

Hello Boost community ! My name is Anurag Tangri. I am a 3rd year undergrad at Thapar University. I am very much familiar with C++14 because of my competitive programming background.I have decent knowledge of Data structures and algorithms and eagerly want to contribute in open source. I am new to open source and stuff. So it would be very helpful if someone could guide me.

1 0

[release] 1.67.0 deadline for new libraries approaching
by Daniel James 14 Feb '18

14 Feb '18

One week from today master will closed for new libraries and breaking changes. Thanks, -- The Boost Release Team

2 1

[release notes] Linking to github issues/pull requests
by Daniel James 14 Feb '18

14 Feb '18

Hi, I've added templates for linking to github issues and pull requests from the release notes. There are two templates: [github module number] which expands to '#number' [github_pr module number] which expands to 'PR#number'. Both will be linked, they need the name of the module to link to the right place. We only really need the issue template as github redirects to the pull request if appropriate, but existing release notes have been using the PR#3 format, so I thought it should support that. You can see an example in the unordered release notes for 1.67.0: https://github.com/boostorg/website/blob/master/feed/history/boost_1_67_0.q… http://www.boost.org/users/history/in_progress.html Does that look okay? Daniel

5 17

[yap] Review
by P F 14 Feb '18

14 Feb '18

- Whether you believe the library should be accepted into Boost I think it should be Accepted. - Your name Paul Fultz II - What is your evaluation of the library's: The design is very nice and simple to follow. I have found Proto to be a little hard for me to grep, but this seems fairly simple to follow. I think the transform -> evalute workflow is great. Also, with transforms being just function objects, it makes transformations very composable. I think this library is very useful. I would love to use this for some projects at work, but the dependency on Hana prevents that(I need to support gcc 5 and MSVC). Looking at the codebase, it could easily be replaced with Boost.Fit(once its included in the release) in the future. Of course, I dont expect a reimplementation without Hana as a condition for acceptance. However, I think Hana at least can be removed from the "interface". The expression elements could be expressed as a `std::tuple` and the placeholders could be a `std::integral_constant`. This should make it easier to use another backend without breaking API compatibility. Some other notes: - Couldn't the operator macros be provided as base classes? So instead of writing: template <boost::yap::expr_kind Kind, typename Tuple> struct user_expr { static const boost::yap::expr_kind kind = Kind; Tuple elements; // Member operator overloads for operator!(). BOOST_YAP_USER_UNARY_OPERATOR_MEMBER(logical_not, ::user_expr) }; The user could write: template <boost::yap::expr_kind Kind, typename Tuple> struct user_expr : logical_not<::user_expr> { static const boost::yap::expr_kind kind = Kind; Tuple elements; }; You could also get rid of the need for `::user_expr` by just taking it as a type and using something similiar to `mp_transform` to change the parameters. Or even change `Kind` to be a type of `std::integral_constant<boost::yap::expr_kind, Kind>` so `mp_transform` could be used directly: template <typename Kind, typename Tuple> struct user_expr : logical_not<user_expr> { static const boost::yap::expr_kind kind = Kind{}; Tuple elements; }; - The customization points seem unnecessary. Why wouldn't the user just use `transform`? Using `transform` also keeps the customizations local. Also, implicit transformations seems like it would lead to suprises(and not good suprises). Are those on the cutting block? - It would be interesting to provide common transformations, like common subexpression elimination, or dead code elimination, but I guess that is beyond the scope of this library. - The `op_string` function is missing the case for `expr_ref` and `terminal`. Also, the tests only check for plus. - The `make_expr_from_tuple` does a move here: auto make_expr_from_tuple (ExprTemplate<Kind, OldTuple> const & expr, NewTuple && tuple) { return ExprTemplate<Kind, NewTuple>{std::move(tuple)}; } But maybe this should be using `std::forward`? - Did you attempt to use the library? If so: Yes, I ran it on clang 3.8 and gcc 7. - How much effort did you put into your evaluation of the review? Several hours

3 8