February 2018 - Boost - lists.preview.boost.org

Review of Yap concluded today
by Louis Dionne 20 Feb '18

20 Feb '18

Dear Boost, The review of Zach Laine's Yap library concluded today, February 19th. I'd like to thank everyone who submitted a review or participated to the discussion in one way or another. The following reviews were submitted: - Barrett Adair (accept): https://lists.boost.org/Archives/boost/2018/02/241284.php - Alex Hagen-Zanker (reject/conditional accept): https://lists.boost.org/Archives/boost/2018/02/241296.php - Paul Fultz II (accept): https://lists.boost.org/Archives/boost/2018/02/241251.php - John Fletcher (accept): https://lists.boost.org/Archives/boost/2018/02/241212.php - Brook Milligan (conditional accept): https://lists.boost.org/Archives/boost/2018/02/241386.php - Steven Watanabe (accept): https://lists.boost.org/Archives/boost/2018/02/241442.php Please let me know if I've missed anyone. Also, for reference purposes, here are other notable general threads in the list archives that are related to the review: - Discussion on contextual evaluation of terminals: https://lists.boost.org/Archives/boost/2018/02/241092.php - Discussion on std::tuple vs hana::tuple: https://lists.boost.org/Archives/boost/2018/02/241351.php - Steven Watanabe on the documentation: https://lists.boost.org/Archives/boost/2018/02/241196.php - Steven Watanabe on the implementation: https://lists.boost.org/Archives/boost/2018/02/241281.php - Kickoff post: https://lists.boost.org/Archives/boost/2018/02/241076.php - Post extending the review until February 19th: https://lists.boost.org/Archives/boost/2018/02/241303.php I will summarize what was discussed during the review and announce the result of the review in a future post. Regards, Louis Dionne

1 0

[gsoc 18] - Enhancing Boost.Intrusive Library
by harisaicharan.challa＠gmail.com 19 Feb '18

19 Feb '18

Hello Boost community, I am Hari sai charan challa, 3rd year undergraduate student from International Institute of Information Technology, Hyderabad (IIIT). I have been working on boost-libraries since 2 months, trying to fix a bug.I can code efficiently in C++ .I have good knowledge in Data structures and Algorithms.I am interested in "Enhancing Boost.Intrusive Library" project so i am looking for a mentor to guide me in this project.

3 3

(no subject)
by karan singh 18 Feb '18

18 Feb '18

hello all , i want to contribute for boost and want to participate in gsoc18. i have c++ knowledge but dont know where to start.

2 1

[gsoc 18] Enhancing Boost.Intrusive Library
by harisaicharan.challa＠gmail.com 18 Feb '18

18 Feb '18

Hello, I am Hari.I am working on competency test of "Enhancing Boost.Intrusive library" project , so can someone please elaborate on the following requirement for the competency test. Requirement:- Test programs for ensuring accuracy and performance benchmark tests against various type of solutions (brute-force, recursive, iterative) Thank-you.

1 0

(no subject)
by karan singh 18 Feb '18

18 Feb '18

hi all , i want to contribute for boost , can anyone help i am a newbie

1 0

Moving Boost.HigherOrderFunctions(formely know as Fit) to boostord
by paul 15 Feb '18

15 Feb '18

Hi All, Can someone with Admin access help me move my repo to boostorg? Thanks, Paul

2 3

[GSoC'18] Project : Add support for tensors
by Manan Sharma 15 Feb '18

15 Feb '18

Hello Boost Community, My name is Manan Sharma. I am a 3rd year undergraduate student pursuing my B.Tech in Computer Science and M.S by research in IIIT Hyderabad, India. I have good understanding of Linear Algebra and Machine Learning. I have a sound background in data structures and algorithms and have qualified twice for ACM ICPC regionals. I have secured good rank in other programming contests too. I have good understanding of C++ having done all my competitive programming and several different projects using it. I am interested in project for adding support for tensors in uBLAS. Since I am new to open source, please let me know as to how can I get started. Thanks Manan Sharma

2 1

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