- Boost - lists.preview.boost.org

Github Actions slow
by Sam Darwin 12 Oct '22

12 Oct '22

On https://github.com/boostorg/json we have noticed very slow Github Actions times such as "Total duration: 6h 8m 47s" This is very likely caused by Github throttling jobs. https://docs.github.com/en/actions/learn-github-actions/usage-limits-billin… mentions limits of between 20 and 180 which would apply to the entire boostorg account. A reminder to any boost developers who are seeing slow processing time that they may use Drone CI, instructions at https://github.com/boostorg/boost-ci

4 3

Boost.URL examples
by Alan de Freitas 10 Oct '22

10 Oct '22

Hi, Would anyone like to suggest examples you'd like to see in Boost.URL? Best, -- Alan Freitas https://alandefreitas.github.io/alandefreitas/ <https://github.com/alandefreitas>

1 0

[checking interest] boost.tcl
by Klemens Morgenstern 01 Oct '22

01 Oct '22

Is there any interest in C++ Tcl bindings? I wanted to find out how far I can push boost.describe so I create C++ tcl binding based on it, PoC is here https://github.com/klemens-morgenstern/boost.tcl It's currently a rough PoC so it'd be a lot of work to make this a proper boost library, hence the question if there's some actual interest, otherwise it's a nice toy project. All you need to do is to use boost.describe for your enum or class and then you can use them in tcl: // C++ enum test_enum {foo = 1}; BOOST_DESCRIBE_ENUM(test_enum, foo); struct my_class { double foo; void bar(int); }; BOOST_DESCRIBE_STRUCT(my_class, (), (foo, bar)); BOOST_TCL_PACKAGE(Test_module, "1.0", mod) { auto & cmd = boost::tcl::create_command(mod, "test"); auto & enm = cmd.add_subcommand("enum"); enm.add_enum<test_enum>(); auto & fun = cmd.add_subcommand("add").add_function(+[](int i, int j) {return i + j;); auto & cl = cmd.add_subcommand("add") .add_class<my_class>() // adds all the members based on boost.describe .add_constructor<my_class(int, std::string)>(); } # TCL # create `test_enum` from it's int valid set e1 [test enum 1] # create test_enum from it's name set e2 [test enum foo] # call the function - overloading is supported [test add 1 2] # create an instance of my_class set mc [my_class new 1 test-string] # get a data-member puts [ *$mc .get foo ] # call a method *$mc bar 42

5 4

Re: [boost] [Boost-users] [signals2][variant] inline warning with MSVC 2022
by Frank Mori Hess 23 Sep '22

23 Sep '22

On Wed, Sep 21, 2022 at 12:21 PM Frank Mori Hess <fmh6jj(a)gmail.com> wrote: > > On Mon, Sep 19, 2022 at 3:16 AM Gavin Lambert via Boost-users > <boost-users(a)lists.boost.org> wrote: > > > > >,struct boost::mpl::l_iter<struct boost::mpl::l_end> > *)' marked > > as __forceinline not inlined > > > > I'm not sure whether the Real Bug™ is in signals2 or in variant, but I > > don't think it's in any of my code since it doesn't name any of my types > > above that I can see. > > The problem is not in signals2, as it makes no direct use of > __forceinline. variant does make use of BOOST_FORCEINLINE so it > probably needs to have the pragma suppression added somewhere. > Actually, maybe the easiest thing would be to just put the pragma suppression in the header that defines BOOST_FORCEINLINE (config/detail/suffix.hpp). -- Frank

5 13

[codecov] blowing up like the Hindenburg
by Vinnie Falco 20 Sep '22

20 Sep '22

All: Over the last 15 months, codecov.io has been undergoing a refactoring/rewriting of its user interface and in my opinion it is not for the better. There is a significant loss of functionality and the interface designs which have replaced the old designs are less usable. There's been an open issue for receiving feedback: <https://github.com/codecov/Codecov-user-feedback/issues/1> As you can see a lot of people are having problems. I have scheduled a call with the CEO. My purpose for this thread is to identify other Boost authors, maintainers, and users who have a stake in seeing codecov preserve its functionality and not get worse. And to show where you can go and complain if you are so inclined. Sam is investigating coveralls as an alternative solution. Its UI isn't quite as good as the old codecov. But it is better than the new codecov. Happy to hear anyone's thoughts on this matter. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

3 5

[range] Concept check failing with custom C++20 range support
by Jared McIntyre 19 Sep '22

19 Sep '22

I've been toying around with a pull request that was entered against boost::range to support integration of boost range_v2 and C++20 ranges to see how flexible it would be: https://github.com/boostorg/range/pull/123 I have a need to continue to use boost::any_range in some of our interfaces, but it would be nice to switch to using C++20 ranges under the covers. A lot of it seems to work well with the type definitions from the pull request, but I'm running into an issue with concept check on line 228 or any_iterator_wrapper.hpp specifically when using the transform adaptor. I don't have the same issue with boost::adaptors::transformed. What has me confused is that I think that the result views::transform should be forward traversal, but I'm not really clear on exactly why it is failing. I created a test if anyone wants to play around with it in a compiler and help me understand what is going on: https://godbolt.org/z/1hMsofbrv Switching between the two commented out base_range declarations will get you different results. Here is the code for anyone that just wants to look at it here: #include <boost/range.hpp> #include <boost/range/adaptors.hpp> #include <boost/range/any_range.hpp> #include <ranges> #if 1 namespace boost::range_detail { template< std::ranges::common_range C > struct range_mutable_iterator< C > { typedef std::ranges::iterator_t< C > type; }; template< std::ranges::common_range C > struct range_const_iterator_helper< C > { typedef std::ranges::iterator_t< C const > type; }; } #endif int main() { std::vector<int> vec(5, 0); auto mul2 = [](int i) { return i * 2; }; auto base_range = vec | std::views::transform(mul2); //auto base_range = vec | boost::adaptors::transformed(mul2); boost::any_range<int, boost::forward_traversal_tag> new_range = base_range; }

1 0

[dynamic_bitset] Add iterator feature
by GaoZIYU 11 Sep '22

11 Sep '22

I would like to support iterator feature by adding a few member functions, `begin()`, `end()`, `rbegin()`, `rend()` and their corresponding constant version. I think it's necessary for dynamic_bitset to have this feature through my thinking and other developer's opinions ( https://m.weibo.cn/5027267375/4757345970424490) Now I have submitted a pull request for the feature with code, docs and test case. Please review my code at your convenience. Thanks!

1 0

1.80.0 issue with Clang 15
by Peter Dimov 10 Sep '22

10 Sep '22

I'm getting multiple reports that ContainerHash 1.80.0 doesn't compile with Clang 15, due to the following change to Config unfortunately not being part of the 1.80.0 release: https://github.com/boostorg/config/commit/f0af4a9184457939b89110795ae2d2935… Since the plans for 1.80.1 have been abandoned, it's not clear what we can do about that except probably updating the Known Issues section.

3 2

How to know the connected server is down ?
by Raghu Huchchannavar 07 Sep '22

07 Sep '22

Hi, I am using the boost socket for the client and server connection. i set the socket option as below boost::asio::socket_base::keep_alive option(true); tcp_socket->set_option(option); I am able to connect the client to the server. Suppose after some time the server goes down. How do I get that information without sending any read/write request? 1. Now I don't know how to check if the client is down ? 2. Do I get the signal that the client is down? (Without reading or writing at the client )? . If yes, how to handle it. Please help me with this ... -- Regards Raghavendra Huchchannavar.

3 2

[Leaf] Unable to compile with particular flags.
by Misha Doter 06 Sep '22

06 Sep '22

Hi. I have a project ( https://github.com/rokoDev/buffer/tree/develop ) where I want to use Boost.Leaf as an error handling mechanism. And in addition I need to compile it by clang compiler with flags "-Werror -Wshadow-all -Wsign-conversion -Wextra" but it turned out that Boost.Leaf was unable to compile with these flags. So I have created a git fork( https://github.com/rokoDev/leaf/tree/clang_flags ) from official Boost.Leaf ( https://github.com/boostorg/leaf ) and made minimal changes which allowed me to build it with those flags. Also I have run all unit tests for Boost.Leaf on MacOS with success. Is it possible to accept my changes(probably with appropriate corrections if either) in order to allow compilation of any project with the same compiler flags as in my project but using the official version of Boost.Leaf?

3 4