Send hpx-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hpx-devel digest..."
Today's Topics:
1. Re: [VOTE] pragma once (Hartmut Kaiser)
2. Re: [VOTE] pragma once (Bryce Adelstein Lelbach aka wash)
----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Apr 2020 08:45:39 -0500
From: "Hartmut Kaiser" <[email protected]>
Subject: Re: [hpx-devel] [VOTE] pragma once
To: <[email protected]>
Message-ID: <[email protected]>
-0 (weakly against, but not opposing majority decision)
Regards Hartmut
---------------
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx
> -----Original Message-----
> From: [email protected] <hpx-devel-bounces@stellar-
> group.org> On Behalf Of Simberg Mikael
> Sent: Friday, April 3, 2020 2:20 AM
> To: [email protected]
> Subject: [hpx-devel] [VOTE] pragma once
>
> I proposed to change our header guards to use pragma once in
> https://github.com/STEllAR-GROUP/hpx/pull/4474. Since this turned out to
> be a contentious topic, we're turning to our newly created
> http://hpx.stellar-group.org/documents/governance/, which states:
>
> When is a vote required?
>
> Every effort is made to allow the majority of decisions to be taken
> through lazy consensus. That is, simply stating one's intentions is
> assumed to be enough to proceed, unless an objection is raised. However,
> some activities require a more formal approval process in order to ensure
> fully transparent decision making.
>
> - ...
> - Feature proposal: When a significant addition or removal is proposed to
> the codebase - Concensus approval of the PMC
> - ...
>
> I think feature proposal fits this topic best, even though it's not
> directly a feature exposed to users. It does say "concensus approval of
> the PMC", but we will absolutely take non-PMC votes into consideration as
> well.
>
> I suggest everyone interested in having a say in this read the section on
> voting in the governance document, but I'll paste the summary here:
>
> If a formal vote on a proposal is called (signaled simply by sending a
> email with [VOTE] in the subject line), all participants on the HPX user's
> mailing list may express an opinion and vote. They do this by sending an
> email in reply to the original [VOTE] email, with the following vote and
> information:
>
> - +1: 'yes', 'agree': also willing to help bring about the proposed action
> - +0: 'yes', 'agree': not willing or able to help bring about the proposed
> action
> - -0: 'no', 'disagree': but will not oppose the action's going forward
> - -1: 'no', 'disagree': opposes the action's going forward and must
> propose an alternative action to address the issue (or a justification for
> not addressing the issue)
>
> Just to make the voting clear, agreeing means agreeing to use pragma once,
> disagreeing means sticking with the header guards we have.
>
> I'll start with +1 for the following reasons:
>
> - Pragma once avoids mistakes by avoiding having to come up with a unique
> name for the header.
> - It only has to be specified in one place in the header file.
> - It's simpler to enforce that all headers have a pragma once (just
> simpler, doesn't mean it can't be done with traditional header guards).
> - It is not in the standard, but it is supported by a large superset of
> the compilers that we support today. Compilers that do not support it are
> unlikely to support the standard to the extent that we require anyway. HPX
> being standards conformant does not mean we can't use extensions.
> - It's a low risk commitment. If there turn out to be practical problems
> in compilers' implementations of pragma once or if the need would arise to
> support a compiler which doesn't support pragma once, changing back from
> pragma once is easy.
> - Experience from other projects at CSCS. I asked around and multiple
> projects are using pragma once without problems. (YMMV...)
------------------------------
Message: 2
Date: Fri, 3 Apr 2020 06:51:25 -0700
From: Bryce Adelstein Lelbach aka wash <[email protected]>
Subject: Re: [hpx-devel] [VOTE] pragma once
To: [email protected]
Message-ID:
<cap3wax9x4yyhe5ivrzvodm2g+2a9lzsq1g-ss21kumzhj8o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
> Compilers that do not support it are unlikely to support the standard to
the extent that we require anyway
As a data point, CUDA Thrust and CUB have used #pragma once for nearly a
decade, and they support at least as many compilers and platforms as HPX
does, if not more: MSVC (back to 2012), GCC (back to 4.1), Clang, PGI,
NVCC, xlC, ICPC, qcc and C++03 through C++17. We have never had an issue
with #pragma once support in compilers.
On Fri, Apr 3, 2020, 00:20 Simberg Mikael <[email protected]> wrote:
> I proposed to change our header guards to use pragma once in this pr
> <https://github.com/STEllAR-GROUP/hpx/pull/4474>. Since this turned out
> to be a contentious topic, we're turning to our newly created governance
> document <http://hpx.stellar-group.org/documents/governance/>, which
> states:
>
>
> When is a vote required?
>
> Every effort is made to allow the majority of decisions to be taken
> through lazy consensus. That is, simply stating one?s intentions is assumed
> to be enough to proceed, unless an objection is raised. However, some
> activities require a more formal approval process in order to ensure fully
> transparent decision making.
>
> - ...
> - Feature proposal: When a significant addition or removal is proposed to
> the codebase ? Concensus approval of the PMC
> - ...
>
>
> I think feature proposal fits this topic best, even though it's not
> directly a feature exposed to users. It does say "concensus approval of the
> PMC", but we will absolutely take non-PMC votes into consideration as well.
>
>
> I suggest everyone interested in having a say in this read the section on
> voting in the governance document, but I'll paste the summary here:
>
>
> If a formal vote on a proposal is called (signaled simply by sending a
> email with [VOTE] in the subject line), all participants on the HPX user?s
> mailing list may express an opinion and vote. They do this by sending an
> email in reply to the original [VOTE] email, with the following vote and
> information:
>
> - +1: ?yes?, ?agree?: also willing to help bring about the proposed action
> - +0: ?yes?, ?agree?: not willing or able to help bring about the proposed
> action
> - -0: ?no?, ?disagree?: but will not oppose the action?s going forward
> - -1: ?no?, ?disagree?: opposes the action?s going forward and must
> propose an alternative action to address the issue (or a justification for
> not addressing the issue)
>
>
> Just to make the voting clear, agreeing means agreeing to use pragma once,
> disagreeing means sticking with the header guards we have.
>
> I'll start with *+1* for the following reasons:
>
> - Pragma once avoids mistakes by avoiding having to come up with a unique
> name for the header.
> - It only has to be specified in one place in the header file.
> - It's simpler to enforce that all headers have a pragma once (just
> simpler, doesn't mean it can't be done with traditional header guards).
> - It is not in the standard, but it is supported by a large superset of
> the compilers that we support today. Compilers that do not support it are
> unlikely to support the standard to the extent that we require anyway. HPX
> being standards conformant does not mean we can't use extensions.
> - It's a low risk commitment. If there turn out to be practical problems
> in compilers' implementations of pragma once or if the need would arise
> to support a compiler which doesn't support pragma once, changing back from
> pragma once is easy.
> - Experience from other projects at CSCS. I asked around and multiple
> projects are using pragma once without problems. (YMMV...)
>
> _______________________________________________
> hpx-devel mailing list
> [email protected]
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.cct.lsu.edu/pipermail/hpx-devel/attachments/20200403/93e34263/attachment-0001.html
------------------------------
_______________________________________________
hpx-devel mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
End of hpx-devel Digest, Vol 59, Issue 3
****************************************
