- Boost - lists.boost.org

[ublas][odeint] PR merge questions
by Antony Polukhin 06 Feb '23

06 Feb '23

Hi, 1) What is the status of adding CMakeLists.txt to ublas and odeint libraries? That file are essential for using Boost in big companies. Especially it is crucial for integrating Boost into buld systwms other that b2. I see there is a https://github.com/boostorg/ublas/pull/142 but no actions for a year. Please, just merge it. 2) Please, merge the fix https://github.com/boostorg/ublas/pull/153 3) Please, merge the fix https://github.com/boostorg/ublas/pull/153 There are many other PR waiting for merge. I do realise that the maintainers could be short on time. May be there are some developers that you trust and write permission could be given to them?

1 0

[gsoc] GSoC mentors
by David Bellot 06 Feb '23

06 Feb '23

Hi Boost mentors for GSoC 2023, If you're interested in mentoring for the Google Summer of Code 2023, please contact me now by email and if you haven't done it already, please start writing your ideas and proposals. The links on github are provided below. The GSoC overview page at Boost is : https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-Overview The ideas page is here too : https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code:-2023 It's the one you should start filling in. The git repository for your future students and contributors is here: https://github.com/BoostGSoC23 Welcome aboard. Best, David

1 0

The C++ Alliance
by Louis Tatta 03 Feb '23

03 Feb '23

Hello, I am writing to update you on the recent activities of The C++ Alliance. Our newest team members include Matt Borland, Ruben Perez. Matt is developing Boost.Charconv, a C++11 library which polyfills the equivalent C++17 functionality, and contributing to the maintenance and improvement of Boost.Math. Ruben is making significant improvements to Boost.MySQL. Our long-running Boost website project continues to progress and will be deployed in beta this year. As some authors and maintainers may have observed, the code coverage services provided by https://codecov.io have been varying greatly in quality in terms of the user experience of viewing the reports, with the experience being typically worse. To mitigate these risks we are researching the development of a new set of HTML, CSS, and JS templates for presenting high quality coverage reports in the original style. In our continuous efforts to improve documentation quality we have contracted HDoc to explore generating Doxygen compatible XML output so that we might move away from Doxygen in favor of HDoc. This tool is focused specifically on C++ and could be a better fit for Boost libraries that currently use Doxygen. Our vision for documentation includes a significant investment in Asciidoc as the choice of markdown. This means rendering Doxygen/HDoc output in Asciidoc and commissioning a great set of stylesheets for Asciidoc to replace the stock sheets. In the longer term we are investigating Antora as a solution for producing documentation that is well integrated into the new website, to offer a better navigation experience, improved accessibility, more features such as C++ syntax highlighting and code snippet interactivity, and others. We are excited to work on these developments, with the hope they will add vitality and enhance Boost. We look forward to sharing more updates with you in the near future. Best regards Louis Tatta CEO The C++ Alliance

3 2

Two Container Hash libraries on the website
by Andrey Semashev 01 Feb '23

01 Feb '23

Hi, For some reason, Container Hash is listed twice on this page: https://www.boost.org/doc/libs/1_81_0/ The two entries seem equivalent except the "C++ Standard Minimum Level" entry.

2 2

Decommissioning Trac (svn.boost.org)
by Glen Fernandes 31 Jan '23

31 Jan '23

We have Trac in read-only mode after we migrated to Git, but we're still paying for the server. Do people still want to preserve any part of the content in some way? The wiki aside, there are old issues, with comments, and some of them have patches attached. Peter had the idea of generating static HTML content from Trac and hosting that on an archive section on boost.org. (I don't know how difficult this is to do). Thoughts? Suggestions? Glen

5 7

Boost TCP socket read/write issues
by Rahul K R 31 Jan '23

31 Jan '23

Hello All, As part of my project activity, I have to create an asynchronous TCP server application using the boost library. I have created a sample application and it's working. But the issue I am facing is the boost::asio::read API takes a long time to read from the TCP socket, almost 5 seconds. I am using boost library version 1.76.0. I have the following queries regarding this, 1. Is there any known issues for boost::asio::read to consume more time? 2. I am doing reading and writing to the same socket from two threads parallelly, Is that possible with the boost? 3. Is the boost lib can perform well if we get too many requests at a time and process parallelly? I am attaching the sample application code herewith. Please let me know your feedback asap. Regards Rahul

2 1

GSoC 2023 (Google Summer of Code)
by David Bellot 31 Jan '23

31 Jan '23

Hi Boost community, the GSoC 2023 organisation application is now open. Boost is again a candidate this year. We're just waiting for the results to see if we're accepted. In the meantime, we are "recruiting" mentors. Some of you already contacted me a few weeks ago, but maybe some others would be interested to join this fascinating journey. Please contact me now, by mailing list or private email if you're interested. Best, David

2 1

Building the proposed Boost.Mustache
by Peter Dimov 30 Jan '23

30 Jan '23

It's been pointed out that the proposed Boost.Mustache https://github.com/pdimov/mustache (whose formal review is upcoming) is relatively hard to evaluate, because the contents of the repository are in a form that is intended for inclusion into a Boost release. Here's how to build the library, starting from scratch: 1. Clone Boost from Github: git clone --recurse-submodules https://github.com/boostorg/boost 2. Clone the Mustache library into the Boost tree: cd boost/libs git clone https://github.com/pdimov/mustache cd .. 3. Build b2: ./bootstrap.sh (We assume Linux and g++ from now on. On Windows, it's just `booststrap`.) 4. Generate the header links in the boost/ directory: ./b2 headers 5. Build the Mustache library and its dependencies (e.g. JSON): ./b2 --with-mustache This will place the compiled libraries into the stage/lib directory. It should contain libboost_container.a/.so, libboost_json.a/.so, and liboost_mustache.a/.so. You can now build and run the Mustache examples by using e.g. g++ libs/mustache/example/html.cpp -o html -I . -L stage/lib -lboost_mustache -lboost_json ./html

1 1

aedis is ACCEPTED into boost with conditions
by Klemens Morgenstern 28 Jan '23

28 Jan '23

Boost.aedis is ACCEPTED with conditions. Accept: 3 ( + 1 late one) Conditional: 1 Reject: 4 All but one rejections asked for changes that were not fundamental to the design, but rather were about particular implementation details or high-level API design issues. Thus I conclude, based on the reviews, that there is no need for another mini-review. This is also based on Marcelo's engagement, so I am confident that many issues will be addressed in the future . These are the conditions - name it boost.redis - clearly document/specify the behaviour of async_exec, async_receive & async_run, how they interact and all the edge cases (and unit test them) - unit tests for error handling, especially for pipes. - add a design discussion & FAQ page. That should mostly copy & paste from the review discussions. - from_bulk & to_bulk should either us tag_invoke or be be renamed to aedis_from_bulk or aedis_to_bulk - remove memory_resource usage and optimize the allocation strategy of a request object (using new/delete), so that it ideally allocates once and then reuses the memory Please note that the inclusion into boost does not mean that it has to be shipped with the next release. I also strongly recommend development of typed commands, possibly with code generation. This is however not a condition and does not need to be in the first release that's included in boost. Another recommendation is to add some very basic explanation of redis, as some users will read your doc before they look into redis. I want to thank everyone who submitted reviews, especially Ruben who really drilled down on some details and brought in his experience from MySQL. Thank you Zach for getting the discussion started on type-safe command access; based on the discussions I am confident that some feature like that will be added on top of the existing APIs. Similarly I want to thank Дмитрий, Sam & Alan, who's review helped me to formulate the conditions. I am also grateful for (who I think are) first time reviewers, Mohammed Nejati, Robert Leahy, Sam Hartsfield & Miguel, and of course our boost veterans Vinnie & Christian. Likewise I want to thank Marcelo for all his responses to reviews and questions and of course for all the work that went into developing aedis. Congratulations Marcelo!

5 6

[Aedis] Formal Review: We could have done better
by Vinnie Falco 26 Jan '23

26 Jan '23

In hindsight, I feel like perhaps we collectively failed the review process. I think that Boost.Aedis was in fact not ready for a review and it did a disservice both to the library and the author that we rushed to review it. Instead, the relevant subject matter experts such as I, Alan de Freitas, Klemens Morgenstern, Reuben Perez, to a lesser extent Christian Mazakas, Mohammed, and a few others should have taken Aedis under our wing and helped to "get it into shape" before the review. Speaking for myself I wish I had put more time into helping the author get the library into the best possible condition. Instead of waiting until the review, I should have helped Marcelo address the flaws ahead of time. For example: <https://github.com/mzimbres/aedis/issues/51> and <https://github.com/mzimbres/aedis/issues/47> The library should not have gone into the review without one or more revisions to the documentation so that common questions that came up during the review were already answered, perhaps in a FAQ section. In particular, reviewers should not have had to ask why async_run or async_exec (see my example exposition in issue 51 above). I also think that the library would have benefited from a concerted effort to get it in the hands of users. I spent a bunch of energy ahead of time to get users for Beast before submitting it for review. It was already deployed in production systems, and there were other projects that started integrating it both open source and closed. We should have at the very least advertised Aedis in places like the redis++ repository (perhaps with a new GitHub issue). Forums, and such. And looked for individual C++ projects already using Redis and informed them of Aedis. For any new libraries we should look at the lesson of Aedis and consider whether or not a similar treatment would result in a better review of the candidate library. Regardless, I have the highest regard for Marcelo as he demonstrates a mastery of Asio and a commitment to quality, even if the library's outcome of the review is not favorable. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

4 6