Ignoring unused type aliases in concepts
Hi, In concepts, such unused type aliases are not uncommon. What is the best way to ignore compiler warnings about those? Options I'm aware of are: 1. Adjust compile options in build configuration (Jamfile) 2. Use #pragma in headers 3. Use boost::ignore_unused_variable_warning(alias{}) (or little brother boost::ignore_unused) 4. Ignore ignoring them. The options 1 and 2 are mentioned on https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines The option 3 is not and is there any particular reason why? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mateusz Loskot via Boost Sent: 17 December 2018 13:42 To: boost@lists.boost.org Cc: Mateusz Loskot Subject: [boost] Ignoring unused type aliases in concepts
Hi,
In concepts, such unused type aliases are not uncommon. What is the best way to ignore compiler warnings about those?
Options I'm aware of are: 1. Adjust compile options in build configuration (Jamfile) 2. Use #pragma in headers 3. Use boost::ignore_unused_variable_warning(alias{}) (or little brother boost::ignore_unused) 4. Ignore ignoring them.
The options 1 and 2 are mentioned on https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
The option 3 is not and is there any particular reason why?
No reason, except that TRAC is now read-only, so I can edit it. I asked before for suggestions about if and where this document should be placed in Boost's GitHub world, but didn't get any response. If a decision can be made on this, then I will move it and update to include option 3. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On Mon, 17 Dec 2018 at 17:29, Paul A. Bristow via Boost <boost@lists.boost.org> wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mateusz Loskot via Boost Sent: 17 December 2018 13:42 To: boost@lists.boost.org Cc: Mateusz Loskot Subject: [boost] Ignoring unused type aliases in concepts
In concepts, such unused type aliases are not uncommon. What is the best way to ignore compiler warnings about those?
Options I'm aware of are: 1. Adjust compile options in build configuration (Jamfile) 2. Use #pragma in headers 3. Use boost::ignore_unused_variable_warning(alias{}) (or little brother boost::ignore_unused) 4. Ignore ignoring them.
The options 1 and 2 are mentioned on https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
The option 3 is not and is there any particular reason why?
No reason, except that TRAC is now read-only, so I can edit it.
Right. Sounds good :)
I asked before for suggestions about if and where this document should be placed in Boost's GitHub world, but didn't get any response.
If a decision can be made on this, then I will move it and update to include option 3.
Paul, I remember your call. In fact, I've been waiting for answer to your it myself too, because I was going to help copying the old wiki to GitHub. What about collecting a list of what to migrate and where? I've just started this page https://github.com/boostorg/website/wiki/Trac-Wiki-Migration Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Mateusz Loskot wrote:
Paul, I remember your call. In fact, I've been waiting for answer to your it myself too, because I was going to help copying the old wiki to GitHub.
What about collecting a list of what to migrate and where?
I've just started this page https://github.com/boostorg/website/wiki/Trac-Wiki-Migration
Since it's not possible to grant git push access to the wiki alone, perhaps we should create a separate repository for the new wiki instead of using the superproject one? How does boostorg/wiki sound?
On 2018-12-17 3:57 p.m., Peter Dimov via Boost wrote:
Mateusz Loskot wrote:
Paul, I remember your call. In fact, I've been waiting for answer to your it myself too, because I was going to help copying the old wiki to GitHub.
What about collecting a list of what to migrate and where?
I've just started this page https://github.com/boostorg/website/wiki/Trac-Wiki-Migration
Since it's not possible to grant git push access to the wiki alone, perhaps we should create a separate repository for the new wiki instead of using the superproject one?
How does boostorg/wiki sound?
Whatever makes it easy for people to contribute documentation. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Mon, Dec 17, 2018 at 2:57 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Mateusz Loskot wrote:
Paul, I remember your call. In fact, I've been waiting for answer to your it myself too, because I was going to help copying the old wiki to GitHub.
What about collecting a list of what to migrate and where?
I've just started this page https://github.com/boostorg/website/wiki/Trac-Wiki-Migration
Since it's not possible to grant git push access to the wiki alone, perhaps we should create a separate repository for the new wiki instead of using the superproject one?
How does boostorg/wiki sound?
That sounds fine.. Except for using the wiki functionality in that repo. If you are going to create a new repo, might as well make a github pages project so get better looking docs. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On 2018-12-17 4:02 p.m., Rene Rivera via Boost wrote:
On Mon, Dec 17, 2018 at 2:57 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Since it's not possible to grant git push access to the wiki alone, perhaps we should create a separate repository for the new wiki instead of using the superproject one?
How does boostorg/wiki sound?
That sounds fine.. Except for using the wiki functionality in that repo. If you are going to create a new repo, might as well make a github pages project so get better looking docs.
No, no, no, please no ! :-) gh-pages are certainly nice, in particular as part of a CI-driven pipeline to keep online docs in sync with the code. But they are no substitute for a wiki, for many different reasons. Let's not (again !) make 'perfect' the enemy of 'good'. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Mon, Dec 17, 2018 at 3:09 PM stefan via Boost <boost@lists.boost.org> wrote:
But they are no substitute for a wiki, for many different reasons.
Excuse my ignorance.. How so? Which reasons? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On 2018-12-17 4:16 p.m., Rene Rivera via Boost wrote:
On Mon, Dec 17, 2018 at 3:09 PM stefan via Boost <boost@lists.boost.org> wrote:
But they are no substitute for a wiki, for many different reasons.
Excuse my ignorance.. How so? Which reasons?
* wiki contribution doesn't require the same level of authorization as write-access to a repo. * wiki contribution doesn't require any git expertise. * wiki contribution is much quicker both on the client as well as the server side (it doesn't require any tools other than a web browser, and neither a rebuild on the server). These may sound like quantitative differences, but overall I think they make a qualitative difference (what people like to call a "game changer"). Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Mon, 17 Dec 2018 at 22:09, stefan via Boost <boost@lists.boost.org> wrote:
On 2018-12-17 4:02 p.m., Rene Rivera via Boost wrote:
On Mon, Dec 17, 2018 at 2:57 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Since it's not possible to grant git push access to the wiki alone, perhaps we should create a separate repository for the new wiki instead of using the superproject one?
How does boostorg/wiki sound?
That sounds fine.. Except for using the wiki functionality in that repo. If you are going to create a new repo, might as well make a github pages project so get better looking docs.
No, no, no, please no ! :-)
gh-pages are certainly nice, in particular as part of a CI-driven pipeline to keep online docs in sync with the code. But they are no substitute for a wiki, for many different reasons. Let's not (again !) make 'perfect' the enemy of 'good'.
If the old notion of Wiki is not required, I'd stick to git repo with collection of Markdown files and set up a CI build that runs MkDocs and publishes stuff at `boostorg.github.io/wiki`. Then new content could be submitted via PR. I see advantage of having mechanism to review content. - a classic wiki feels like it's too easy to drop any new page with any garbage, scratch notes, etc. A PR-based maintenance would help to avoid that. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 2018-12-17 4:17 p.m., Mateusz Loskot via Boost wrote:
If the old notion of Wiki is not required, I'd stick to git repo with collection of Markdown files and set up a CI build that runs MkDocs and publishes stuff at `boostorg.github.io/wiki`. Then new content could be submitted via PR. I see advantage of having mechanism to review content. - a classic wiki feels like it's too easy to drop any new page with any garbage, scratch notes, etc. A PR-based maintenance would help to avoid that.
I think there is room (and raison d'etre) for both. A wiki is a convenient playground for new content to be "prototyped". Once stable, it can be migrated to a more curated model. But shutting down a wiki is certainly no way to grow a community (if growing a community is what Boost wants - sometimes I'm in serious doubt about that). Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Mon, 17 Dec 2018 at 22:28, stefan via Boost <boost@lists.boost.org> wrote:
On 2018-12-17 4:17 p.m., Mateusz Loskot via Boost wrote:
If the old notion of Wiki is not required, I'd stick to git repo with collection of Markdown files and set up a CI build that runs MkDocs and publishes stuff at `boostorg.github.io/wiki`. Then new content could be submitted via PR. I see advantage of having mechanism to review content. - a classic wiki feels like it's too easy to drop any new page with any garbage, scratch notes, etc. A PR-based maintenance would help to avoid that.
I think there is room (and raison d'etre) for both. A wiki is a convenient playground for new content to be "prototyped". Once stable, it can be migrated to a more curated model. But shutting down a wiki is certainly no way to grow a community (if growing a community is what Boost wants - sometimes I'm in serious doubt about that).
A vailid idea. Why not using boostorg/website straight away - with Wiki for old Trac Wiki, new ad-hoc and prototyped content - once golden articles are polished, submitted via PR, they may make it into the website Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 2018-12-17 4:30 p.m., Mateusz Loskot via Boost wrote:
Why not using boostorg/website straight away - with Wiki for old Trac Wiki, new ad-hoc and prototyped content - once golden articles are polished, submitted via PR, they may make it into the website
Sure, that sounds good. It supports both, and allows to streamline the integration of both. Stefan -- ...ich hab' noch einen Koffer in Berlin...
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of stefan via Boost Sent: 17 December 2018 21:34 To: boost@lists.boost.org Cc: stefan Subject: Re: [boost] Boostorg wiki (Was: Re: Ignoring unused type aliases in concepts)
On 2018-12-17 4:30 p.m., Mateusz Loskot via Boost wrote:
Why not using boostorg/website straight away - with Wiki for old Trac Wiki, new ad-hoc and prototyped content - once golden articles are polished, submitted via PR, they may make it into the website
Sure, that sounds good. It supports both, and allows to streamline the integration of both.
OK - sounds good to me too. So should I continue to convert the TRAC version to Markdown on Github to get agreement on content? https://github.com/boostorg/boost/wiki/Guidelines:-Warnings (I will include a reference to the long - if hijacked - recent thread on this topic and try to draw some consensus). and start a new thread on warning for comments, corrections, condemnations etc. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 2018-12-18 5:03 a.m., Paul A. Bristow via Boost wrote:
So should I continue to convert the TRAC version to Markdown on Github to get agreement on content?
Yes, please ! I have already started migrating some pages from trac to this wiki years ago. (I have replaced the content of the original pages with a reference to the new one, e.g. https://svn.boost.org/trac10/wiki/Git/GitHome. It would be great to see more pages migrate.)
https://github.com/boostorg/boost/wiki/Guidelines:-Warnings
(I will include a reference to the long - if hijacked - recent thread on this topic and try to draw some consensus).
and start a new thread on warning for comments, corrections, condemnations etc.
Great, thanks ! Stefan -- ...ich hab' noch einen Koffer in Berlin...
Hi Paul, On 2018-12-17 11:28 a.m., Paul A. Bristow via Boost wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mateusz Loskot via Boost Sent: 17 December 2018 13:42 To: boost@lists.boost.org Cc: Mateusz Loskot Subject: [boost] Ignoring unused type aliases in concepts
Hi,
In concepts, such unused type aliases are not uncommon. What is the best way to ignore compiler warnings about those?
Options I'm aware of are: 1. Adjust compile options in build configuration (Jamfile) 2. Use #pragma in headers 3. Use boost::ignore_unused_variable_warning(alias{}) (or little brother boost::ignore_unused) 4. Ignore ignoring them.
The options 1 and 2 are mentioned on https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
The option 3 is not and is there any particular reason why? No reason, except that TRAC is now read-only, so I can edit it.
I asked before for suggestions about if and where this document should be placed in Boost's GitHub world, but didn't get any response.
If a decision can be made on this, then I will move it and update to include option 3.
I don't think you should have to wait for any formal decision. It's a wiki ! :-) Anyhow, I have created a placeholder page here: https://github.com/boostorg/boost/wiki/Guidelines:-Warnings, so please fill it in. If you (or anyone else for that matter) think this is the wrong place, feel free to rename it. Stefan -- ...ich hab' noch einen Koffer in Berlin...
Thanks. A fumbling edit just done. I will add the rest when I have got a better grip on Markdown. And add Mateusz's option 3 and 4. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of stefan via Boost Sent: 17 December 2018 17:16 To: boost@lists.boost.org Cc: stefan Subject: Re: [boost] Ignoring unused type aliases in concepts
Hi Paul,
On 2018-12-17 11:28 a.m., Paul A. Bristow via Boost wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mateusz Loskot via Boost Sent: 17 December 2018 13:42 To: boost@lists.boost.org Cc: Mateusz Loskot Subject: [boost] Ignoring unused type aliases in concepts
Hi,
In concepts, such unused type aliases are not uncommon. What is the best way to ignore compiler warnings about those?
Options I'm aware of are: 1. Adjust compile options in build configuration (Jamfile) 2. Use #pragma in headers 3. Use boost::ignore_unused_variable_warning(alias{}) (or little brother boost::ignore_unused) 4. Ignore ignoring them.
The options 1 and 2 are mentioned on https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
The option 3 is not and is there any particular reason why? No reason, except that TRAC is now read-only, so I can edit it.
I asked before for suggestions about if and where this document should be placed in Boost's GitHub world, but didn't get any response.
If a decision can be made on this, then I will move it and update to include option 3.
I don't think you should have to wait for any formal decision. It's a wiki ! :-)
Anyhow, I have created a placeholder page here: https://github.com/boostorg/boost/wiki/Guidelines:-Warnings,
so please fill it in. If you (or anyone else for that matter) think this is the wrong place, feel free to rename it.
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (5)
-
Mateusz Loskot -
Paul A. Bristow -
Peter Dimov -
Rene Rivera -
stefan