- Boost - lists.preview.boost.org

Re: [boost] Need Volunteers for Docs!
by Klemens Morgenstern 18 Mar '23

18 Mar '23

I've been writing the occasional post on cppalliance.org, should that go to boost instead? Or should boost operate like an aggregator? On Sat, Mar 18, 2023 at 8:55 AM Vinnie Falco via Boost < boost(a)lists.boost.org> wrote: > All: > > We are working on the User's Guide which is for people who want to use > Boost, and we are working on the Contributor's guide which is for > people who want to contribute to Boost. This includes authors, > maintainers, reviewers, review managers, review wizards, release > managers, contributors, testers, basically everyone who is changing > the state of our repositories somehow. > > These manuals are written in Asciidoc, but we need volunteers who can > jump in and start producing results right away. Most of the existing > site content has been ported to markdown and it needs editing and > sorting into a table of contents. The Getting Started instructions > which go into the release are in pretty rough shape and need editing. > > Documentation has been a long-running complaint of users and authors. > The look of it, the content of it, and the way that people find it. We > are looking to resolve all of that and we've made quite a lot of > progress but we need help. There's a ton of work going into the > infrastructure and website right now so if you want to be a part of it > please speak up! > > This is a sample of where we are going with it (the stylesheets have > not been worked on yet): > > https://antora.cppalliance.org/doc/html/mp11/mp11/list.html > > https://antora.cppalliance.org/doc/html/contributor-manual/intro.html > > Thank you for considering it ! > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Need Volunteers for Docs!
by Vinnie Falco 18 Mar '23

18 Mar '23

All: We are working on the User's Guide which is for people who want to use Boost, and we are working on the Contributor's guide which is for people who want to contribute to Boost. This includes authors, maintainers, reviewers, review managers, review wizards, release managers, contributors, testers, basically everyone who is changing the state of our repositories somehow. These manuals are written in Asciidoc, but we need volunteers who can jump in and start producing results right away. Most of the existing site content has been ported to markdown and it needs editing and sorting into a table of contents. The Getting Started instructions which go into the release are in pretty rough shape and need editing. Documentation has been a long-running complaint of users and authors. The look of it, the content of it, and the way that people find it. We are looking to resolve all of that and we've made quite a lot of progress but we need help. There's a ton of work going into the infrastructure and website right now so if you want to be a part of it please speak up! This is a sample of where we are going with it (the stylesheets have not been worked on yet): https://antora.cppalliance.org/doc/html/mp11/mp11/list.html https://antora.cppalliance.org/doc/html/contributor-manual/intro.html Thank you for considering it !

1 0

Re: [boost] announcing boost.async
by Richard Hodges 17 Mar '23

17 Mar '23

On Fri, 17 Mar 2023 at 16:22, Klemens Morgenstern via Boost < boost(a)lists.boost.org> wrote: > Hi, > > I've been working on a C++20 coroutine library, called `async`, > which is meant to be for C++ what asyncio is for python or generic > async/await is for javascript. > It's meant to be a framework for single threaded coroutine applications. > You are doing the Lord's work. > > It provides coroutine types, such as promises, tasks and generators to > model async operations, > channels for inter-coroutine communication and functions > like select, gather & join to wait or combine multiple awaitables. > > It's asio-based, i.e. uses asio::io_context as its event-loop and can > co_await any asio operation. > > As this is a very complex domain, I really would be happy to have some > users. > This will help me to improve documentation & come up with more > example ideas. > > Docs: https://klemens.dev/async > Repo: https://github.com/klemens-morgenstern/async > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

announcing boost.async
by Klemens Morgenstern 17 Mar '23

17 Mar '23

Hi, I've been working on a C++20 coroutine library, called `async`, which is meant to be for C++ what asyncio is for python or generic async/await is for javascript. It's meant to be a framework for single threaded coroutine applications. It provides coroutine types, such as promises, tasks and generators to model async operations, channels for inter-coroutine communication and functions like select, gather & join to wait or combine multiple awaitables. It's asio-based, i.e. uses asio::io_context as its event-loop and can co_await any asio operation. As this is a very complex domain, I really would be happy to have some users. This will help me to improve documentation & come up with more example ideas. Docs: https://klemens.dev/async Repo: https://github.com/klemens-morgenstern/async

1 0

Re: [boost] improve <boost/math/constants.hpp>
by Gero Peterhoff 16 Mar '23

16 Mar '23

I forgot my test case int main() { std::cout << std::setprecision(100); std::cout << "boost pi" << std::endl; { const auto pi = boost::math::constants::pi<std::float16_t>(); std::cout << pi << std::endl; } { constexpr auto pi = boost::math::constants::pi<std::float128_t>(); std::cout << pi << std::endl; } { constexpr auto pi = boost::math::constants::pi<boost::multiprecision::float128>(); std::cout << pi << std::endl; } { const auto pi = boost::math::constants::pi<boost::multiprecision::cpp_bin_float_100>(); std::cout << pi << std::endl; } std::cout << "my pi" << std::endl; { constexpr auto pi = boost::math::constants::my_pi<std::float16_t>(); std::cout << pi << std::endl; } { constexpr auto pi = boost::math::constants::my_pi<std::float128_t>(); std::cout << pi << std::endl; } { constexpr auto pi = boost::math::constants::my_pi<boost::multiprecision::float128>(); std::cout << pi << std::endl; } { const auto pi = boost::math::constants::my_pi<boost::multiprecision::cpp_bin_float_100>(); std::cout << pi << std::endl; } return EXIT_SUCCESS; } boost pi 3.140625000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857 3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857 3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117068 my pi 3.140625000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857 3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857 3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117068

1 0

Re: [boost] improve <boost/math/constants.hpp>
by Gero Peterhoff 16 Mar '23

16 Mar '23

Am 11.03.23 um 11:44 schrieb John Maddock via Boost: > On 10/03/2023 21:12, Gero Peterhoff via Boost wrote: - The support for XX_v is omitted. - Additional macros BOOST_FLOATxx_C_OR_ZERO are needed. - boost::multiprecision::float128 is now constexpr if possible. > Off the top of my head I see two main correctness issues: > * Your code introduces *double rounding* for float/double (and maybe long double) types, as a result the constants for these types will no longer guarantee last digit accuracy. This is a deal breaker for me> I am not sure if this is actually true. When testing with pi the results were identical. If this should be generally so (testing) we can save the helper macros BOOST_FLOATxx_C_OR_ZERO and use the general version. In the code the general version is available, but commented out. > * For multiprecision types with more digits than we can reasonably store in a string your constants will have insufficient accuracy (cached runtime calculation is needed in this case). Instead of lexical_cast, the constructor(sting) is now used - had overlooked that. Is the accuracy sufficient? > * It's also lacking some "nice to have" features, for example, you have all UDT types going the lexical_cast route, but if the type can be constructed from a builtin type with sufficient precision, then the code is more efficient and constexpr that way. For example with boost::multiprecision::float128. As said boost::multiprecision::float128 works now. Are there any other cases? Exactly with boost::multiprecision::float128 it is noticed negatively that there are 3 code paths: - gcc (BOOST_MP_USE_FLOAT128) - intel (BOOST_MP_USE_QUAD) - in general This was also the reason for my other posting - quadmath as a standalone library. Then there would be only 2 code paths and the quadmath lib could be implemented more understandable. Eg there is in cstdfloat_iostream.hpp AND cstdfloat_cmath.hpp the stream operator<<. This is completely unnecessary effort. You have expressed concerns that with these measures the code would have to be adapted - which nobody likes to do. But in the train with C++23-FP types this must be done anyway - then please correctly. Gero

1 0

Re: [boost] Master branch is now open for bug fixes
by Glen Fernandes 16 Mar '23

16 Mar '23

On Thursday, March 16, 2023, John Maddock via Boost <boost(a)lists.boost.org> wrote: > > I'd like to merge two bug fixes from Multiprecision into master if > possible: > > * This one is a flat out correctness-bug that really should go in: > https://github.com/boostorg/multiprecision/pull/542 > > * This one is a more nice to have fix to the conversion operators: > https://github.com/boostorg/multiprecision/pull/543 > > > Go ahead Glen

1 0

Re: [boost] Master branch is now open for bug fixes
by John Maddock 16 Mar '23

16 Mar '23

On 16/03/2023 15:38, Marshall Clow via Boost wrote: > The master branch is now open for bug fixes and documentation changes. > Other changes by release manager permission, as described in > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> I'd like to merge two bug fixes from Multiprecision into master if possible: * This one is a flat out correctness-bug that really should go in: https://github.com/boostorg/multiprecision/pull/542 * This one is a more nice to have fix to the conversion operators: https://github.com/boostorg/multiprecision/pull/543 In both cases the one CI failure, is a network timeout on the drone runner pulling Boost down. Thanks, John.

1 0

Master branch is now open for bug fixes
by Marshall Clow 16 Mar '23

16 Mar '23

The master branch is now open for bug fixes and documentation changes. Other changes by release manager permission, as described in https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> The next deadline: On April 5th, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall

1 0

Re: [boost] [Release] Master branch is closed for beta
by Andrey Semashev 16 Mar '23

16 Mar '23

On 3/9/23 17:19, Marshall Clow via Boost wrote: > Master is closed for all changes. > > See the release schedule at: https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> Is the master branch open now?

1 0