I'm curious about how I might go about discovering and contacting the person(s) who might be maintaining a particular library. As an example, I have a couple of questions about possible enhancements to the boost interval library (what about making this constexpr?). Ideally, I'd like to see a summary page for each library which steers me to the appropriate links like issues, comments/issues page, maintainence status etc. such as the boost library incubator has. Actually, I considered just adding these pages to the boost library incubator website, but I didn't have the motivation and it might stir a pot I personally don't want to stir right now. Robert Ramey
AMDG On 12/23/2017 02:32 PM, Robert Ramey via Boost wrote:
I'm curious about how I might go about discovering and contacting the person(s) who might be maintaining a particular library. As an example, I have a couple of questions about possible enhancements to the boost interval library (what about making this constexpr?).
Ideally, I'd like to see a summary page for each library which steers me to the appropriate links like issues, comments/issues page, maintainence status etc. such as the boost library incubator has. Actually, I considered just adding these pages to the boost library incubator website, but I didn't have the motivation and it might stir a pot I personally don't want to stir right now.
There's libs/maintainers.txt. Not sure how up-to-date it is. In Christ, Steven Watanabe
On 23.12.2017 16:32, Robert Ramey via Boost wrote:
I'm curious about how I might go about discovering and contacting the person(s) who might be maintaining a particular library. As an example, I have a couple of questions about possible enhancements to the boost interval library (what about making this constexpr?). I think https://github.com/boostorg/interval/blob/develop/meta/libraries.json ought to provide that information.
Ideally, I'd like to see a summary page for each library which steers me to the appropriate links like issues, comments/issues page, maintainence status etc. such as the boost library incubator has. Actually, I considered just adding these pages to the boost library incubator website, but I didn't have the motivation and it might stir a pot I personally don't want to stir right now.
I fully agree, the landing page of each library ought to provide such a table (possibly automatically populated from data in the respective meta/libraries.json file). Initially that could be fully automated, and missing information could be filled in with default values, so library maintainers can replace them with whatever they need. (If we really must, we an of course also generate a global page that presents all those library-specific data in a single place. But that page should always be generated from library-specific metadata.) Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Sat, 23 Dec 2017, Robert Ramey via Boost wrote:
I'm curious about how I might go about discovering and contacting the person(s) who might be maintaining a particular library.
Pessimistic view: start with the CMT page and check if the library is listed there :-(
As an example, I have a couple of questions about possible enhancements to the boost interval library
Indeed, CMT.
(what about making this constexpr?).
That's going to be hard, unless you are happy with making only trivial things (construct, copy) constexpr. -- Marc Glisse
(what about making this constexpr?). That's going to be hard, unless you are happy with making only trivial things (construct, copy) constexpr How come? I looked at the code it seems doable. When I first looked at
On 12/23/17 11:59 PM, Marc Glisse wrote: the code some months ago, it seemed too hard to adapt to my use case. So I made my own specific version. Of course I was wrong and I now I see that my original use case was ill-factored. I do have my own constexpr version, but now it should be about the same as the Boost version. Granted, this might be an ambitious, long and tedious change, but I other than that, I don't see any fundamental obstacle to implementing it. Actually, I would much like to see the documentation improved as well. But by the time we're done, it's really interval2 rather than just a tweak to interval. I've studied the package in some detail. I believe it is well done - but since it was done, I think we have somewhat expectations than we did then. -- Robert Ramey www.rrsd.com (805)569-3793
On Sun, 24 Dec 2017, Robert Ramey via Boost wrote:
On 12/23/17 11:59 PM, Marc Glisse wrote:
(what about making this constexpr?). That's going to be hard, unless you are happy with making only trivial things (construct, copy) constexpr How come?
How do you control the rounding mode at compile time? -- Marc Glisse
On Sun, 24 Dec 2017, Robert Ramey via Boost wrote:
On 12/23/17 11:59 PM, Marc Glisse wrote:
(what about making this constexpr?). That's going to be hard, unless you are happy with making only trivial things (construct, copy) constexpr How come? How do you control the rounding mode at compile time? Hmmm - I don't see anything special about rounding mode that would
On 12/24/17 10:30 AM, Marc Glisse wrote: prevent it from being constexpr. The same sort of question could be raised about lots of aspects of this or any other library. One can't really answer any of these questions until undertaking the task. All or most of the functions depend solely upon their parameters and have not side effects. But, in my recent experience, functions of this sort can generally be made to support constexpr. I'm sure there are functions for which supporting constexpr wouldn't be worth it. Transdental functions come to mind. But I don't think that everything would have to be constexpr in order to be useful. There other things I'd like to see as well - basically template parameter checking with BOOST_STATIC_ASSERT and better documentation of requirements. -- Robert Ramey www.rrsd.com (805)569-3793
On Sun, 24 Dec 2017, Robert Ramey via Boost wrote:
On Sun, 24 Dec 2017, Robert Ramey via Boost wrote:
On 12/23/17 11:59 PM, Marc Glisse wrote:
(what about making this constexpr?). That's going to be hard, unless you are happy with making only trivial things (construct, copy) constexpr How come? How do you control the rounding mode at compile time? Hmmm - I don't see anything special about rounding mode that would
On 12/24/17 10:30 AM, Marc Glisse wrote: prevent it from being constexpr.
The way this currently works is you call fesetround or some asm to set the rounding mode of the FPU, then do your floating point operations as usual, with various tricks to prevent broken compilers (at least gcc and clang) from reordering arithmetic with rounding mode changes. The only way I can think of to make operations constexpr (without making them incredibly slow) is to detect if they are called in a constexpr context, and in that case provide a software emulation. Don't forget to use gcc's -frounding-math flag to see how much you need to emulate...
The same sort of question could be raised about lots of aspects of this or any other library. One can't really answer any of these questions until undertaking the task. All or most of the functions depend solely upon their parameters and have not side effects. But, in my recent experience, functions of this sort can generally be made to support constexpr.
I'm sure there are functions for which supporting constexpr wouldn't be worth it. Transdental functions come to mind. But I don't think that everything would have to be constexpr in order to be useful.
I think even addition or multiplication will not be so easy. Or maybe you are interested in interval<int>? I was only ever interested in interval<double>, but interval<int> should indeed be easy to make constexpr. -- Marc Glisse
On Sun, 24 Dec 2017, Robert Ramey via Boost wrote:
On Sun, 24 Dec 2017, Robert Ramey via Boost wrote:
On 12/23/17 11:59 PM, Marc Glisse wrote:
(what about making this constexpr?). That's going to be hard, unless you are happy with making only trivial things (construct, copy) constexpr How come? How do you control the rounding mode at compile time? Hmmm - I don't see anything special about rounding mode that would
On 12/24/17 10:30 AM, Marc Glisse wrote: prevent it from being constexpr.
The way this currently works is you call fesetround or some asm to set the rounding mode of the FPU, then do your floating point operations as usual, with various tricks to prevent broken compilers (at least gcc and clang) from reordering arithmetic with rounding mode changes. OK - good explanation The only way I can think of to make operations constexpr (without making them incredibly slow) is to detect if they are called in a constexpr context, and in that case provide a software emulation. ] I tried but so far haven't found a way to detect whether a function is being invoked at compile time or run time. I have reason to believe
On 12/24/17 11:20 AM, Marc Glisse wrote: that it's possible, but as I said, I haven't found it yet. It's also possible that the user invoke the functions with a different policy if he's using it in a context which he expects it to be invoked at compile time. Actually, that would likely work in my case.
Don't forget to use gcc's -frounding-math flag to see how much you need to emulate... And efficiency isn't really an issue at compile time.
The same sort of question could be raised about lots of aspects of this or any other library. One can't really answer any of these questions until undertaking the task. All or most of the functions depend solely upon their parameters and have not side effects. But, in my recent experience, functions of this sort can generally be made to support constexpr.
I'm sure there are functions for which supporting constexpr wouldn't be worth it. Transdental functions come to mind. But I don't think that everything would have to be constexpr in order to be useful.
I think even addition or multiplication will not be so easy. In my home brew version - which doesn't consider rounding error - these operations haven't caused any problems. Unfortunately, the only way to really know is to try to do it. Or maybe you are interested in interval<int>? I was only ever interested in interval<double>, but interval<int> should indeed be easy to make constexpr. That's what I've been working with right now. Well, not quite, I'm using interval
which is sort an extended integer type. But the interval code generic in that it's decoupled from the type. The current versions are remarkably easy, hence my interest in seeing the official package support constexpr.
The considerations you mention above suggest that there would be a fair amount of extra information required to use the library effectively. That is, I think that the question of improved documentation would get promoted from desirable, to necessary. -- Robert Ramey www.rrsd.com (805)569-3793
On Sat, Dec 23, 2017 at 4:32 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:
I'm curious about how I might go about discovering and contacting the person(s) who might be maintaining a particular library. As an example, I have a couple of questions about possible enhancements to the boost interval library (what about making this constexpr?).
Ideally, I'd like to see a summary page for each library which steers me to the appropriate links like issues, comments/issues page, maintainence status etc. such as the boost library incubator has. Actually, I considered just adding these pages to the boost library incubator website, but I didn't have the motivation and it might stir a pot I personally don't want to stir right now.
Robert Ramey
Boost.Interval is maintained by the CMT: https://svn.boost.org/trac10/wiki/CommunityMaintenance - Jim
On 24 December 2017 at 16:25, James E. King, III via Boost
Boost.Interval is maintained by the CMT:
The maintainers field in the metadata should probably be updated for community maintenance libraries. I don't think it has to have an email address.
participants (6)
-
Daniel James
-
James E. King, III
-
Marc Glisse
-
Robert Ramey
-
Stefan Seefeld
-
Steven Watanabe