January 2023 - Boost - lists.preview.boost.org

Re: [boost] aedis review starts today
by Zach Laine 18 Jan '23

18 Jan '23

As Marcelo pointed out, I did not Reply All; here is the email: On Tue, Jan 17, 2023 at 3:40 PM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Tue, Jan 17, 2023 at 3:11 PM Marcelo Zimbres Silva > <mzimbres(a)gmail.com> wrote: > > > > On Tue, 17 Jan 2023 at 20:39, Zach Laine via Boost > > <boost(a)lists.boost.org> wrote: > > > > > > No. In particular, the API requires the user to write lots of Redis > > > strings by hand. A typo will not be detected until runtime. The > > > set of Redis keywords is fixed; there's no reason not to make an > > > enumeration of them all, like this: > > > > I had enums in the past but I had to remove them for a couple of reasons > > > > 1. There are a multitude of possible commands in the Redis stack, for example > > > > * Redis search: https://redis.io/commands/?group=search > > * Redis graph: https://redis.io/commands/?group=graph > > * Redis time series: https://redis.io/commands/?group=timeseries > > * Redis json: https://redis.io/commands/?group=json > > * Perhaps more I might be missing righ now. > > I don't yet see the problem. In the enumeration I made, there's a > JSON_DEBUG (JSON.DEBUG from https://redis.io/commands/?group=json, but > with s/./_/), etc. None of these enumerators collides with any other; > I compiled the resulting enumeration to check exactly this. Am I > missing something? > > > Then, we would probably agree that the command syntax is equally > > important. To check it properly I would have to write a generator that > > parses the description of each command and generates a checker, see > > https://github.com/redis/redis/tree/unstable/src/commands. > > > > I have made no thoughts so far about how that would work and if I get > > that correctly I would still have to watch for versioning (what > > changes from release to release), what new commands were implemented > > and which were deprecated. > > Yep. That's the job. The good news is that a new version need not be > that disruptive. You only ever need to add to the enumeration, and > you can add a single deprecation-detection function that compares any > enumerator used against the list of enumerators that are deprecated. > > > That might be enough for Redis, but them I would be keeping other > > Redis-like databases off, for example > > > > * https://github.com/Snapchat/KeyDB > > * https://github.com/scylladb/scylladb/blob/master/docs/dev/redis.md > > * https://github.com/dragonflydb/dragonfly > > * Perhaps more. > > > > I don't know how compatible they are with the Redis API. I can't > > afford working on this right now and in the foreseeable future, I see > > it almost as a second library of a module of my library e.g. > > aedis::redis::search::request or something. > > Ok, this is something different. If you don't want to break support > for those other DBs, that's understandable. But since you don't have > support for them at the moment, I don't think possibly adding support > for those later (which could also be added in much the same way) > should slow down adoption of a better interface for Redis today. > > Zach

1 0

Implemented support for recvmmsg / sendmmsg (on supported operating systems: Linux / *BSD / AIX / QNX)
by Virgilio Fornazin 17 Jan '23

17 Jan '23

As stated on asio-users mailing list ( https://sourceforge.net/p/asio/mailman/asio-users/thread/CADfydx%2BDF1kvqch… ), I wrote a patch that enables sendmmsg / recvmmsg on supported operating systems (Linux, [Free/Net/Open]BDS, AIX, Blackberry QNXNeutrino). The syscalls are implemented in reactive_socket_service backend (the io_uring backend on Linux does not support sendmmsg / recvmmsg yet, so no recvmmsg / sendmmsg when using newest support for io_uring on asio). The config.hpp has macros for forcible disable those calls, and detect supported operating system compiler macros. New methods were developed for (send/send_to/receive/receive_from) suffixed with '_multiple_buffer_sequence' that accepts a multiple_buffer_sequence class (backed by asio::detail::array<multiple_buffer_sequence_op, N> or std::vector<multiple_buffer_sequence_op>) and a multiple_buffer_sequence_adapter that convert ops to struct mmsghdr* for sendmmsg/recvmmsg. The multiple_buffer_sequence implementations are basically a collection of multiple_buffer_sequence_op instances that represents each socket operation . It defines the objects needed to perform fill on mmsghdr structures buffer_sequence_type buffer_sequence_; buffer_sequence_adapter_type buffer_sequence_adapter_; endpoint_type endpoint_; bool completed_; socket_base::message_flags flags_; std::size_t bytes_transferred_; asio::error_code error_code_; The multiple_buffer_sequence implementations has full container support, iterators, and support Mutable and Const buffer sequences. I finished the first version of the patch. It's able to send and receive 1million packet / second on my box at same time (an intel i9 9900k / ubuntu 22.04 lts low latency kernel) using packet sizes of 64 / 1430 bytes without packet loss (using 64mb udp socket buffers) A little running demo is able to being watched at https://www.youtube.com/watch?v=Q3hqe6ntM3w. I need to write some automatic tests for (async_)[send/receive]_multiple_buffer_sequence calls[_to/_from] and push a pure ASIO example in examples repository I made the code available for review, scrutiny and suggestions. The source code is in my github repo ( https://github.com/virgiliofornazin/asio ),on branch feature/multiple_datagram_buffers_sequence-io-sendmmsg-recvmmsg ( the full URL of patch diff is https://github.com/chriskohlhoff/asio/compare/master...virgiliofornazin:asi… ).

2 7

Regression Results Not Updating
by Tom Kent 15 Jan '23

15 Jan '23

The results from the pages at: https://www.boost.org/development/tests/develop/developer/summary.html https://www.boost.org/development/tests/master/developer/summary.html Have not updated in almost a month. Can someone check on the process that manages this? Thanks, Tom

4 10

delayed_forward: good, bad, ugly?
by Hans Dembinski 12 Jan '23

12 Jan '23

Dear all, a user noticed that some classes in Boost.Histogram do not provide a strong exception guarantee, although with a few changes they could. I never promised that guarantee for those classes, but I am inclined to support it. To that end, I am considering use a type called delayed_forward to the public interface of that class. I would like to get a mini-review on the concept. The change is backward-compatible and it offers some advantages, so it seems like a good solution to me, but maybe I am missing some caveats. The constructor of my class, let’s call it Foo, accepts some potentially non-trivial parameters by value, because I didn’t want to write an interface with a templated forward reference. Passing non-trivial parameters by value is cheap if the compiler can do RVO or if the user calls the move constructor via std::move. Not using a forward reference saves a few template instantiations and thus reduces compile time. I think I got that from Herb Sutter in a GotW entry, but I cannot find it right now. With delayed_forward one can efficiently pass values to Foo with a single ctor. The trade-off is a tiny runtime cost, but that’s ok if we know that Foos are not created en mass in a hot loop. That already guided my choice of passing by value. A minimal demo is here: https://godbolt.org/z/z71E1jno1 The design of delayed_forward is so simple that it probably already exists somewhere, likely under another name. Maybe even in Boost. What do you think? Hans

5 13

Upcoming aedis review
by Klemens Morgenstern 10 Jan '23

10 Jan '23

The aedis review will start in less than a week, on the 15th and last until the 24th of this month. Aedis is a Redis client library built on top of Boost.Asio that implements the latest version of the Redis communication protocol RESP3. Some of its distinctive features are * A connection class that provides high-level functions to execute Redis commands and receive server pushes concurrently. * Automatic pipelining of commands. * Support for STL containers and serialization of user-defined data types. * Low-latency: Responses can be read in their final data-structure without creating copies. Aedis links Github: https://github.com/mzimbres/aedis Documentation: https://mzimbres.github.io/aedis/ Git tag: v1.4.1 Tarball: https://github.com/mzimbres/aedis/archive/refs/tags/v1.4.1.tar.gz Redis Links: Redis: https://redis.io/ RESP3: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Pipelines: https://redis.io/docs/manual/pipelining/ Redis commands: https://redis.io/commands/ Running Redis: Redis can be also easily installed on your local machine, for example, on Debian run "apt install redis". You might also want to use docker https://www.docker.com/blog/how-to-use-the-redis-docker-official-image/ Please consider writing a review next week.

1 0

CMake documentation (mostly) available
by Peter Dimov 07 Jan '23

07 Jan '23

I've written a document that explains how to use CMake to build or consume Boost, at https://github.com/boostorg/cmake/blob/develop/README.md This targets users of Boost. Developer-centric documentation is also available at https://github.com/boostorg/cmake/blob/develop/developer.md This is still unfinished, but I decided to "publish" it because the portions that are present are still (hopefully) valuable.

1 0

Fwd: CircleCI Security Alert - 4 Jan 2023 - Rotate any secrets stored in CircleCI
by Marshall Clow 05 Jan '23

05 Jan '23

I received this today….. — Marshall > Begin forwarded message: > > From: CircleCI <security(a)circleci.com> > Subject: CircleCI Security Alert - 4 Jan 2023 - Rotate any secrets stored in CircleCI > Date: January 4, 2023 at 6:30:49 PM PST > To: marshall(a)idio.com > Reply-To: security(a)circleci.com > > <https://go.circleci.com/NDg1LVpNSC02MjYAAAGJHrz8WLiocAliTEINy0V4BGCeC4xesDl…> > We wanted to make you aware that we are currently investigating a security incident, and that our investigation is ongoing. We will provide you updates about this incident, and our response, as they become available. At this point, we are confident that there are no unauthorized actors active in our systems; however, out of an abundance of caution, we want to ensure that all customers take certain preventative measures to protect your data as well. > > Action request: > > Out of an abundance of caution, we strongly recommend that all customers take the following actions: > Immediately rotate any and all secrets stored in CircleCI. These may be stored in project environment variables or in contexts. > We also recommend customers review internal logs for their systems for any unauthorized access starting from December 21, 2022 through today, January 4, 2023, or upon completion of your secrets rotation. > Additionally, if your project uses Project API tokens, we have invalidated those and you will need to replace them. You can find more information on how to do that in our documentation here. <https://go.circleci.com/NDg1LVpNSC02MjYAAAGJHrz8WBmOiXzPovREibkXKh8Iqcsacum…> > > We apologize for any disruption to your work. We take the security of our systems and our customers’ systems extremely seriously. While we are actively investigating this incident, we are committed to sharing more details with customers in the coming days. > > Thank you for your urgent attention to rotating your secrets.

1 0

Aedis scheduled for review
by Mateusz Loskot 04 Jan '23

04 Jan '23

Folks, I'd like to thank Klemens Morgenstern for stepping forward and volunteering as a review manager of the Aedis library. The Aedis review will take place between the dates of January 15, 2023 - January 24, 2023 https://www.boost.org/community/review_schedule.html Please, polish your guns and look forward to receiving the start of the review announcement from Klemens. Best regards, -- Mateusz Loskot on behalf of Boost Review Wizards

4 8

Mustache scheduled for review
by Mateusz Loskot 04 Jan '23

04 Jan '23

Folks, I'd like to thank Klemens Morgenstern for volunteering as a review manager of the Mustache library, and Peter Dimov for submitting the library. The Mustache review will take place between the dates of February 5, 2023 - February 14, 2023 https://www.boost.org/community/review_schedule.html As usual, the review manager will announce the beginning of the review with details. Best regards, -- Mateusz Loskot on behalf of Boost Review Wizards

1 0

Updating Review Schedule
by Mateusz Loskot 03 Jan '23

03 Jan '23

Happy New Year Everyone! On behalf of the Review Wizards Team, I'm updating the review schedule. It looks like we will be enjoying two reviews this month yet: - Aedis by Marcelo Zimbres Silva (start planned for Jan, 15) - Mustache by Peter Dimov (start planned not too long after aedis review) Before I issue official announcements, if there are any objections to this plan, then please express them now. Best regards, Mateusz Loskot

2 2