March 2021 - Boost - lists.boost.org

Re: [boost] Boost Digest, Vol 6566, Issue 1
by shady mohamed 28 Mar '21

28 Mar '21

I want to talk with engineer david bellot and engineer cem bassoy Thanks في الجمعة، ٢٦ مارس، ٢٠٢١ ١٢:٢٣ م <boost-request(a)lists.boost.org> كتب: > Send Boost mailing list submissions to > boost(a)lists.boost.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.boost.org/mailman/listinfo.cgi/boost > or, via email, send a message with subject or body 'help' to > boost-request(a)lists.boost.org > > You can reach the person managing the list at > boost-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost digest..." > > > The boost archives may be found at: http://lists.boost.org/Archives/boost/ > > > Today's Topics: > > 1. Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 (Andrzej Krzemienski) > 2. Re: [release] 1.76.0 post-beta merges (Niall Douglas) > 3. Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 (Peter Dimov) > 4. Re: [release] 1.76.0 post-beta merges (Marshall Clow) > 5. Re: [release] 1.76.0 post-beta merges (Niall Douglas) > 6. Re: [release] 1.76.0 post-beta merges (Glen Fernandes) > 7. Re: [Lambda2] Review starts Monday March 22, 2021 to March > 31, 2021 (Julien Blanc) > 8. Re: [Lambda2] Review starts Monday March 22, 2021 to March > 31, 2021 (Andrzej Krzemienski) > 9. Re: [Lambda2] Review starts Monday March 22, 2021 to March > 31, 2021 (Julien Blanc) > 10. Re: [Boost] [Describe] Summary Review Summary (Emil Dotchevski) > 11. Re: [Lambda2] Review starts Monday March 22, 2021 to March > 31, 2021 (Mathias Gaunard) > 12. Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 (Mathias Gaunard) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 25 Mar 2021 14:54:17 +0100 > From: Andrzej Krzemienski <akrzemi1(a)gmail.com> > To: Boost mailing list <boost(a)lists.boost.org> > Cc: Peter Dimov <pdimov(a)gmail.com> > Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22, > 2021 to March 31, 2021 > Message-ID: > <CAOenAXhsJ1yCRRBYgJuPh8xws5MMVCks7p6GvfmBG+= > 28QDNPg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > pon., 22 mar 2021 o 16:44 Peter Dimov via Boost <boost(a)lists.boost.org> > napisa?(a): > > > Edward Diener wrote: > > > My first reaction, after quickly looking at the submission, is what > does > > this > > > library offer that the original lambda library, which appears to have a > > much > > > larger amount of functionality than this lambda2 library, not offer ? > > Also there > > > is the Phoenix library, which also offers an even greater amount of > > function > > > object and lambda-like functionality, of which the review manager is > the > > main > > > author I believe. > > > > Purely from a user perspective, what this library offers is being a > > lightweight, > > single header dependency, and... > > > > > Is it basically so that the programmer can easily interface with > > > the std::bind/std::function classes with the lambda2 placeholders, > > whereas the > > > C++03 libraries don't have this possibility wit their placeholders ? > > > > ... indeed, a way to port boost::bind code that uses its operators to > > std::bind, > > something that comes up from time to time as projects are modernized. > > > > From a different perspective, another goal of the submission is to gather > > experience and provide a tested and widely available implementation for > an > > eventual proposal to add this functionality to the standard. (Better late > > than > > never.) > > > > My opinion so far is that there is not enough motivation to warrant the > addition of this library into Boost. > > First, the design goals, or the purpose, of the library is not clearly > defined. > > Is the goal that tandem std::bind + Boost.Lambda2 should be a replacement > over boost::bind and Boost.Lambda? If so, in the current form of the > library the goal will not be satisfied, because current Boost.Lambda offers > quite more things. Just look at the motivating examples of Boost.Lambda: > https://www.boost.org/doc/libs/1_75_0/doc/html/lambda/using_library.html > In particular, the usage of assignment or function constant(). > Boost.Lambda2 will not work as a drop-in replacement for Boost.Lambda. > > For a moment I thought that the goal is to have a cooler syntax for the > current standard arithmetic function objects, such as std::plus, > std::multiplies. But the advantage is dubious. You gain a few characters, > but you pay the cost of > * employing a different library > * messy error messages > * no debugger support > > The suggestion that we would enable constructs like > `std::bind(&Employee::name, e1) < std::bind(&Employee::name, e2)`also > doesn't seem like a good motivation. std::bind only works well when it is > used for binding arguments to functions. Overusing it for implementing > lambdas made sense in C++03, because there was no other way. Now with > generic lambdas it can only be considered a bad (or at least controversial) > practice. > > I am far from imposing my programming style on others. But promoting a > programming style like this through the inclusion into Boost seems too > much. My vision of Boost is that it should support certain programming > styles that are considered good, but not any programming style. > > Regarding the implementation, on the other hand, it is as elegant as a > library implementation could ever be. It is extremely short! (78 lines, > including whitespace, header guards, and copyright notice). > > Regards, > &rzej; > > > ------------------------------ > > Message: 2 > Date: Thu, 25 Mar 2021 15:06:02 +0000 > From: Niall Douglas <s_sourceforge(a)nedprod.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [release] 1.76.0 post-beta merges > Message-ID: <6efb04af-9f26-4d04-a187-8bc08369caf3(a)nedprod.com> > Content-Type: text/plain; charset=utf-8 > > On 16/03/2021 20:24, Marshall Clow via Boost wrote: > > The master branch is is now open for post-beta merges, but only as > described in the Post-Beta Merge Policy. > > See < > https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> > > I would like to fix https://github.com/ned14/outcome/issues/249 by > improving the logic at > > https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L… > please. > > Niall > > > ------------------------------ > > Message: 3 > Date: Thu, 25 Mar 2021 17:24:15 +0200 > From: "Peter Dimov" <pdimov(a)gmail.com> > To: "'Andrzej Krzemienski'" <akrzemi1(a)gmail.com>, "'Boost mailing > list'" <boost(a)lists.boost.org> > Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22, > 2021 to March 31, 2021 > Message-ID: <131601d7218a$eb1033b0$c1309b10$(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > Andrzej Krzemienski wrote: > > First, the design goals, or the purpose, of the library is not clearly > defined. > > The goals of the library are > > - Give people the choice of using an abbreviated lambda syntax that is able > to express simple operations in fewer characters; > - Bring std::bind to parity with boost::bind feature-wise so that porting > is > easier; > - Prepare a proposal to extend the standard with these same additions by > gathering experience in Boost first. > > > Is the goal that tandem std::bind + Boost.Lambda2 should be a replacement > > over boost::bind and Boost.Lambda? If so, in the current form of the > library > > the goal will not be satisfied, because current Boost.Lambda offers > quite more > > things. > > This doesn't make it useless. When porting "operator-enhanced" boost::bind, > or Boost.Lambda, code, you need to go over all the uses and change them > into language lambdas. This is routine mechanical work that as a result is > highly error-prone and without good test coverage, mistakes can easily pass > review because of the repetitive nature of the diff. It's much better if > you > could port at least some of the uses without making changes beyond > replacing > boost:: with std::, and adding/changing the using directive. > > It's not necessary to be able to port _all_ uses without any changes; a > portion > is enough to reduce the error rate significantly. > > And if you're going to ask what's the point of porting from one Boost > library > to another, the difference is that it's much easier to "vendor" a single > short > header. > > > For a moment I thought that the goal is to have a cooler syntax for the > current > > standard arithmetic function objects, such as std::plus, > std::multiplies. But the > > advantage is dubious. You gain a few characters, but you pay the cost of > > * employing a different library > > * messy error messages > > * no debugger support > > This could be true, but it has nothing to do with the library lacking > clarity of > purpose. > > > The suggestion that we would enable constructs like > > `std::bind(&Employee::name, e1) < std::bind(&Employee::name, e2)`also > > doesn't seem like a good motivation. > > As explained, this is only an issue when porting boost::bind code using > these constructs. You obviously aren't going to use this in new code > because > the equivalent language lambda is shorter (not by much) and clearer. > > > > ------------------------------ > > Message: 4 > Date: Thu, 25 Mar 2021 08:45:22 -0700 > From: Marshall Clow <mclow.lists(a)gmail.com> > To: Boost Developers List <boost(a)lists.boost.org> > Subject: Re: [boost] [release] 1.76.0 post-beta merges > Message-ID: <0EAF569D-A080-4217-BC77-D7CE4057EC0A(a)gmail.com> > Content-Type: text/plain; charset=utf-8 > > On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost < > boost(a)lists.boost.org> wrote: > > > > On 16/03/2021 20:24, Marshall Clow via Boost wrote: > >> The master branch is is now open for post-beta merges, but only as > described in the Post-Beta Merge Policy. > >> See < > https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> > > > > I would like to fix https://github.com/ned14/outcome/issues/249 by > > improving the logic at > > > https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L… > > please. > > Do you have a commit that fixes this? > > ? Marshall > > > > > ------------------------------ > > Message: 5 > Date: Thu, 25 Mar 2021 16:04:17 +0000 > From: Niall Douglas <s_sourceforge(a)nedprod.com> > To: Boost Developers List <boost(a)lists.boost.org> > Subject: Re: [boost] [release] 1.76.0 post-beta merges > Message-ID: <2dc9222a-592a-6b85-c76b-d62ef55611b3(a)nedprod.com> > Content-Type: text/plain; charset=utf-8 > > On 25/03/2021 15:45, Marshall Clow wrote: > > On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost < > boost(a)lists.boost.org> wrote: > >> > >> On 16/03/2021 20:24, Marshall Clow via Boost wrote: > >>> The master branch is is now open for post-beta merges, but only as > described in the Post-Beta Merge Policy. > >>> See < > https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> > >> > >> I would like to fix https://github.com/ned14/outcome/issues/249 by > >> improving the logic at > >> > https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L… > >> please. > > > > Do you have a commit that fixes this? > > The change is trivial. Current: > > ```c++ > #if !defined(_MSC_VER) && !defined(__clang__) && (__GNUC__ < 9 || > __cpp_concepts < 201907L) > #define OUTCOME_GCC6_CONCEPT_BOOL bool > #else > #define OUTCOME_GCC6_CONCEPT_BOOL > #endif > ``` > > To be replaced with: > > ```c++ > #if (defined(_MSC_VER) || defined(__clang__) || (defined(__GNUC__) && > __cpp_concepts >= 201707) || OUTCOME_FORCE_STD_CXX_CONCEPTS) && > !OUTCOME_FORCE_LEGACY_GCC_CXX_CONCEPTS > #define OUTCOME_GCC6_CONCEPT_BOOL > #else > #define OUTCOME_GCC6_CONCEPT_BOOL bool > #endif > ``` > > To explain, GCC expects bool with concept, or not, in varying > configuration combinations which have evolved over GCC versions, > including apparently point releases, which is deeply unhelpful. This has > led to repeated bug reports for not just Outcome, but also for ASIO and > many other C++ projects. > > If this above fix doesn't permanently shut this constant source of bug > reports, I'll be permanently disabling legacy GCC concepts support in > Outcome. I couldn't be arsed with supporting how unpredictably broken > GCC is with this. > > Niall > > > ------------------------------ > > Message: 6 > Date: Thu, 25 Mar 2021 12:12:03 -0400 > From: Glen Fernandes <glen.fernandes(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [release] 1.76.0 post-beta merges > Message-ID: > <CAHVPgznFdSVYJ9gR8LzP7qQV7w5+fcjBvKq95ReUKkFR-ct= > Qg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Thu, Mar 25, 2021 at 12:04 PM Niall Douglas via Boost > <boost(a)lists.boost.org> wrote: > > > > On 25/03/2021 15:45, Marshall Clow wrote: > > > On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost < > boost(a)lists.boost.org> wrote: > > >> > > >> I would like to fix https://github.com/ned14/outcome/issues/249 by > > >> improving the logic at > > >> > https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L… > > >> please. > > > > > > Do you have a commit that fixes this? > > > > The change is trivial. Current: > > If you're asking for permission to merge to master now, you should > have a commit on outcome's develop branch that we can look at. You are > free to commit to develop at any time. Only master is locked. > > Glen > > > ------------------------------ > > Message: 7 > Date: Thu, 25 Mar 2021 19:10:33 +0100 > From: Julien Blanc <julien.blanc(a)tgcm.eu> > To: boost(a)lists.boost.org > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: <2773cbf43ec651fdf2b3a3262c8476d814047eb0.camel(a)tgcm.eu> > Content-Type: text/plain; charset="UTF-8" > > Le lundi 22 mars 2021 ? 10:35 +0800, Joel de Guzman via Boost a ?crit?: > > The Boost formal review of the Lambda2, authored by Peter Dimov, > > starts Monday, March 22, 2021 to March 31, 2021 (inclusive). > > Here's my small review of the lambda 2 library. > > TLDR: ACCEPT > > > ?? - What is your evaluation of the design? > > ?? - What is your evaluation of the implementation? > > The library is a really small piece of code, like other reviewers > already noticed. During my tests, i came across two things that could > be improved: > * the internal macro BOOST_LAMBDA2_UNARY_LAMBDA and > BOOST_LAMBDA2_BINARY_LAMBDA #undefed at the end of the file. While i > undestand that it is an internal macro, it could be exposed to the user > to allow implementation for other operators > * that macro hardcode the std prefix, it could be part of its call, ie: > > BOOST_LAMBDA2_BINARY_LAMBDA(+, std::plus) // instead of > BOOST_LAMBDA2_BINARY_LAMBDA(+, plus) > > This would allow the user of the library to get the building blocks to > customize other operators to its needs (I have implemented unary > operator* easily that way). > > > ?? - What is your evaluation of the documentation? > > The documentation is really good at telling what the library does, is > clean, nice looking. > > > ?? - What is your evaluation of the potential usefulness of the > > library? > > At first glance, i was thinking that this was the kind of library that > i would never use. I find the count_if examples in the documentation > not really convincing. > > Then, it happened that i made some experiments with c++20 ranges. And i > find that, in this context, shortening the lambdas gives a real benefit > to the code. It basically started from the need to feed a function that > was needing a list of non owner references to T from a > vector<unique_ptr<T>>. As I was not satisfied with the solution, I > checked whether c++20 ranges could provide an elegant solution to this. > Something like > > f(std::views::transform(vec, deref)); > > implementing deref is easy. Then, out of curiosity, i checked if i > could use Peter's library to be able to write something like: > > f(std::views::transform(vec, *_1)); > > I actually find that this way of writing is more natural than the > former. > > So, i wrote : > > namespace std // BAD, don't do that > { > template<typename T = void> > struct deref > { > decltype(auto) operator()(T& v) { return *v; } > }; > template<> > struct deref<void> > { > template<typename T> > decltype(auto) operator()(T& v) { return *v; } > }; > } > > BOOST_LAMBDA2_UNARY_LAMBDA(*, deref); > > modified Peter's library to remove the #undef, and voila, it just > works. > > I see a lot of potential for the short writing form for lambdas, in > conjunction with the ranges library. I find convenient to write: > > f(std::views::transform(vec, _1 + 1)) // convert from 0-based to 1- > based index > > > ?? - Did you try to use the library? With which compiler(s)? Did you > > ???? have any problems? > > No specific issue encountered, with gcc-10. Error messages are a bit > cryptic. > > > ?? - How much effort did you put into your evaluation? A glance? A > > quick > > ???? reading? In-depth study? > > A few hours playing with the library. > > > ?? - Are you knowledgeable about the problem domain? > > Not at all. > > My feeling is the following. At first glance, i was wondering what was > the use case the library addressed. After playing a bit with it, i'm > now convinced that people will want to use it, and, like me, will > probably want to expand it to fit their need. I was not suspecting that > it was possible to write code that way. I suspect most developers are > not either. Now that it is known it's possible, people will come up > with their own, probably inferior, solution. Having such a feature in > boost would at least provide everyone with a correct implementation of > it. Because people will want to write code like this, and i believe, > especially with ranges. > > Thanks to Peter for writing this library, and proposing it to boost. > Reviewing it has been very interesting and instructive. > > Regards, > > Julien > > > > ------------------------------ > > Message: 8 > Date: Fri, 26 Mar 2021 05:54:36 +0100 > From: Andrzej Krzemienski <akrzemi1(a)gmail.com> > To: Boost mailing list <boost(a)lists.boost.org> > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: > <CAOenAXgEDx= > kmKY5gVdST-oAeipoa2oG2s5j_y0brxs34r7ojw(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > czw., 25 mar 2021 o 19:11 Julien Blanc via Boost <boost(a)lists.boost.org> > napisa?(a): > > > Le lundi 22 mars 2021 ? 10:35 +0800, Joel de Guzman via Boost a ?crit : > > > The Boost formal review of the Lambda2, authored by Peter Dimov, > > > starts Monday, March 22, 2021 to March 31, 2021 (inclusive). > > > > Here's my small review of the lambda 2 library. > > > > TLDR: ACCEPT > > > > > - What is your evaluation of the design? > > > - What is your evaluation of the implementation? > > > > The library is a really small piece of code, like other reviewers > > already noticed. During my tests, i came across two things that could > > be improved: > > * the internal macro BOOST_LAMBDA2_UNARY_LAMBDA and > > BOOST_LAMBDA2_BINARY_LAMBDA #undefed at the end of the file. While i > > undestand that it is an internal macro, it could be exposed to the user > > to allow implementation for other operators > > * that macro hardcode the std prefix, it could be part of its call, ie: > > > > BOOST_LAMBDA2_BINARY_LAMBDA(+, std::plus) // instead of > > BOOST_LAMBDA2_BINARY_LAMBDA(+, plus) > > > > This would allow the user of the library to get the building blocks to > > customize other operators to its needs (I have implemented unary > > operator* easily that way). > > > > Is it not just that the library is missing some operators? If Boost.Lambda2 > overloaded all overloadable operators there would be no point in users > doing it. > > > > > - What is your evaluation of the documentation? > > > > The documentation is really good at telling what the library does, is > > clean, nice looking. > > > > > - What is your evaluation of the potential usefulness of the > > > library? > > > > At first glance, i was thinking that this was the kind of library that > > i would never use. I find the count_if examples in the documentation > > not really convincing. > > > > Then, it happened that i made some experiments with c++20 ranges. And i > > find that, in this context, shortening the lambdas gives a real benefit > > to the code. It basically started from the need to feed a function that > > was needing a list of non owner references to T from a > > vector<unique_ptr<T>>. As I was not satisfied with the solution, I > > checked whether c++20 ranges could provide an elegant solution to this. > > Something like > > > > f(std::views::transform(vec, deref)); > > > > implementing deref is easy. Then, out of curiosity, i checked if i > > could use Peter's library to be able to write something like: > > > > f(std::views::transform(vec, *_1)); > > > > I actually find that this way of writing is more natural than the > > former. > > > > This is an interesting observation. In my experience, storing collections > of ints is a rare case in production code (it is frequent in tests, > tutorials, books, presentations), maybe this is why arithmetic operators do > not appear as something practical. However pointers (including smart ones) > to user-defined types is something that I see a lot. The following als > looks as something I would see often in the code: > > assert(std::ranges::all_of(records, _1 != nullptr)); > > Regards, > &rzej; > > > > So, i wrote : > > > > namespace std // BAD, don't do that > > { > > template<typename T = void> > > struct deref > > { > > decltype(auto) operator()(T& v) { return *v; } > > }; > > template<> > > struct deref<void> > > { > > template<typename T> > > decltype(auto) operator()(T& v) { return *v; } > > }; > > } > > > > BOOST_LAMBDA2_UNARY_LAMBDA(*, deref); > > > > modified Peter's library to remove the #undef, and voila, it just > > works. > > > > I see a lot of potential for the short writing form for lambdas, in > > conjunction with the ranges library. I find convenient to write: > > > > f(std::views::transform(vec, _1 + 1)) // convert from 0-based to 1- > > based index > > > > > - Did you try to use the library? With which compiler(s)? Did you > > > have any problems? > > > > No specific issue encountered, with gcc-10. Error messages are a bit > > cryptic. > > > > > - How much effort did you put into your evaluation? A glance? A > > > quick > > > reading? In-depth study? > > > > A few hours playing with the library. > > > > > - Are you knowledgeable about the problem domain? > > > > Not at all. > > > > My feeling is the following. At first glance, i was wondering what was > > the use case the library addressed. After playing a bit with it, i'm > > now convinced that people will want to use it, and, like me, will > > probably want to expand it to fit their need. I was not suspecting that > > it was possible to write code that way. I suspect most developers are > > not either. Now that it is known it's possible, people will come up > > with their own, probably inferior, solution. Having such a feature in > > boost would at least provide everyone with a correct implementation of > > it. Because people will want to write code like this, and i believe, > > especially with ranges. > > > > Thanks to Peter for writing this library, and proposing it to boost. > > Reviewing it has been very interesting and instructive. > > > > Regards, > > > > Julien > > > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > > ------------------------------ > > Message: 9 > Date: Fri, 26 Mar 2021 07:44:43 +0100 > From: Julien Blanc <julien.blanc(a)tgcm.eu> > To: boost(a)lists.boost.org > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: <54d581dd2987773250b0f822393ea819a03297bc.camel(a)tgcm.eu> > Content-Type: text/plain; charset="UTF-8" > > Le vendredi 26 mars 2021 ? 05:54 +0100, Andrzej Krzemienski via Boost a > ?crit?: > > > This would allow the user of the library to get the building blocks > > > to > > > customize other operators to its needs (I have implemented unary > > > operator* easily that way). > > > > > > > Is it not just that the library is missing some operators? If > > Boost.Lambda2 > > overloaded all overloadable operators there would be no point in > > users > > doing it. > > Agreed. But I don't have a strong opinion on whether the library should > implement everything, or just be more open to user extensions. > > > The following als looks as something I would see often in the code: > > > > assert(std::ranges::all_of(records, _1 != nullptr)); > > Definitely. That's the kind of motivating example that i think should > appear in the documentation. > > Regards, > > Julien > > > > ------------------------------ > > Message: 10 > Date: Fri, 26 Mar 2021 00:23:56 -0700 > From: Emil Dotchevski <emildotchevski(a)gmail.com> > To: Boost <boost(a)lists.boost.org> > Subject: Re: [boost] [Boost] [Describe] Summary Review Summary > Message-ID: > < > CAN5fK5H0Cr5OmaX2ryTjRcboLu8xqiv3eKuYdCaft6EZXKFh9Q(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Wed, Mar 24, 2021 at 7:35 AM Jeff Garland via Boost < > boost(a)lists.boost.org> wrote: > > > The committee seems to be concerned more with internal and external > > > politics than with serving the community. If that wasn't true there > would > > > be ZERO library additions that haven't been battle hardened by being > > > deployed and established themselves as the defacto standard already. > > > > Unlike the boost review where there's 'a decider', the committee uses > > consensus. It's a much higher bar, as frankly, it should be. > > A "much higher bar" can prevent a good library from being accepted or > prevent a bad library from being rejected. That is, consensus cuts both > ways. > > > As for battle hardened, sometimes it's not quite so simple as sometimes > > language changes are needed or vendor support is needed. Every proposal > > gets vetted for usage experience and it's clear that without experience > > it's unlikely to go forward. Is the process perfect -- no. Will it make > > everyone, even the members happy -- no. Can it be improved -- surely -- > > but like many things in life it's not as simple as we'd like. > > We can talk about the case when language changes are needed but let's focus > on libraries. > > > > The only thing they should be doing is rubber-stamping libraries that > are > > > already the standard for doing something. > > > > And if we 'just did that', things like generic programming wouldn't exist > > in c++. If the 'Roque Wave' container design was adopted in 1998 the > world > > would be very different now. > > There was no GitHub in 1998. Today it feels like some authors treat the > standard library as a vehicle for making their library available everywhere > in hopes it'll get adopted. All I'm saying is that adoption should come > before standardization. Git pull requests are better than Subversion > commits. > > > And if you want one of those 'battle hardened' libraries > > adopted, that's fine > > You see, I think it is problematic to "want" to standardize a library. IMO > the standardization process should be dull and boring, rather than driven > by exciting innovation. > > > ------------------------------ > > Message: 11 > Date: Fri, 26 Mar 2021 10:11:43 +0000 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: Boost mailing list <boost(a)lists.boost.org> > Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to > March 31, 2021 > Message-ID: > <CALnjya9TV+n=N-0_8zWsu_+zGTAW= > xezCsQ4C3vnBU6wZ6LkNw(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Fri, 26 Mar 2021 at 04:54, Andrzej Krzemienski via Boost > <boost(a)lists.boost.org> wrote: > > > > This is an interesting observation. In my experience, storing collections > > of ints is a rare case in production code (it is frequent in tests, > > tutorials, books, presentations), maybe this is why arithmetic operators > do > > not appear as something practical. > > They do appear frequently if you use column-oriented data structures, > which are generally better at dealing with large collections of data. > > > ------------------------------ > > Message: 12 > Date: Fri, 26 Mar 2021 10:16:17 +0000 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: Boost mailing list <boost(a)lists.boost.org> > Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22, > 2021 to March 31, 2021 > Message-ID: > < > CALnjya8bbeFs1d4q2pSbr8azU3aELbXVDtyCDtj+xioUDdkaEw(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Mon, 22 Mar 2021 at 02:35, Joel de Guzman via Boost > <boost(a)lists.boost.org> wrote: > > > > The Boost formal review of the Lambda2, authored by Peter Dimov, > > starts Monday, March 22, 2021 to March 31, 2021 (inclusive). > > > > Documentation: https://pdimov.github.io/lambda2/doc/html/lambda2.html > > Source: https://github.com/pdimov/lambda2/ > > > > Lambda2 is a simple, but functional, C++14 lambda library. It takes > advantage > > of the fact that the standard <functional> header already provides > placeholders > > _1, _2, _3, and so on, for use with std::bind, and function objects such > > as std::plus, std::greater, std::logical_not, and std::bit_xor, > corresponding to > > arithmetic, relational, logical and bitwise operators. > > > > Please provide in your review information you think is valuable to > > understand your choice to ACCEPT or REJECT including Lambda2 as a > > Boost library. Please be explicit about your decision (ACCEPT or REJECT). > > > > Some other questions you might want to consider answering: > > > > - What is your evaluation of the design? > > - What is your evaluation of the implementation? > > - What is your evaluation of the documentation? > > It is not clear from the documentation what the capture behaviour of > terminals is. > I assume it's capturing rvalues by value and lvalues by reference? > > What about the expression tree itself, is it fully by value, and > therefore safely copyable? > Boost.Proto for example by default is binding everything by reference, > meaning that you couldn't even store the expression in a variable. Is > it avoiding this issue? > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > ------------------------------ > > End of Boost Digest, Vol 6566, Issue 1 > ************************************** >

1 0

[GSoC] Boost.Real: Introduction and Guidence
by Suraj Nehra 28 Mar '21

28 Mar '21

Hi, I am Suraj Nehra, a pre-final year student at the National Institute of Technology (NIT), Warangal, India. This mail is to introduce myself to the boost community. Boost.Real is not added to boost project ideas page yet but I was discussing ideas with Vikram(vikram2000b(a)gmail.com) and also made several contributions to the library. I wish to work on this library in this GSoC and will start drafting the proposal. I received the competency task from Vikram and will start working on those. I was informed of the following potential ideas by him: 1. Library comparison and benchmarking with other similar libraries. 2. DAG internal representation 3. Propose and implement optimizations for trigonometric functions. I wish to work on ideas 1 and 3. I will start making the proposal for these ideas and share the draft with you. It will be a pleasure to hear any suggestions and guidance from you. Thanks & Regards Suraj Nehra

1 0

(no subject)
by Suraj Nehra 28 Mar '21

28 Mar '21

Hi, I am Suraj Nehra, a pre-final year student at the National Institute of Technology (NIT), Warangal, India. This mail is to introduce myself to the boost community. Boost.Real is not added to boost project ideas page yet but I was discussing ideas with Vikram(vikram2000b(a)gmail.com) and also made several contributions to the library. I wish to work on this library in this GSoC and will start drafting the proposal. I received the competency task from Vikram and will start working on those. I was informed of the following potential ideas by him: 1. Library comparison and benchmarking with other similar libraries. 2. DAG internal representation 3. Propose and implement optimizations for trigonometric functions. I wish to work on ideas 1 and 3. I will start making the proposal for these ideas and share the draft with you. It will be a pleasure to hear any suggestions and guidance from you. Thanks & Regards Suraj Nehra

1 0

To contact project's mentor for GSoC21
by prince raj 26 Mar '21

26 Mar '21

Hello, My self Anish Kumar Singh and I want to participate to in boost organisation. But I have no idea how to contact mentor for project discussion and my ideas with him. So please help me contacting to mentor so that I can make my proposal good to summit. Thankyou...

3 2

[Boost] [Describe] Summary Review Summary
by Richard Hodges 26 Mar '21

26 Mar '21

Boost Describe Review Summary Boost Describe was submitted by Peter Dimov. The review period lasted from 1st March 2021 until 10th March 2021, inclusive. Overall Verdict Boost.Describe has been accepted into Boost. Detailed Results In all, 13 people submitted reviews. Of these 13, 11 reviews were an unconditional ACCEPT. The remaining two reviews were marked CONDITIONAL ACCEPT. This seems to be common practice, as committing firmly to accept or reject can seem like a bold position either way. However the Boost review process has no provision for attaching conditions to library acceptance. The verdict must be either that the library is sufficiently well written and documented, as well as providing sufficient utility, to be included in the Boost offering, or it is not. Conditional Acceptances In this review I counted the two remaining conditional acceptances as ACCEPT, and decided to pass the conditions as comments/suggestions on to the author for consideration, as well as enumerate them in this report in the hope that further study/debate is stimulated. Libraries evolve over time, and the comments will no doubt be useful to Peter when making future decisions about Boost.Describe. I will deal with the conditions mentioned by Julain Blanc first. Julian’s concerns centered around the fact that the bitfield supplied to the describe_members macro is not additive. I will quote his example here. Given the following code: struct C { int a; std::string b; double c; void f(float a, int b) { } void g() { } static void s() {} private: int p_; void h_(std::string const& s) {} BOOST_DESCRIBE_CLASS(C, (), (a, b, c, f, g, s), (), (p_, h_)) }; I would expect the following: static_assert(mp_size<describe_members<C, mod_public>>::value == 6); static_assert(mp_size<describe_members<C, mod_private>>::value == 2); That's not the case. Instead, the results are resp 3 and 1. By default, only data members are returned, not member functions. So, let's try another one. I want all my member functions: static_assert(mp_size<describe_members<C, mod_function | mod_public | mod_protected | mod_private >>::value == 4) --> fails. By default, it only returns non-static functions. So, let's try to include static function as well: static_assert(mp_size<describe_members<C, mod_static | mod_function | mod_public | mod_protected | mod_private >>::value == 4) That also fails. The result is one, now i only get the static functions. It looks that there's a mix of apples and orange in this enum. Some values acts as they will include more data in the results, some on the contrary will filter, and some will change completely the type of the members enumerated. This concern resonates with me, as I raised a similar (but less well written) query with Peter in the same area. Barrett Adair was the author of the second conditional accept. His reasoning was along the same lines as Julian’s, quoted: I don't like that I need to call describe_members multiple times to get static, non-static, data, and functions. I would appreciate the addition of mod_data and mod_nonstatic to keep the flags consistent. This is my only acceptance condition. Peter took time to respond to this concern: The reason the static/nonstatic and data/function members are returned separately is that the type of `pointer` changes. For nonstatic data, it's M T::*. For static data, it's M*. For nonstatic function, it's R (T::*)(A...). For static function, it's R (*)(A...). Since one typically does things with `pointer` in the loop over members, it's rarely the case that you want all of these at once, because the syntactic form of the code manipulating them changes. So I've found it in practice more convenient to separate them by default. It is fair to say that in less recent variants of C++, iterating over different pointer types would be problematic, although arguably less so with later variants of C++ if some accessor function template overloads or CPOs were made available in the library. The decision on whether this should be explored rests with Peter. Documentation and Examples Reviewers almost universally commented on the quality and completeness of the documentation. Particular attention was drawn to the numerous examples that clearly represent common real-world use cases. Features Requested Rainer Deyke requested the ability to annotate members with further attributes. Peter responded that he would look into whether this was possible while retaining compatibility with likely future standards adoptions of reflection, which is a design goal of the library. Maximilian Riemensberger wondered whether it would be possible to support reference members and overloaded functions. Peter’s response was that alas, no. The language itself is a limiting factor there. Maximilian also requested the ability to annotate enums with associated data. For example, representing an enum value as text when the text cannot be reasonably computed from the value’s symbolic name. Peter agreed to consider this further. Maximilian also touched on the single-pass iteration issue, which brings the number of observers who feel there is good grounds for future evolution to four. Overall Usefulness of the Library The reviewers were unanimous in calling out the need for this kind of library. From reading the reviews it is apparent that a great deal of developer effort is duplicated in writing custom reflection mechanisms. It struck me that (any kind of) language-level compile-time reflection would be welcomed with open arms by the developer community. Perhaps we can hope that the acceptance of Describe into Boost and its subsequent use can inform and encourage the C++ language group to bring something to the community sooner than later. Please join me in extending gratitude to Peter, who has taken time and painstaking effort to present us with such a useful, succinct and well documented library. Please also join me in thanking the reviewers, who can be sure that the detailed analysis included has been read and in for the most part, already elicited a response/bug-fix from Peter. Sincerely, Richard Hodges -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 mobile: +376380212

12 31

C++17 and "Alice in Wonderland"
by Edward Diener 24 Mar '21

24 Mar '21

I apologize for this non-Boost related post, but I ran into what I thought was a C++17 bug in clang ( also in vc++14.2 C++17 ), whose explanation to me of why it is not a bug really sounds like the non-logic of "Alice in Wonderland". I am not putting down the person who explains to me why it is not a bug in any way, as I know he is a C++ expert, but if this is really C++17 something must be wrong with my admittedly limited understanding of C++ and where it is going. My bug report is at https://bugs.llvm.org/show_bug.cgi?id=49684 and the explanation given there just eludes me as to what C++17 is doing, as my further comments makes apparent. Does anyone actually understand how this can possibly be ? How does C++17 apparently deduce a template argument different from what the actual type is and than declare therefore a mismatch ? This is really something from another world. My apologies for bringing this up in Boost, as it is purely a C++ issue, but my original problem comes from something I have been working on in the hopes it might eventually be a Boost library, so I decided to see if any of the expert Boost contributors might know what is going on in C++17. I realize that if everyone did as I have done here the mailing list would be a mass of irrelevant posts not Boost related.

9 11

Boost 1.76 beta - linking error when including Boost
by Luigi Ballabio 24 Mar '21

24 Mar '21

Hello, I'm afraid I don't have a minimal example yet, but I thought I'd give you a heads-up in case it rings a bell. I've been trying the Boost 1.76 beta to build a library I'm maintaining. The library builds, but when I link it to an executable I'm getting an "undefined reference to `bool boost::math::isnan<long double>(long double)". Everything works with 1.75 and earlier. My code is not using boost::math::isnan directly, so I'm guessing some other included boost component is forward-declaring it or doing something similar? The linking error disappears if I include <boost/math/special_functions/fpclassify.hpp> in a config file that is included by every file in the library. Today I'll try to pinpoint the problem by removing it there and including it before specific boost headers in the source files, but as I said, I'm posting this in case someone already has an idea about the underlying issue. Thanks, Luigi

3 4

Any Interest in a port of ZLib to C++?
by Vinnie Falco 24 Mar '21

24 Mar '21

Beast currently has its own port of ZLib to C++: <https://github.com/boostorg/beast/tree/develop/include/boost/beast/zlib> Is there any interest in having this proposed as its own separate Boost library (with a separate review, which has nothing to do with Beast)? The differences would be as follows: * Ported to use C++11 idioms * Same header-only / compiled source model as Boost.JSON * Better documentation and clear API * Improved tests Programs which use this C++ port of ZLib would get their zlib dependency from Boost instead of the official zlib distribution. And they can integrate it into their projects the same way that Boost libraries are integrated. Or they can include <boost/zlib/src.hpp> in any one translation unit (like JSON). The motivation for this is twofold: * Provide an easier way for users to access ZLib's functionality * To use this in some new libraries that I'm going to propose -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

11 14

[Boost.JSON] Security Review
by Vinnie Falco 24 Mar '21

24 Mar '21

As part of our commitment to producing the very finest C++ libraries that application developers can trust, the C++ Alliance has commissioned Bishop Fox to perform a security audit of the Boost.JSON library. The report is linked here: <https://cppalliance.org/pdf/C%20Plus%20Plus%20Alliance%20-%20Boost%20JSON%2…> This will report will be published starting in Boost 1.76.0 -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

boost library incubator planning shutdown
by Robert Ramey 22 Mar '21

22 Mar '21

I had high hopes for the boost library incubator when I made it. But I think it's pretty clear that those hopes haven't been realized. Maintaining and Enhancing this website required more effort than I had anticipated so it hasn't evolved. I do notice that people do use it from time to time (a couple hundred page hits/day), so it's not totally dead. But it would either have to go forward or be shut down. If someone wanted to take it over that would be fine. But I don't expect anyone to come forward so I'll be shutting it down probably in the next 30 days or so. Robert Ramey

1 0

Mentor application for Boost.Real
by Vikram Chundawat 21 Mar '21

21 Mar '21

Hello everyone, I am Vikram Singh Chundawat, I worked on Boost.Real previous GSoC and I am actively working on the library since. Now, one of the potential mentors Damian Vicino is not mentoring this year, I wish to mentor this project in GSoC 2021 with Laouen Belloli. We have some potential candidates who are working on the library and also some good ideas for the library. The aim last year was to bring Boost.Real to review ready state and some work is still remaining to make it review ready, we found some bugs in the review. Now, we are working on optimizations, bug fixes, and benchmarking. I went through the guidelines of Google and wish to know the procedure for mentor application. Thank You Regards Vikram Singh Chundawat

2 1

Proposing a library to include in Boost
by Mohit Saini 20 Mar '21

20 Mar '21

Hi, This is Mohit Saini. I developed a lazy_map library, whose interface is similar to std::unordered_map but lazy_map is O(1) copiable. Other operations like Deletion, Lookup, Insertion etc. continue to cost O(1).. which also implies that lazy_map is not a simple cow_wrapper<std::unordered_map> .. lazy_map is way more clever than that. Learn more at : https://github.com/tinytrashbin/lazy_map Specially, checkout the section which explains the "Fragment" tree. Lazy_map is heavily used in our codebase for taking snapshot of a very large state ( of size ~ 5 GBs), enabling "fork" of a snapshot in O(1) time for further modification in the forked snapshot, allowing a large number of threads to operate on different snapshots of very large size, concurrently without interfering with each other where each of the thread is even "writing" to their snapshot. I believe such a utility will be very helpful for others too. I'm looking for boost-maintainers who can review and suggest what all I need to do so that lazy_map can be accepted in Boost. Thanks -- Mohit Saini

1 0

Re: [boost] Feedback on GSoC'21 project proposal
by krushnalpatel11＠gmail.com 20 Mar '21

20 Mar '21

I have updated the proposal with the changes you proposed. Please check if all things are updated as per your feedback. https://docs.google.com/document/d/1Bvno6ifHjo8EdMRuzFqCk9AEB5IgAxf2ag4xdc4… Krushnal http://krushnal.me/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost </quote> Quoted from: http://boost.2283326.n4.nabble.com/Feedback-on-GSoC-21-project-proposal-tp4… _____________________________________ Sent from http://boost.2283326.n4.nabble.com

1 0

Re: [boost] Boost website changes and .'cxxstd'
by Donovan Dikaio 20 Mar '21

20 Mar '21

I can look into it. But needs to make the requirements clear. So, the task is to show *C++ standard minimum level: C++nn* for Standard attribute for each lib in this page: C++ standard minimum level: C++nn ? And we could replace nn with the actual number by checking the *cxxstd* key in a library's meta info json file. Please let me know if I got it right. On Fri, Dec 25, 2020 at 10:00 AM Louis Tatta <louis(a)cppalliance.org> wrote: > > > ---------- Forwarded message --------- > From: Edward Diener via Boost <boost(a)lists.boost.org> > Date: Wed, Dec 23, 2020 at 7:39 PM > Subject: [boost] Boost website changes and .'cxxstd' > To: <boost(a)lists.boost.org> > CC: Edward Diener <eldiener(a)tropicsoft.com> > > > Even though I have worked a little with PHP in the past I do not have > the talent to make the change to the website which would incorporate the > addition of the meta information json field 'cxxstd' to the Boost > documentation web page for each library. The idea is that if 'cxxstd' is > set to a value the documentation for that library would also show: > > C++ standard minimum level: C++nn > > where nn would be 11, 14, 17, or 20 depending on the value of 'cxxstd'. > Alternatively if there is no 'cxxstd' entry for a library or if the > value of 'cxxstd' is '03', we could either specify 'nn' as '03' or leave > off the line stating the 'C++ standard minimum level completely. > > On the face of it this should be doable in the website code but > evidently Daniel James is the only one who really understands how this > works in the code and he is no longer active in Boost. So if someone > else who understands the website code and PHP could do this it would be > appreciated, since I think it will be valuable telling end-users whether > a Boost library is usable at the C++ compiler level they are using. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

8 43

Providing a link to GitHub commit from documentation
by pbristow＠hetp.u-net.com 20 Mar '21

20 Mar '21

I've been considering adding commit hash info to some documentation made using the Quickbook/Boostbook/Docbook/b2/bjam toolchain Using git command line git log or ls-remote I can show the necessary hex digit string: commit 5609fa86e37e1b0eae6466065ba6c8eb3ac0ab2f (HEAD -> refactor1) (It would be useful to have the local commit (rather than remote) so that the generated documentation including this has can be pushed up to remote). Paul@hetpD MINGW64 /i/boost/libs/quan/doc (refactor1) $ git log -n1 HEAD > commit.txt That contains commit 5609fa86e37e1b0eae6466065ba6c8eb3ac0ab2f Author: pabristow <pbristow(a)hetp.u-net.com> Date: Fri Mar 19 15:46:45 2021 +0000 Generated super new version. So this gets this info into a file, but I have yet to see how to get this into the Quickbook or ? during the b2 build. I note that the Boost documentation headers provide this information in the form a link like displayed as d57d645009 with contents https://github.com/boostorg/boost/commit/d57d6450098300343c6fe3a22129791524… but I don't know how this works. Has anyone done anything like this? Suggestions most welcome. Paul

4 4

Feedback on GSoC'21 project proposal
by Krushnal Patel 19 Mar '21

19 Mar '21

Hi, I am applying for the project Boost.XML. I have completed the competency test and the next step being proposal feedback from mentors, I have made a draft proposal. https://docs.google.com/document/d/1Bvno6ifHjo8EdMRuzFqCk9AEB5IgAxf2ag4xdc4… As this is a new library, I have not been able to add much in the 'Project Proposal' details except the bare minimum details. Mentors please have a look at it and let me know what you think. Should I make additions, remove or edit some things? -- Awaiting your feedback, Krushnal Patel http://krushnal.me/

2 1

(no subject)
by Sakshi Singh 19 Mar '21

19 Mar '21

Hello Sir/Mam I'm Sakshi Singh Dangi from India l'm interested in one of your project bit I don't know what to do regarding application process please guide me.

1 0

[GSoC'21] Boost.Math : FFT Utilities PROJECT 1 Guidance
by Tushar k 19 Mar '21

19 Mar '21

Hello, I am Tushar Khandelwal from BITS Pilani 2019 batch, I am working with C++ for the past 2 years so I have a decent understanding of C++. In the past few days, I went through different boost libraries and different project ideas. So, I liked one of the projects of Boost.Math library: FFT Utilities, I have studied Fast Fourier Transform a few months back in my university course signals and system, also I have read many different articles and videos related to this beautiful concept. I have some doubts related to it like what exactly are your expectations from this project? how should I proceed? So I request a potential mentor of this project Christopher Kormanyos or others to please guide me. thanks! Looking forward to this open-source project in GSoC'21. With regards Tushar Khandelwal

3 2

Re: [boost] [release] 1.76.0 post-beta merges
by Glen Fernandes 18 Mar '21

18 Mar '21

John Maddock wrote: > I've had a request to merge these new Boost.Config feature > checks to release as Serialization depends on them: > https://github.com/boostorg/config/pull/369 > Also related to Serialization, this bugfix for BOOST_HAS_HASH should > probably go in: https://github.com/boostorg/config/pull/374. OK to merge both. Glen

1 0

[asio] [regex] 1.76.0 beta 1 compilation failure
by Scott Determan 18 Mar '21

18 Mar '21

There appears to be a problem compiling a program that includes both asio and regex in 1.76.0 beta 1. The following program fails to compile: ``` #include <boost/asio.hpp> #include <boost/regex.hpp> int main(int argc, char** argv) { return 0; } ``` The error is: ``` /home/swd/projs/common/boost_1_76_0_b1/boost/regex/v5/match_flags.hpp:38:14: error: multiple definition of ‘enum boost::regex_constants::_match_flags’ 38 | typedef enum _match_flags | ^~~~~~~~~~~~ In file included from /home/swd/projs/common/boost_1_76_0_b1/boost/asio/detail/regex_fwd.hpp:21, from /home/swd/projs/common/boost_1_76_0_b1/boost/asio/read_until.hpp:23, from /home/swd/projs/common/boost_1_76_0_b1/boost/asio.hpp:146, from ../src/main.cpp:2: /home/swd/projs/common/boost_1_76_0_b1/boost/regex/v4/match_flags.hpp:38:14: note: previous definition here 38 | typedef enum _match_flags ```

4 4

(GSoC '21) uBlas Project 2/3 Guidance
by Laxman 18 Mar '21

18 Mar '21

Hi, I, Laxman Desai, am interested in ublas Project 2 and 3. I’ve built a few C++ libraries before (for personal use) and I am familiar with C++17, MATLAB, TensorFlow, NumPy and Pandas to a good extent. I am currently learning R. I also have a good mathematical background, especially in Linear Algebra. I have currently completed the Competency Test for uBlas, and would request the mentors: David Bellot, Cem Bassoy or Amit Singh to guide me further for Project 2: creating new matrix and vector types and Project 3: Finalize Dataframe Implementation. Project 2: I dont understand what experimental templates and ublas::experimental::matrix means. I although have a strong feeling that it just refers to the tensor implementation of the same. I haven’t used uBlas tensor_core before, so could a mentor explain further (a basic intuition of the improvement, and the workflow for this project)? I would also appreciate more information on submatrix, and its implementation! To my understanding, it is to solve the problem that C++ doesn’t allow overloading of the colon operator. Project 3: I also am interested in project 3 (Finalising the DataFrames Implementation), and am currently exploring the available features. I have been using Pandas for a while now, and recently learnt R. “Finalize and productionize” seemed a bit vague to me, could I get more information on what all the current implementation is lacking (except for documentation)? I would also like to know if the mentors have a shortlist of features to add in mind? Any feedback on this would be greatly appreciated. Kind Regards, Laxman Desai Mail: desai.laxman2001(a)gmail.com

1 0

SVN/Trac account settings not accessible
by Andrey Semashev 18 Mar '21

18 Mar '21

Hi, It looks like SVN/Trac manager is no longer working. Is there a way to change account password?

1 1

Remove obsolete Coding Guidelines for Integral Constant Expressions
by Nikita Kniazev 17 Mar '21

17 Mar '21

Boost Library Requirements and Guidelines has a page https://www.boost.org/development/int_const_guidelines.html which contains highly outdated information. I think the guideline no longer applies and should be simply removed.

1 0

[GSoC'21] Seeking Further Guidance for Project3:Finalize Dataframe Implementation (Boost.uBlas: Matrix and Tensor Computations)
by Kowndinya Renduchintala 17 Mar '21

17 Mar '21

Hi Community! I am Kowndinya Renduchintala, a Second Year Undergraduate majoring in Computer Science and Engineering at Indian Institute of Technology Bombay. I am completely new to Open Source Software Development. Having worked on C++ extensively for the last two years of my Undergraduate studies, I consider myself a proficient C++ programmer. I also had a great amount of exposure in Math, specifically in Linear Algebra and Calculus. This led me to do more work related to them and I started working in the field Data Science where I have largely used Python’s numpy and pandas libraries, also MATLAB in some cases. I am very much interested in developing equivalent capabilities of above mentioned libraries in C++ too! I have gone through the Project Description on the GSoC’21 Ideas Page, and I am highly delighted to see that “Project:3 Finalize Dataframe Implementation” (in Matrix and Tensor Computation category), matches my interests to a very large extent. I am also ready to spend 40-50 hours per week for the completion of the project, thereby helping in productionizing the code by the end of the GSoC’21. But I have some questions left out in my mind after reading the “Project Description” and the “Competency Test” following it. The description says- “add a collection of free form functions, modern data analysis procedures (as found in R tidyverse, in Python pandas/numpy, and in many other packages)”. 1. Do the mentor(s) have some preconceived “list” of the sort of functions to be implemented, or am I expected to include the details of “my” ideas in the project proposal that I submit to Google starting from Mar29 to Apr13? 2. Is the Competency Test(providing matrix and vector C++17 implementation similar to MATLAB syntax) meant for giving us a taste for how the work in actual project is going to look like? If it is the case, then I am highly interested to work on such things/ similar things for that matter. I request David Bellot(The Potential Mentor as per the Wiki page) or any one else who is involved with the above project to please guide me further. After clarifying above two questions, I can straight away get into business and start the work, try to make a list of deliverables and probably ask more “technical” questions that I have in the code base, in my next mail. Looking forward to collaborate with Boost.uBlas and successfully complete my first Open Source Software Development project at GSoC’21 in my most favourite programming language!!! Regards Kowndinya Renduchintala rharisrikowndinya333(a)gmail.com Sent from [1]Mail for Windows 10 References 1. https://go.microsoft.com/fwlink/?LinkId=550986

1 0

[sort] How does pdq-sort allocated memory?
by Viktor Sehr 17 Mar '21

17 Mar '21

According to the documentation boost::pdq_sort uses Log N additional memory. Assuming this memory is allocated via new, is it possible to pass an allocator, or even better, a pre-reserved std::vector<T> to the algorithm in order to avoid allocation? I could not find anything in the documentation about this. /VIktor

1 0