December 2023 - Boost-users

Re: [Boost-users] Could sprintf be replaced with snprintf?
by McGrath, Justin M 13 Dec '23

13 Dec '23

Has there been any movement on having someone else maintain ODEINT? I don't know that I would be of much use, but I'm willing to help where I can. There is one other issue that isn't critical, but it would save our group from having to do some hand editing of ODEINT for use with our project. Some of the paths are long enough that after they're included in our project they have nonportable lengths, requiring use to rename them. I made an issue last year: https://github.com/boostorg/odeint/issues/54. Changing the names would surely break code, and I don't know if this is a feasible change. Given that it's pretty easy for people to update include directives though, maybe it's not too intrusive. If it's a welcome change, I can submit a PR on GitHub. Best wishes, Justin ________________________________________ From: McGrath, Justin M <jmcgrath(a)illinois.edu> Sent: Monday, December 4, 2023 11:53 AM To: Matt Borland; Karsten Ahnert Cc: mario.mulansky(a)gmx.net; Nick Thompson Subject: Re: [Boost-users] Could sprintf be replaced with snprintf? Thank you everyone. It would be great if someone could continue managing the package. It's a great resource. Best wishes, Justin ________________________________________ From: Matt Borland <matt(a)mattborland.com> Sent: Friday, December 1, 2023 2:04 AM To: Karsten Ahnert Cc: McGrath, Justin M; mario.mulansky(a)gmx.net; Nick Thompson Subject: Re: [Boost-users] Could sprintf be replaced with snprintf? > On Nov 30, 2023, at 9:27 PM, Karsten Ahnert <karsten.ahnert(a)gmx.de> wrote: > > Merged the pull request. We are not actively maintaining the library anymore. > > But I will keep an eye on any upcoming changes. > Karsten, Thanks. Would you be interested in new maintainers stepping in for the library? Nick Thompson (cced) and I are maintainers on several other Boost libraries (math, multiprecision, random, and test), and we would be interested in helping out. He’s a mathematician, and I am a full-time Boost developer. If you would like to schedule a call or anything to discuss we can do that. Matt

3 2

coroutine condition_variable
by Keith Bennett 06 Dec '23

06 Dec '23

I'm using asio's awaitable. Couroutines are pretty neat. One of the things that keeps cropping up in the ability to notify another function that something has finished. In the past, I would use condition_variable and wait on that. Is there a better way to do that with coroutines? eg, I want to do something like: asio::awaitable<void> function(std::mutex& mtx, condition_variable& cv) { std::unique_lock lock{mtx}; // suspend this function until notified or 30 seconds expired auto expired = co_await cv.wait_until(lock, std::chrono::seconds(30)); if (expired) { // or something log("expired"); co_return; } do_some_work(); } then somewhere else I might do: asio::awaitable<void> somewhere_else(condition_variable& cv) { do_other_work(); cv.notify_one(); } I understand that it's a bad idea to hold a lock during co_await. What other problems prevent something like this from being created? Does something like this already exist? It's not clear from asio reference. I'm using boost 1.81.0 but I can upgrade if that is a problem -- Keith Bennett

3 8

[python] to_python_converter , is by value needed?
by MM 04 Dec '23

04 Dec '23

Hello, I have posted a question here some time ago, I thought to try here as well https://stackoverflow.com/questions/77552946/to-python-converter-is-by-valu… The community of experts in boost.python seems to have moved off to other concerns? Rds,

1 0