New subject: 14 to contact for introduction and guidance with gsoc mentor.

28 Mar 2021


      Sir/madam I does not have that great idea regarding Gsoc ,so firstly I want
to know what about it exactly and how to apply and do project,and even
about the eligibility ,I am ok with c++ programming. Is it enough ,these
are my queries regarding gsoc.

On Sun, 28 Mar, 2021, 7:20 pm ,  wrote:
...
Send Boost mailing list submissions to
        boost@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@lists.boost.org
You can reach the person managing the list at
        boost-owner@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 (Peter Dimov)
   2. Re: [Lambda2] Review starts Monday March 22, 2021 to March
      31, 2021 (Peter Dimov)
   3. To contact project's mentor for GSoC21 (prince raj)
   4. Re: To contact project's mentor for GSoC21
      (Vin?cius dos Santos Oliveira)
   5. Re: To contact project's mentor for GSoC21 (Mateusz Loskot)
   6. Re: [Lambda2] Review starts Monday March 22, 2021 to March
      31, 2021 (Christian Mazakas)
   7. Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to
      March 31, 2021 (Emil Dotchevski)
   8. Re: [Lambda2] Review starts Monday March 22,      2021 to March
      31, 2021 (Phil Endecott)
   9. Re: [Lambda2] Review starts Monday March 22, 2021 to March
      31, 2021 (Peter Dimov)
  10. [Boost][GIL][GSOC 2021] Contribute to the library
      (sayan chaudhuri)
  11. (no subject) (Suraj Nehra)
  12. [GSoC] Boost.Real: Introduction and Guidence (Suraj Nehra)
  13. Changelog for 1.76 is outdated (Antony Polukhin)
  14. Re: Changelog for 1.76 is outdated (Antony Polukhin)
  15. Re: Boost Digest, Vol 6566, Issue 1 (shady mohamed)
----------------------------------------------------------------------
Message: 1
Date: Fri, 26 Mar 2021 14:10:43 +0200
From: "Peter Dimov" 
To: 
Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22,
        2021 to March 31, 2021
Message-ID: <144201d72239$0c182c30$24488490$@gmail.com>
Content-Type: text/plain;       charset="utf-8"
Mathias Gaunard wrote:
...
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?
The capture behavior is inherited from std::bind, which captures
everything by value by default unless overridden with std::ref.
------------------------------
Message: 2
Date: Fri, 26 Mar 2021 14:19:24 +0200
From: "Peter Dimov" 
To: 
Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
        March 31, 2021
Message-ID: <144401d7223a$42e76ef0$c8b64cd0$@gmail.com>
Content-Type: text/plain;       charset="utf-8"
Andrzej Krzemienski wrote:
...
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.
I'll add the shift operators and the unary * at minimum, will see about any
others. The current set is determined by the function objects in
<functional>.
------------------------------
Message: 3
Date: Fri, 26 Mar 2021 20:50:52 +0530
From: prince raj 
To: "boost@lists.boost.org" 
Subject: [boost] To contact project's mentor for GSoC21
Message-ID: 
Content-Type: text/plain; charset="utf-8"
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...
------------------------------
Message: 4
Date: Fri, 26 Mar 2021 12:46:26 -0300
From: Vin?cius dos Santos Oliveira 
To: Boost 
Cc: prince raj 
Subject: Re: [boost] To contact project's mentor for GSoC21
Message-ID:
        <
CAK9RveLeh66nHX-ZBRpPs4mP+fDZ5JjwN3beVVRd8X0dnHCvRA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Em sex., 26 de mar. de 2021 ?s 12:22, prince raj via Boost <
boost@lists.boost.org> escreveu:
...
But I have no idea how to contact mentor for project discussion and my
   ideas with him.
What's the project you're interested in?
--
Vin?cius dos Santos Oliveira
https://vinipsmaker.github.io/
------------------------------
Message: 5
Date: Fri, 26 Mar 2021 17:32:14 +0100
From: Mateusz Loskot 
To: boost@lists.boost.org
Subject: Re: [boost] To contact project's mentor for GSoC21
Message-ID:
        <
CABUeae8fsFiX6CS6_HXH-u59_GQJscbEdEJEZ-W0naq_WJRHiA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Fri, 26 Mar 2021 at 16:22, prince raj via Boost
 wrote:
...
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.
First, read this and the materials linked there
https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-Overview
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
------------------------------
Message: 6
Date: Fri, 26 Mar 2021 19:45:39 -0700
From: Christian Mazakas 
To: "boost@lists.boost.org List" 
Cc: Peter Dimov 
Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
        March 31, 2021
Message-ID:
        <
CAHf7xWsqNHEt8-nxBRFz1+BjNMiwXasoYsFOuFR+tpd2EWZkog@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hey everyone,
I vote to *ACCEPT *Lambda2.
I first heard of Lambda2 when Peter asked me how many lines I thought
it would take to recreate Boost.Lambda.
Naturally, I should've seen this as a loaded question but I guessed a few
hundred. Maybe something just below a couple thousand by the time all
the dust settles.
Peter told me it could be done in ~50 lines. Now I was intrigued. The
source code of
Lambda2 is wonderfully clever and short. Moreso, sufficiently clever that
it's worth
not repeating every time we want to use it.
Higher-order functions are all the rage in C++ and writing lambdas is
cumbersome
and annoying. Lambda2 gives us a C++14 solution that relies on nothing else
but
simple language features and stdlib headers making it faster to compile
than older
solutions such as Phoenix or the original Lambda.
Lambda2 also has the fortune of interop'ing greatly with existing
constructs like
Boost.HOF and the new `<ranges>` STL header. See:
https://godbolt.org/z/hfxfhfEqv
Keeping this short, Lambda2 gives us fresh paint over an old technology
that we know
works and one that (while polarizing in its style) does its job well. I
think it ultimately
serves Boost and the larger C++ community to keep this Lambda-style of
coding alive
and well-maintained as C++ evolves.
- Christian
------------------------------
Message: 7
Date: Fri, 26 Mar 2021 23:18:47 -0700
From: Emil Dotchevski 
To: Boost 
Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22,
        2021 to March 31, 2021
Message-ID:
        
Content-Type: text/plain; charset="UTF-8"
Here is my review of lambda2:
I remember when I first learned boost::bind, and realized how much more
useful STL is because of it. Even after C++11 I still find myself using
bind, it sometimes looks more readable to my eyes than a lambda.
The lambda2 library is one more proof for the solid design behind
std::bind. That, or std::bind was designed with things like lambda2 in
mind. Either way, lambda2 is an elegant utility for writing elegant C++,
albeit only in the (rare?) cases when it is a perfect fit. Given this, and
the miniature size of the library, my vote is to ACCEPT.
------------------------------
Message: 8
Date: Sat, 27 Mar 2021 17:42:36 +0000
From: "Phil Endecott" 
To: 
Subject: Re: [boost] [Lambda2] Review starts Monday March 22,   2021 to
        March   31, 2021
Message-ID: <1616866956454@dmwebmail.dmwebmail.chezphil.org>
Content-Type: text/plain; format="flowed"; charset="UTF-8"
Peter Dimov wrote:
...
The goals of the library are
[...]
- Prepare a proposal to extend the standard with these same additions by
  gathering experience in Boost first.
Am I correct in thinking that this functionality could have been
added to the standard library when std::bind was added in C++11,
except that it requires something in the core language that was not
added until C++14 ?
If not, what is the reason why this was not added when std::bind
was added? (I've failed to locate any pre-C++11 WG21 papers about
std::bind.)
Regards, Phil.
------------------------------
Message: 9
Date: Sat, 27 Mar 2021 19:58:03 +0200
From: "Peter Dimov" 
To: 
Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
        March   31, 2021
Message-ID: <14fe01d72332$bc76fad0$3564f070$@gmail.com>
Content-Type: text/plain;       charset="utf-8"
Phil Endecott wrote:
...
Peter Dimov wrote:
...
The goals of the library are
[...]
- Prepare a proposal to extend the standard with these same additions
by
  gathering experience in Boost first.
Am I correct in thinking that this functionality could have been added
to the
standard library when std::bind was added in C++11, except that it
requires
something in the core language that was not added until C++14 ?
Return type deduction makes it easier to write, and the function objects in
<functional> acquired their <void> forms in C++14, but it's possible to
make
this work in C++11 as well.
...
If not, what is the reason why this was not added when std::bind was
added?
(I've failed to locate any pre-C++11 WG21 papers about std::bind.)
I didn't propose it. :-)
------------------------------
Message: 10
Date: Sat, 27 Mar 2021 22:38:36 +0530
From: sayan chaudhuri 
To: boost@lists.boost.org
Subject: [boost] [Boost][GIL][GSOC 2021] Contribute to the library
Message-ID:
        
Content-Type: text/plain; charset="UTF-8"
Hello Everyone,
                        My name is Sayan Chaudhuri. I am a final
year,undergraduate student,in the Computer Science and Engineering
department of IEM,India . I am eager to participate in the GSOC 2021 and
willing to contribute to the Boost GIL library.
                         I have already gone through the wiki list of Boost
GIL listing the various image processing and computer vision algorithms
that have not been implemented yet. I have also gone through the
Contributing documents for BOOST GIL. . While going through the Boost
Mailing List Archives, I found that Igor Antropov had suggested to develop
ORB descriptor during his GSOC tenure but it has not been implemented yet..
I am therefore eager to develop the ORB descriptor for Boost GIL during
GSOC 2021. ORB is useful in many situations like object recognition and
structure for motion and also it is suitable for real time applications
unlike SIFT and SURF. I also found out that while using Boost , everytime I
need to see the output , I need to save the output in order to view
it,thereby unnecessarily wasting memory when I do not wish to save the
output.  So, the functionality of imshow() for OPENCV is missing for Boost
GIL. I am also eager to work on that functionality as well during GSOC
2021. Would therefore anyone is interested in mentoring me?
                         As my programming competency test for Boost GIL, I
have implemented the KMeans algorithm from scratch using Boost GIL and I
have raised a pull request- https://github.com/boostorg/gil/pull/587. I
would kindly request if someone can kindly review it. Also, I would like to
know whether there are any similar issues  that I can work on currently.
------------------------------
Message: 11
Date: Sun, 28 Mar 2021 03:22:35 +0000
From: Suraj Nehra 
To: boost@lists.boost.org
Subject: [boost] (no subject)
Message-ID:
        
Content-Type: text/plain; charset="UTF-8"
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@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
------------------------------
Message: 12
Date: Sun, 28 Mar 2021 03:30:54 +0000
From: Suraj Nehra 
To: boost@lists.boost.org
Subject: [boost] [GSoC] Boost.Real: Introduction and Guidence
Message-ID:
        <
CAJR02Fe4w-FfDcjDK4NfLs1LNqBwThi5uxF-nhefMo6NhrSSkw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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@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
------------------------------
Message: 13
Date: Sun, 28 Mar 2021 09:54:11 +0300
From: Antony Polukhin 
To: "boost@lists.boost.org List" 
Subject: [boost] Changelog for 1.76 is outdated
Message-ID:
        <
CAKqmYPazb_JKWwwy-DZGdpfseJ4wB0KXR3FsK22o-nZ0w6G+0Q@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
The https://www.boost.org/users/history/version_1_76_0.html seems quite
outdated. Please update
Thanks in advance!
------------------------------
Message: 14
Date: Sun, 28 Mar 2021 09:56:43 +0300
From: Antony Polukhin 
To: "boost@lists.boost.org List" 
Subject: Re: [boost] Changelog for 1.76 is outdated
Message-ID:
        
Content-Type: text/plain; charset="UTF-8"
By "outdated" I mean that
https://github.com/boostorg/website/blob/master/feed/history/boost_1_76_0.qb...
has more info
------------------------------
Message: 15
Date: Sun, 28 Mar 2021 15:05:07 +0200
From: shady mohamed 
To: boost@lists.boost.org
Subject: Re: [boost] Boost Digest, Vol 6566, Issue 1
Message-ID:
        <
CAPwR5ipUjbt4R5E_W4qO3wvfkm7NfmiT1Q99AhMwWvGxTUyk2A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
I want to talk with engineer david bellot and engineer cem bassoy
Thanks
?? ??????? ?? ????? ???? ??:?? ?  ???:
...
Send Boost mailing list submissions to
        boost@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@lists.boost.org
You can reach the person managing the list at
        boost-owner@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 
To: Boost mailing list 
Cc: Peter Dimov 
Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22,
        2021 to March 31, 2021
Message-ID:
        
Content-Type: text/plain; charset="UTF-8"
pon., 22 mar 2021 o 16:44 Peter Dimov via Boost 
napisa?(a):
...
...
My first reaction, after quickly looking at the submission, is what
does
...
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
Edward Diener wrote:
this
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 
To: boost@lists.boost.org
Subject: Re: [boost] [release] 1.76.0 post-beta merges
Message-ID: <6efb04af-9f26-4d04-a187-8bc08369caf3@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
...
please.
Niall
------------------------------
Message: 3
Date: Thu, 25 Mar 2021 17:24:15 +0200
From: "Peter Dimov" 
To: "'Andrzej Krzemienski'" ,       "'Boost mailing
        list'" 
Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22,
        2021 to March 31, 2021
Message-ID: <131601d7218a$eb1033b0$c1309b10$@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
https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L3...
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 
To: Boost Developers List 
Subject: Re: [boost] [release] 1.76.0 post-beta merges
Message-ID: <0EAF569D-A080-4217-BC77-D7CE4057EC0A@gmail.com>
Content-Type: text/plain;       charset=utf-8
On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost <
boost@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#L3...
...
...
please.
Do you have a commit that fixes this?
? Marshall
------------------------------
Message: 5
Date: Thu, 25 Mar 2021 16:04:17 +0000
From: Niall Douglas 
To: Boost Developers List 
Subject: Re: [boost] [release] 1.76.0 post-beta merges
Message-ID: <2dc9222a-592a-6b85-c76b-d62ef55611b3@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@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#L3...
...
...
...
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 
To: boost@lists.boost.org
Subject: Re: [boost] [release] 1.76.0 post-beta merges
Message-ID:
        
Content-Type: text/plain; charset="UTF-8"
On Thu, Mar 25, 2021 at 12:04 PM Niall Douglas via Boost
 wrote:
...
On 25/03/2021 15:45, Marshall Clow wrote:
...
On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost <
boost@lists.boost.org> wrote:
...
...
...
I would like to fix https://github.com/ned14/outcome/issues/249 by
improving the logic at
...
...
...
...
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 
To: boost@lists.boost.org
Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
        March 31, 2021
Message-ID: <2773cbf43ec651fdf2b3a3262c8476d814047eb0.camel@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. 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 
To: Boost mailing list 
Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
        March 31, 2021
Message-ID:
        
Content-Type: text/plain; charset="UTF-8"
czw., 25 mar 2021 o 19:11 Julien Blanc via Boost 
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. 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 
To: boost@lists.boost.org
Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
        March 31, 2021
Message-ID: <54d581dd2987773250b0f822393ea819a03297bc.camel@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 
To: Boost 
Subject: Re: [boost] [Boost] [Describe] Summary Review Summary
Message-ID:
        <
CAN5fK5H0Cr5OmaX2ryTjRcboLu8xqiv3eKuYdCaft6EZXKFh9Q@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Wed, Mar 24, 2021 at 7:35 AM Jeff Garland via Boost <
boost@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
https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L3...
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 
To: Boost mailing list 
Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
        March 31, 2021
Message-ID:
        
Content-Type: text/plain; charset="UTF-8"
On Fri, 26 Mar 2021 at 04:54, Andrzej Krzemienski via Boost
 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@ens-lyon.org>
> To: Boost mailing list <boost@lists.boost.org>
> Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22,
>         2021 to March 31, 2021
> Message-ID:
>         <
> CALnjya8bbeFs1d4q2pSbr8azU3aELbXVDtyCDtj+xioUDdkaEw@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Mon, 22 Mar 2021 at 02:35, Joel de Guzman via Boost
> <boost@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 &amp; other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
> ------------------------------
>
> End of Boost Digest, Vol 6566, Issue 1
> **************************************
>
------------------------------
Subject: Digest Footer
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
------------------------------
End of Boost Digest, Vol 6567, Issue 1
**************************************

Re: [boost] 14 to contact for introduction and guidance with gsoc mentor.

Chandana Gubba

Mateusz Loskot

tags

participants (2)