Dear Boost, I have received a non-public review which raises concerns about the naming land grab by proposed Boost.Async i.e. a Boost library called "Async" claims too much through its name. Seeing as nobody here has raised this concern to date, can I confirm everybody here is fine with proposed Boost.Async being called Boost.Async? If you are not, please suggest a preferred alternative name. Niall
I'm not going to submit a review but I do think the name is almost a misnomer. The library is essentially just an Asio wrapper and isn't a genuine coroutine library. I think the name Async gives the wrong impressions and expectations in addition to being much too generic of a name for what the library actually does. I agree with having the library being renamed. - Christian
On Mon, Oct 2, 2023 at 10:43 PM Christian Mazakas via Boost <boost@lists.boost.org> wrote:
I'm not going to submit a review but I do think the name is almost a misnomer.
The library is essentially just an Asio wrapper and isn't a genuine coroutine library.
What would be a genuine asynchronous coroutine library?
I think the name Async gives the wrong impressions and expectations in addition to being much too generic of a name for what the library actually does.
What would be those expectations? What functionality should it include?
Em seg., 2 de out. de 2023 às 11:49, Klemens Morgenstern via Boost < boost@lists.boost.org> escreveu:
On Mon, Oct 2, 2023 at 10:43 PM Christian Mazakas via Boost <boost@lists.boost.org> wrote:
I'm not going to submit a review but I do think the name is almost a
misnomer.
The library is essentially just an Asio wrapper and isn't a genuine coroutine library.
What would be a genuine asynchronous coroutine library?
Can you explain to me what an asynchronous coroutine is? As far as I see, the context-switch always happens in well defined points/cooperatively (thus synchronously). Racket does have preemptive fibers which are interrupted asynchronously (much like Golang's goroutines), but coroutines are not fibers. The Lisp community already learned this lesson: The difference between a fibers facility and just coroutines is that with
fibers, you have a scheduler as well.
https://wingolog.org/archives/2018/05/16/lightweight-concurrency-in-lua We have some of the best experts in this domain in our own community, and a few of them spared the time just on this topic as well: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf The least we should do is to at least take the time to listen. Communities such as Ruby do misnomer coroutines and fibers, but we shouldn't be learning from incorrect material. Just as much, there are plenty of communities for which coroutines are just a syntax sugar for promises, but then again: we shouldn't be learning from incorrect material. Coroutines are not syntax sugars for promise objects. Coroutines are a broader topic. The most popular implementation nowadays are promises objects, but beyond a function that resumes, all the other details that involve these promise objects have nothing to do with coroutines. So, again, could you teach me what an asynchronous coroutine is? This is really a topic that I spend a lot of time mastering. Any new thing that I might learn here would be appreciated. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
On Mon, Oct 2, 2023 at 11:33 PM Vinícius dos Santos Oliveira <vini.ipsmaker@gmail.com> wrote:
Em seg., 2 de out. de 2023 às 11:49, Klemens Morgenstern via Boost <boost@lists.boost.org> escreveu:
On Mon, Oct 2, 2023 at 10:43 PM Christian Mazakas via Boost <boost@lists.boost.org> wrote:
I'm not going to submit a review but I do think the name is almost a misnomer.
The library is essentially just an Asio wrapper and isn't a genuine coroutine library.
What would be a genuine asynchronous coroutine library?
Can you explain to me what an asynchronous coroutine is? As far as I see, the context-switch always happens in well defined points/cooperatively (thus synchronously).
asynchronous in my lingo means that the coroutine might suspend to an asynchronous event source, e.g. a timer expiring. This is my lingo, but is how other languages that provide an async keyword do it, too. So if I were to call std::coroutine_handle<some_async_coro>::resume() I can't assume it's done (reached a yield or a return) when resume returns. This is different from a synchronous coroutine like std::generator, where the .resume() will only occur after a value has been yielded or the generator returned.
Racket does have preemptive fibers which are interrupted asynchronously (much like Golang's goroutines), but coroutines are not fibers. The Lisp community already learned this lesson:
The difference between a fibers facility and just coroutines is that with fibers, you have a scheduler as well.
Well, then what I call an async coroutine, is a conceptual fiber implemented via coroutines. I say conceptual, because boost.fiber and the paper you cite below use an entirely different API from what my coroutines do.
https://wingolog.org/archives/2018/05/16/lightweight-concurrency-in-lua
We have some of the best experts in this domain in our own community, and a few of them spared the time just on this topic as well: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf
The least we should do is to at least take the time to listen.
I would like to point out that the paper does compare the author's coroutine paper to their fiber paper. It does not compare fibers (since it was written in 2014) to the coroutines standardized in C++20, and thus also provide no await mechanism. I am pretty sure both had a different vision than what we got, and the dichotomy between fibers & coroutines in this paper arose from their idea of how to separate the concepts. .
Communities such as Ruby do misnomer coroutines and fibers, but we shouldn't be learning from incorrect material. Just as much, there are plenty of communities for which coroutines are just a syntax sugar for promises, but then again: we shouldn't be learning from incorrect material. Coroutines are not syntax sugars for promise objects. Coroutines are a broader topic. The most popular implementation nowadays are promises objects, but beyond a function that resumes, all the other details that involve these promise objects have nothing to do with coroutines.
I am not familiar with ruby, but I reckon you'd consider goroutines to be fibers? The promise issue is why my library makes a distinction between an awaitable and a coroutine. It's not just syntactic sugar for promises, although I wonder why that would be a bad thing? What's wrong with using coroutines to get out of callback-hell? And I do agree with you, that coroutines are a wider topic, which is why my library is called async. I don't think it's the one true coroutine library, nor is it meant to be. Rather the idea is to allow it to interact with other coroutine libraries. For example, if you were to build a coroutine based stream parser you should be able to make it work asynchronously with an io stream based on boost.async.
So, again, could you teach me what an asynchronous coroutine is? This is really a topic that I spend a lot of time mastering. Any new thing that I might learn here would be appreciated.
The coroutines you get with the async keyword in python or javascript, which means coroutines that run on a scheduler. Both languages have coroutines that are not async, too.
Em seg., 2 de out. de 2023 às 13:23, Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> escreveu:
Can you explain to me what an asynchronous coroutine is? As far as I see, the context-switch always happens in well defined points/cooperatively (thus synchronously).
asynchronous in my lingo means that the coroutine might suspend to an asynchronous event source, e.g. a timer expiring. This is my lingo, but is how other languages that provide an async keyword do it, too.
I'm well aware of languages that perform free-style terming. And everybody mirrors NodeJS these days... However the term there is short for “async IO” rather than async coroutines. In fact, coroutines don't even need to be marked as “async”. Chris Kohlhoff tried to persuade the C++ committee to adopt a keyword-less approach back in 2015: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0114r0.pdf Lua coroutines don't need such keywords either and are in fact more powerful (they can suspend the caller/parent) which makes it possible for them to implement fibers. Lua isn't the only language that exhibits this property. Same goes for Golang's goroutines. Async means a lack of synchronization. You can combo the term with others to give it more meaning (e.g. async IO). So if I were to call std::coroutine_handle<some_async_coro>::resume()
I can't assume it's done (reached a yield or a return) when resume returns. This is different from a synchronous coroutine like std::generator, where the .resume() will only occur after a value has been yielded or the generator returned.
I like this example.
The difference between a fibers facility and just coroutines is that with fibers, you have a scheduler as well.
Well, then what I call an async coroutine, is a conceptual fiber implemented via coroutines. I say conceptual, because boost.fiber and the paper you cite below use an entirely different API from what my coroutines do.
That's correct. You followed the reasoning.
We have some of the best experts in this domain in our own community, and a few of them spared the time just on this topic as well: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf
I would like to point out that the paper does compare the author's coroutine paper to their fiber paper. It does not compare fibers (since it was written in 2014) to the coroutines standardized in C++20, and thus also provide no await mechanism.
Both concepts predate their Boost libraries counterpart (and C++20's as well). C++20 didn't invent coroutines. It's easy to distinguish these concepts anyway. Fibers are meant as "lightweight threads" and as such any fiber library (Boost or not) will need to answer "what fiber should I *schedule* once current one can't make further progress?". Coroutines are a generalization of subroutines that add two new operations: suspend and resume. You can dig into its history easily nowadays.
Communities such as Ruby do misnomer coroutines and fibers, but we shouldn't be learning from incorrect material. Just as much, there are plenty of communities for which coroutines are just a syntax sugar for promises, but then again: we shouldn't be learning from incorrect material. Coroutines are not syntax sugars for promise objects. Coroutines are a broader topic. The most popular implementation nowadays are promises objects, but beyond a function that resumes, all the other details that involve these promise objects have nothing to do with coroutines.
I am not familiar with ruby, but I reckon you'd consider goroutines to be fibers?
Not quite. If we want to be technically correct, goroutines are neither. Fibers come from threading terminology which is a concurrency model that competes against CSP (don't communicate by sharing memory; share memory by communicating). However fibers are closer to goroutines than coroutines. Both fibers and goroutines implicitly require a scheduler. Both represent the "unit of concurrency" in their own concurrency model. Ruby is a weird "impure duck". I do like these pragmatic solutions (my own solution based on Lua and Boost.Asio mixes actors from the actor model and fibers). My dislike for Ruby is just in their minor misnomer here. The promise issue is why my library makes a distinction between an
awaitable and a coroutine. It's not just syntactic sugar for promises, although I wonder why that would be a bad thing? What's wrong with using coroutines to get out of callback-hell?
And I do agree with you, that coroutines are a wider topic, which is why my library is called async. I don't think it's the one true coroutine library, nor is it meant to be.
Rather the idea is to allow it to interact with other coroutine libraries. For example, if you were to build a coroutine based stream parser you should be able to make it work asynchronously with an io stream based on boost.async.
Fair enough.
So, again, could you teach me what an asynchronous coroutine is? This is really a topic that I spend a lot of time mastering. Any new thing that I might learn here would be appreciated.
The coroutines you get with the async keyword in python or javascript, which means coroutines that run on a scheduler. Both languages have coroutines that are not async, too.
They happen asynchronously to what exactly? If there are asynchronous coroutines, there are synchronous coroutines. What distinguishes them? I never saw the term "asynchronous coroutines" anywhere before. I just see a lack of rigorous analysis here. To be honest, if you just mirror the design of NodeJS or whatever, I can't acknowledge you as an expert in this domain. What these languages really provide: - An ecosystem of multiple independent concepts working together with proper synergy. - Among these concepts, a scheduler that concurrently (and synchronously, not asynchronously) switches between tasks. - Among these concepts, also an object to represent a task (a promise). - Also among these concepts, a coroutine at the language-level to remove the boilerplate of writing objects implementing the interface for a promise. - As an optimization when the host operating system provides (e.g. Windows IOCP, Linux io_uring) truly asynchronous IO support (a bigger topic that Boost.Asio already gets right). I did learn from NodeJS and it was good at the time as it helped to push people for something better. However I also learnt from Boost.Asio, Boost.Coroutine, Boost.Context, Boost.Asio, and plenty of members inside and outside Boost's community. Honestly, NodeJS just got stuck in time. It can't hope to grow more than it already did. If you provide a complete copy of NodeJS inside C++ so NodeJS programmers can come over, what is it that you'll offer for them to come here? They already have NodeJS. You need a differentiating factor. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
wt., 3 paź 2023 o 06:53 Vinícius dos Santos Oliveira via Boost < boost@lists.boost.org> napisał(a):
Em seg., 2 de out. de 2023 às 13:23, Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> escreveu:
Can you explain to me what an asynchronous coroutine is? As far as I see, the context-switch always happens in well defined points/cooperatively (thus synchronously).
asynchronous in my lingo means that the coroutine might suspend to an asynchronous event source, e.g. a timer expiring. This is my lingo, but is how other languages that provide an async keyword do it, too.
I'm well aware of languages that perform free-style terming. And everybody mirrors NodeJS these days...
However the term there is short for “async IO” rather than async coroutines. In fact, coroutines don't even need to be marked as “async”. Chris Kohlhoff tried to persuade the C++ committee to adopt a keyword-less approach back in 2015: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0114r0.pdf
Lua coroutines don't need such keywords either and are in fact more powerful (they can suspend the caller/parent) which makes it possible for them to implement fibers. Lua isn't the only language that exhibits this property. Same goes for Golang's goroutines.
Async means a lack of synchronization. You can combo the term with others to give it more meaning (e.g. async IO).
So if I were to call std::coroutine_handle<some_async_coro>::resume()
I can't assume it's done (reached a yield or a return) when resume returns. This is different from a synchronous coroutine like std::generator, where the .resume() will only occur after a value has been yielded or the generator returned.
I like this example.
The difference between a fibers facility and just coroutines is that with fibers, you have a scheduler as well.
Well, then what I call an async coroutine, is a conceptual fiber implemented via coroutines. I say conceptual, because boost.fiber and the paper you cite below use an entirely different API from what my coroutines do.
That's correct. You followed the reasoning.
We have some of the best experts in this domain in our own community, and a few of them spared the time just on this topic as well: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf
I would like to point out that the paper does compare the author's coroutine paper to their fiber paper. It does not compare fibers (since it was written in 2014) to the coroutines standardized in C++20, and thus also provide no await mechanism.
Both concepts predate their Boost libraries counterpart (and C++20's as well). C++20 didn't invent coroutines.
It's easy to distinguish these concepts anyway. Fibers are meant as "lightweight threads" and as such any fiber library (Boost or not) will need to answer "what fiber should I *schedule* once current one can't make further progress?".
Coroutines are a generalization of subroutines that add two new operations: suspend and resume. You can dig into its history easily nowadays.
Communities such as Ruby do misnomer coroutines and fibers, but we shouldn't be learning from incorrect material. Just as much, there are plenty of communities for which coroutines are just a syntax sugar for promises, but then again: we shouldn't be learning from incorrect material. Coroutines are not syntax sugars for promise objects. Coroutines are a broader topic. The most popular implementation nowadays are promises objects, but beyond a function that resumes, all the other details that involve these promise objects have nothing to do with coroutines.
I am not familiar with ruby, but I reckon you'd consider goroutines to be fibers?
Not quite. If we want to be technically correct, goroutines are neither. Fibers come from threading terminology which is a concurrency model that competes against CSP (don't communicate by sharing memory; share memory by communicating). However fibers are closer to goroutines than coroutines. Both fibers and goroutines implicitly require a scheduler. Both represent the "unit of concurrency" in their own concurrency model.
Ruby is a weird "impure duck". I do like these pragmatic solutions (my own solution based on Lua and Boost.Asio mixes actors from the actor model and fibers). My dislike for Ruby is just in their minor misnomer here.
The promise issue is why my library makes a distinction between an
awaitable and a coroutine. It's not just syntactic sugar for promises, although I wonder why that would be a bad thing? What's wrong with using coroutines to get out of callback-hell?
And I do agree with you, that coroutines are a wider topic, which is why my library is called async. I don't think it's the one true coroutine library, nor is it meant to be.
Rather the idea is to allow it to interact with other coroutine libraries. For example, if you were to build a coroutine based stream parser you should be able to make it work asynchronously with an io stream based on boost.async.
Fair enough.
So, again, could you teach me what an asynchronous coroutine is? This is really a topic that I spend a lot of time mastering. Any new thing that I might learn here would be appreciated.
The coroutines you get with the async keyword in python or javascript, which means coroutines that run on a scheduler. Both languages have coroutines that are not async, too.
They happen asynchronously to what exactly? If there are asynchronous coroutines, there are synchronous coroutines. What distinguishes them? I never saw the term "asynchronous coroutines" anywhere before.
I just see a lack of rigorous analysis here. To be honest, if you just mirror the design of NodeJS or whatever, I can't acknowledge you as an expert in this domain.
What these languages really provide:
- An ecosystem of multiple independent concepts working together with proper synergy. - Among these concepts, a scheduler that concurrently (and synchronously, not asynchronously) switches between tasks. - Among these concepts, also an object to represent a task (a promise). - Also among these concepts, a coroutine at the language-level to remove the boilerplate of writing objects implementing the interface for a promise. - As an optimization when the host operating system provides (e.g. Windows IOCP, Linux io_uring) truly asynchronous IO support (a bigger topic that Boost.Asio already gets right).
I did learn from NodeJS and it was good at the time as it helped to push people for something better. However I also learnt from Boost.Asio, Boost.Coroutine, Boost.Context, Boost.Asio, and plenty of members inside and outside Boost's community. Honestly, NodeJS just got stuck in time. It can't hope to grow more than it already did. If you provide a complete copy of NodeJS inside C++ so NodeJS programmers can come over, what is it that you'll offer for them to come here? They already have NodeJS. You need a differentiating factor.
I am convinced by this. If I were reviewing the library now, after what I have learned from this thread, my recommendation would have been to reject the library for now, as it was the case when Boost was young, on the grounds that the programming model and the scope is not clear. It is still not clear to me, "when I should use this library". My best approximation is "when I already use Boost.ASIO (directly or indirectly) and I find its (ASIO's) interface too clumsy". Regards, &rzej;
-- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sun, Oct 8, 2023 at 9:00 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
If I were reviewing the library now, after what I have learned from this thread, my recommendation would have been to reject the library for now, as it was the case when Boost was young, on the grounds that the programming model and the scope is not clear. It is still not clear to me, "when I should use this library". My best approximation is "when I already use Boost.ASIO (directly or indirectly) and I find its (ASIO's) interface too clumsy".
I trust your judgement even though I am not completely familiar with the technical details of the argument presented. That said, I believe that the review for this particular library is flawed, and I question the decision to accept. There are an insufficient number of reviews, the scope of the library is not clear, and furthermore there is no clarity with respect to answering the question "what belongs in Boost?" Ask five different people on the list and you will get five different answers. If there is no documented explanation of what belongs in Boost then the outcomes of certain reviews are going to be highly unpredictable, especially those where there is controversy. In some cases the answer to what belongs in Boost is obvious. Implementations of standard library features for older versions of C++ are an example of something that obviously belongs in Boost. A library modeled on an existing 3rd party library but polished up to Boost quality and working with other Boost libraries (e.g. boost::system::error_code) is another: Boost.JSON. But then we have novel libraries for which reviewers have no template, no guidance, no existing practice to understand whether or not something belongs in Boost, and I believe Boost.Klemens.Async is the perfect example of such a library. This is my opinion, but I believe in these cases that the proper course of action is for the author to "do the work" of going out into the community and establishing a user base for the library before submitting it for review (as I have done with Beast and URL). As an active member of the Official C++ Slack Workspace I observed the development process of Boost.Async, which unfolded roughly this way: 1. "Let's write a new library and propose it for Boost" 2. (work on library) 3. Propose for Boost This can work when the author is a C++ savant like Peter Dimov but for ordinary humans such as myself I think that authoring a library with the intent of going "direct to Boost" is a recipe for yielding poor results. I believe that at a minimum we should have required some field experience before the review was scheduled, so that reviewers would have more information to go on in terms of seeing how this library fits into the Asio and coroutine ecosystem. Andrzej: There is a process for disputing the results of a review, by reporting the concerns to the Review Wizard. I would like to dispute the review result, on the grounds mentioned above, and if you still feel strongly about rejecting the library for the aforementioned reasons then I suggest you also dispute the review results. This goes for everyone on the list. Who is the Review Wizard for this review? Side note: Did you know that review results can be disputed? Because I can't find this information on the website. I think we need to start documenting the review process and formalizing some of these common law rules, so that future reviews can be conducted at the high level of quality befitting Boost. Thanks, Vinnie
niedz., 8 paź 2023 o 18:15 Vinnie Falco <vinnie.falco@gmail.com> napisał(a):
On Sun, Oct 8, 2023 at 9:00 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
If I were reviewing the library now, after what I have learned from this thread, my recommendation would have been to reject the library for now, as it was the case when Boost was young, on the grounds that the programming model and the scope is not clear. It is still not clear to me, "when I should use this library". My best approximation is "when I already use Boost.ASIO (directly or indirectly) and I find its (ASIO's) interface too clumsy".
I trust your judgement even though I am not completely familiar with the technical details of the argument presented.
That said, I believe that the review for this particular library is flawed, and I question the decision to accept.
There are an insufficient number of reviews, the scope of the library is not clear, and furthermore there is no clarity with respect to answering the question "what belongs in Boost?" Ask five different people on the list and you will get five different answers. If there is no documented explanation of what belongs in Boost then the outcomes of certain reviews are going to be highly unpredictable, especially those where there is controversy.
In some cases the answer to what belongs in Boost is obvious. Implementations of standard library features for older versions of C++ are an example of something that obviously belongs in Boost. A library modeled on an existing 3rd party library but polished up to Boost quality and working with other Boost libraries (e.g. boost::system::error_code) is another: Boost.JSON.
But then we have novel libraries for which reviewers have no template, no guidance, no existing practice to understand whether or not something belongs in Boost, and I believe Boost.Klemens.Async is the perfect example of such a library. This is my opinion, but I believe in these cases that the proper course of action is for the author to "do the work" of going out into the community and establishing a user base for the library before submitting it for review (as I have done with Beast and URL).
As an active member of the Official C++ Slack Workspace I observed the development process of Boost.Async, which unfolded roughly this way:
1. "Let's write a new library and propose it for Boost" 2. (work on library) 3. Propose for Boost
This can work when the author is a C++ savant like Peter Dimov but for ordinary humans such as myself I think that authoring a library with the intent of going "direct to Boost" is a recipe for yielding poor results. I believe that at a minimum we should have required some field experience before the review was scheduled, so that reviewers would have more information to go on in terms of seeing how this library fits into the Asio and coroutine ecosystem.
Andrzej: There is a process for disputing the results of a review, by reporting the concerns to the Review Wizard. I would like to dispute the review result, on the grounds mentioned above, and if you still feel strongly about rejecting the library for the aforementioned reasons then I suggest you also dispute the review results. This goes for everyone on the list. Who is the Review Wizard for this review?
Well, so far the results for this review have not been announced, so there is nothing to dispute. I had similar concerns for other libraries recently accepted to Boost: Boost.MySQL, Boost.Redis. I cannot assess their quality or design, as they are too big, and I am not an expert. They may be good, but even good libraries do not necessarily belong to Boost. Are they sufficiently general-purpose? Are we just giving a stump that a library meets a certain level of quality of design and implementation? Or are we aiming at an extended Standard Library? Regards, &rzej;
Side note: Did you know that review results can be disputed? Because I can't find this information on the website. I think we need to start documenting the review process and formalizing some of these common law rules, so that future reviews can be conducted at the high level of quality befitting Boost.
Thanks,
Vinnie
On 10/8/23 21:08, Andrzej Krzemienski via Boost wrote:
I had similar concerns for other libraries recently accepted to Boost: Boost.MySQL, Boost.Redis. I cannot assess their quality or design, as they are too big, and I am not an expert. They may be good, but even good libraries do not necessarily belong to Boost. Are they sufficiently general-purpose? Are we just giving a stump that a library meets a certain level of quality of design and implementation? Or are we aiming at an extended Standard Library?
I think there is a long history of libraries that are unlikely to be ever accepted into the standard but which are generally very much useful. Boost.Spirit, Boost.Intrusive, Boost.Fusion, Boost.MPL, to name a few examples. (Yes, MPL has fallen out of favor lately, but one cannot overestimate its impact before wide adoption of C++11.) I'm not saying anything about the libraries you mention. I have no experience with them, nor am I familiar with their domain. I'm just saying that targeting the standard library has never been the criteria for accepting libraries into Boost.
That said, I believe that the review for this particular library is flawed, and I question the decision to accept.
There are an insufficient number of reviews, the scope of the library is not clear, and furthermore there is no clarity with respect to answering the question "what belongs in Boost?" Ask five different people on the list and you will get five different answers. If there is no documented explanation of what belongs in Boost then the outcomes of certain reviews are going to be highly unpredictable, especially those where there is controversy.
Should I have rejected boost.url, which had the same amount of reviews? There are more libraries with seven or less reviews in boost, boost.lambda2 had 6. If we introduce a lower limit, Also, isn't a "REJECT, I don't think it belongs in boost" a fair review?
In some cases the answer to what belongs in Boost is obvious. Implementations of standard library features for older versions of C++ are an example of something that obviously belongs in Boost. A library modeled on an existing 3rd party library but polished up to Boost quality and working with other Boost libraries (e.g. boost::system::error_code) is another: Boost.JSON.
Why is the second obvious? I also find the question "does it belong in boost" misguided. If it passed review, it belongs in boost. You are free to write a short review rejecting it and the review manager is free to disregard
But then we have novel libraries for which reviewers have no template, no guidance, no existing practice to understand whether or not something belongs in Boost, and I believe Boost.Klemens.Async is the perfect example of such a library. This is my opinion, but I believe in these cases that the proper course of action is for the author to "do the work" of going out into the community and establishing a user base for the library before submitting it for review (as I have done with Beast and URL).
That's not really true. Libraries akin to async have been around in other languages for a very long time. Then there is also cppcoro and the coroutine types existing in asio. How big does the user-base need to be and how would this be measured?
Andrzej: There is a process for disputing the results of a review, by reporting the concerns to the Review Wizard. I would like to dispute the review result, on the grounds mentioned above, and if you still feel strongly about rejecting the library for the aforementioned reasons then I suggest you also dispute the review results. This goes for everyone on the list. Who is the Review Wizard for this review?
Which grounds? Too few reviews? Because all the other things you brought up should be addressed during review I would really like a review wizard to clarify what valid grounds for disputing a review are.
On Sun, Oct 8, 2023 at 1:26 PM Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> wrote:
Should I have rejected boost.url, which had the same amount of reviews?
Perhaps, you could have, and it would not have bothered me in the slightest, because Boost.URL *already had users* and there were more coming every day. In other words Boost.URL offered such compelling usability and utility that it did not *need* to be part of the official Boost distribution in order for other projects
I also find the question "does it belong in boost" misguided. If it passed review, it belongs in boost.
That is probably true and helpful for most reviews but we are talking about outliers. I was never given any instructions on what belongs in Boost. There is no place anyone can go to answer this question for themselves. For example, does a library with no users, no field experience, whose API is not based on any other model, for which the intention is to "shove it in Boost and see who uses it" qualify as "belonging in Boost?" I wish we knew. The simple formula of "if it passed review, it belongs in boost" is unfortunately not a healthy or sustainable model. Libraries akin to async have been around in other languages for a very long
time.... How big does the user-base need to be and how would this be measured
On this, we agree. That there is a need for *something* along the lines of Boost.Klemens.Async, is not disputed. In fact, one could say that the demand is so high, that Not-In-Boost.Klemens.Async should gain traction on its own even without the need to be included in the distribution.
Which grounds? Too few reviews? Because all the other things you brought up should be addressed during review
I would really like a review wizard to clarify what valid grounds for disputing a review are.
Again I find myself in agreement here. The review process most of the time "just works" but every so often we get just the right combination of review manager, author, library, and "direct to Boost" philosophy on a controversial tech that answering the question of "does this belong in Boost" suddenly is not simple. And we end up with reviews that proclaim acceptance if for no other reason than "coroutines are important and Boost has to _do something_ about them" without any practical experience. I want to stress that I am not saying every library needs field experience. This is different from WG21 - where I believe that ANY proposed library-only solution should bake for years. For Boost we do not need such a high bar. But a controversial library from a particular author with a particular review manager in a particular subject for which there is little to no field experience, I think that it needs to prove itself. If it was me proposing Boost.Async, and someone said "hey Vinnie you need to get some users" I would simply withdraw my library from consideration and spend the next year getting those users. That you are arguing with me and not putting in the work to market your library and work with other projects to get them to use it, is a red flag. I would make sure that when my library goes up for review there is a cadre of existing users standing with me and making their presence felt virtually ("accept this library or we will become loud!"). Boost.Klemens.Async has no cadre of existing users. No other project uses it. Basically this library is like an unhoused person asking for handouts "please accept my library even though I have no users." As a matter of pride I would never allow my hard work to limp into a review with no support. Thanks
On Sun, Oct 8, 2023 at 3:37 PM Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Sun, Oct 8, 2023 at 1:26 PM Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> wrote:
Should I have rejected boost.url, which had the same amount of reviews?
Perhaps, you could have, and it would not have bothered me in the slightest, because Boost.URL *already had users* and there were more coming every day. In other words Boost.URL offered such compelling usability and utility that it did not *need* to be part of the official Boost distribution in order for other projects
This got cut off, here is the full text: Perhaps, you could have, and it would not have bothered me in the slightest, because Boost.URL *already had users* and there were more coming every day. In other words Boost.URL offered such compelling usability and utility that it did not *need* to be part of the official Boost distribution in order for other projects to incorporate it and use it in informal and commercial projects. I want to be clear here, the practice of "we need to accept it into Boost to get users and find out if its any good" to be a harmful idea that carries significant reputational risk. There is no stated policy which describes whether or not this practice is valid for determining acceptance in a review, which is itself a problem (lack of a clear written instructions on how reviewers should evaluate libraries), and the reason that I am having to make these posts. It might be that such a policy would be detrimental as it would be too much of a hard and fast rule, and the question is best determined on a case by case bases. In that scenario I believe that Boost.Klemens.Async is one such case. Thanks
Vinnie Falco wrote:
I want to be clear here, the practice of "we need to accept it into Boost to get users and find out if its any good" to be a harmful idea that carries significant reputational risk. There is no stated policy which describes whether or not this practice is valid for determining acceptance in a review, which is itself a problem (lack of a clear written instructions on how reviewers should evaluate libraries), and the reason that I am having to make these posts.
Boost has never required a library to have users in order to be accepted. If the review process says it's good, it's good. Reviews from users count more than reviews from non-users, of course, but that's the extent of it. As for "reputational risk", the reputation we have has been built while using the above policy. I'm also thinking that we apparently need to have a (written) rule about people questioning the review result without having submitted a review. If you can't be bothered to invest the time to review the library, your opinion on whether it belongs in Boost doesn't count. Or stated differently, the proper and only way to express your opinion on whether the library belongs in Boost or not is by submitting a review.
On Sun, Oct 8, 2023 at 4:42 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Vinnie Falco wrote:
I want to be clear here, the practice of "we need to accept it into
Boost
to get users and find out if its any good" to be a harmful idea that carries significant reputational risk. There is no stated policy which describes whether or not this practice is valid for determining acceptance in a review, which is itself a problem (lack of a clear written instructions on how reviewers should evaluate libraries), and the reason that I am having to make these posts.
Boost has never required a library to have users in order to be accepted. If the review process says it's good, it's good.
Reviews from users count more than reviews from non-users, of course, but that's the extent of it.
As for "reputational risk", the reputation we have has been built while using the above policy.
I'm also thinking that we apparently need to have a (written) rule about people questioning the review result without having submitted a review. If you can't be bothered to invest the time to review the library, your opinion on whether it belongs in Boost doesn't count.
Or stated differently, the proper and only way to express your opinion on whether the library belongs in Boost or not is by submitting a review.
That said, it is still valid to express an opinion in principle. I don't feel qualified to write a review, but in principle I think it's valid to vote REJECT due to major design disagreements, as in "this is the wrong solution to the problem", however this requires at least outlining an alternative design. Other than that, if a library is well documented, solves problems reasonably well, and is written with competence and with domain knowledge, then it should be accepted.
On Sun, Oct 8, 2023 at 4:41 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Boost has never required a library to have users in order to be accepted. If the review process says it's good, it's good. ... Or stated differently, the proper and only way to express your opinion on whether the library belongs in Boost or not is by submitting a review.
What I am saying is that I believe the author knows the library would not get users on its own and this is why there was no effort to acquire them. Thanks
On Sun, Oct 8, 2023 at 5:00 PM Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Sun, Oct 8, 2023 at 4:41 PM Peter Dimov via Boost <
boost@lists.boost.org>
wrote:
Boost has never required a library to have users in order to be accepted. If the review process says it's good, it's good. ... Or stated differently, the proper and only way to express your opinion on whether the library belongs in Boost or not is by submitting a review.
What I am saying is that I believe the author knows the library would not get users on its own and this is why there was no effort to acquire them.
I don't see anything wrong with an author seeking acceptance in Boost as a way to acquire users. Authors who don't care about that don't bother with Boost, they go straight to std. :)
On Sun, Oct 8, 2023 at 5:31 PM Emil Dotchevski via Boost < boost@lists.boost.org> wrote:
I don't see anything wrong with an author seeking acceptance in Boost as a way to acquire users.
Then let me educate you. Users correctly or incorrectly presume that all libraries in the Boost collection will have the same consistently high level of quality in terms of library API, documentation, performance, and fitness to task. As this is almost impossible to sustain over time, eventually an experienced Boost user recognizes that some libraries are better than others. And they may discover that some libraries are a trap, unable to deliver on their promises, or perhaps they are not as well maintained anymore. In other words quality varies significantly from library to library. During the "golden age of Boost" which occurred at the inception of Boost and stretched until 2011, this was less of a problem as the people proposing libraries were experts in the field who also participated in the standards process. But now there is less participation in Boost and more participation in the standardization process. Mailing list volume is down and fewer reviewers appear for new libraries. Boost also lost its Great Founders and momentum slowed. I was told a long time ago that the formal review process is as much about evaluating the author as it is about evaluating the library. Because once a library goes into the collection it needs to be maintained, and only the original author has the best understanding of the library and how it might evolve over time. For example an author of inconsistent temperament who might abandon their library after it passes a review would be harmful to the integrity of the collection. I'm not saying this is applicable in this case but we have a similar problem. I challenge the author with this exhortation: get a user or two, show that this thing is compelling enough to be used outside of the Boost community in an actual project, and then submit it. What is so hard about that? What's the rush to put this into the collection? If it's good it will be just as good two or three releases from now. And no one will be impeded from using it even before it becomes part of a release. Klemens: why do you have zero users? The question is of course rhetorical because we already have the answers. No effort was made to acquire them, no thoughtfulness was put into actual user needs, no users were consulted during the development of the library. How many times was Peter Dimov consulted during the library's development? Did Christopher Kohloff offer his input? In the first review cycle for the library it was said that the library is single threaded and it made sense to optimize: https://lists.boost.org/Archives/boost/2023/08/254938.php I got no answer to this question so I asked it again: https://lists.boost.org/Archives/boost//2023/08/254958.php Still no answers to this question from August, the author provided no information about how the library is optimized, what kind of improvement was seen, the methodology for optimization, any kind of benchmarks, and so on. There is just a handwavey claim of performance. Is this how low Boost has fallen now? What happened to the engineering rigor and discipline that was the hallmark of Boost's heyday? Must we resign ourselves to the indignity of statements like "I don't see anything wrong with an author seeking acceptance in Boost as a way to acquire users?" Sad. Thanks
I challenge the author with this exhortation: get a user or two, show that this thing is compelling enough to be used outside of the Boost community in an actual project, and then submit it. What is so hard about that? What's the rush to put this into the collection? If it's good it will be just as good two or three releases from now. And no one will be impeded from using it even before it becomes part of a release.
... what makes you think I have zero users? Who are the people opening issues?
Klemens: why do you have zero users? The question is of course rhetorical because we already have the answers. No effort was made to acquire them, no thoughtfulness was put into actual user needs, no users were consulted during the development of the library. How many times was Peter Dimov consulted during the library's development? Did Christopher Kohloff offer his input?
I have users. I have talked to them and to potential users to refine the API & scope. You keep assuming the worst here and you're wrong on almost every point I did reach out to Peter & Chris as well, but neither led to any input. Now you're just making up things.
In the first review cycle for the library it was said that the library is single threaded and it made sense to optimize:
https://lists.boost.org/Archives/boost/2023/08/254938.php
I got no answer to this question so I asked it again:
https://lists.boost.org/Archives/boost//2023/08/254958.php
Still no answers to this question from August, the author provided no information about how the library is optimized, what kind of improvement was seen, the methodology for optimization, any kind of benchmarks, and so on. There is just a handwavey claim of performance. Is this how low Boost has fallen now? What happened to the engineering rigor and discipline that was the hallmark of Boost's heyday? Must we resign ourselves to the indignity of statements like "I don't see anything wrong with an author seeking acceptance in Boost as a way to acquire users?"
It didn't sound like a serious question - my docs have a benchmark section, you know? async uses symmetric transfer all over the place, which is the main optimization over asio. Using pmr is not really an optimization, but a customization point one can disable at compile time. I didn't want an allocator template parameter everywhere, so pmr is the standard version of achieving this. Beside symmetric transfer, async uses a small buffer in the coroutine frame which gets used for the associated allocator of an `co_await async_foo(..., use_op)` expression. Depending on the memory required by the op, that can mean that no allocations take place at all. The upstream of the sbo depends on whether or not PMR is disabled. See the "Operation Allocation": https://klemens.dev/async/benchmarks.html
Sad.
This thread is making me sad indeed.
On Sun, Oct 8, 2023 at 6:51 PM Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> wrote:
async uses symmetric transfer all over the place, which is the main optimization over asio.
Using pmr is not really an optimization, but a customization point one can disable at compile time. I didn't want an allocator template parameter everywhere, so pmr is the standard version of achieving this.
Beside symmetric transfer, async uses a small buffer in the coroutine frame which gets used for the associated allocator of an `co_await async_foo(..., use_op)` expression. Depending on the memory required by the op, that can mean that no allocations take place at all. The upstream of the sbo depends on whether or not PMR is disabled.
That is all wonderful but I think it should go into the documentation, not the list. Thanks
On Sun, Oct 8, 2023 at 6:51 PM Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> wrote:
I have users. I have talked to them and to potential users to refine the API & scope. You keep assuming the worst here and you're wrong on almost every point
If I am completely wrong about some of what I said or even all of it, then I am pleased and relieved. Thanks
On 10/8/23 6:21 PM, Vinnie Falco via Boost wrote:
On Sun, Oct 8, 2023 at 5:31 PM Emil Dotchevski via Boost < boost@lists.boost.org> wrote:
I don't see anything wrong with an author seeking acceptance in Boost as a way to acquire users.
Then let me educate you.
LOL
I challenge the author with this exhortation: get a user or two, show that this thing is compelling enough to be used outside of the Boost community in an actual project, and then submit it. What is so hard about that? What's the rush to put this into the collection? If it's good it will be just as good two or three releases from now. And no one will be impeded from using it even before it becomes part of a release.
I would note that many libraries have been accepted into Boost with zero users. In fact many libraries have been accepted into Boost that have many weaknesses and problems with the condition that these be addressed before the library is released. This is certainly the case with the two libraries I'm responsable for: Serialization an Safe Numerics. When I proposed serialization the first time it was rejected for a lot of good reasons. Nothing wrong with that. The review was very helpful to me and motivated me to double down and address all the noted short comings. It was accepted a year later. When I proposed Safe Numerics, it had a lot of problems and design flaws and relative little interest from users. (not that it has a lot today). But enough reviewers thought that it had potential to be useful if it's issues were addressed. I don't know that these experiences are typical. But it seems to me that very few Boost libraries have significant users before being proposed for inclusion in boost.
Must we resign ourselves to the indignity of statements like "I don't see anything wrong with an author seeking acceptance in Boost as a way to acquire users?"
I don't think it's sad at all. Seems to me like its the traditional way of doing things. One needs the Boost imprimatur to get any users at all. Robert Ramey
On Mon, Oct 9, 2023 at 8:00 AM Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Sun, Oct 8, 2023 at 4:41 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Boost has never required a library to have users in order to be accepted. If the review process says it's good, it's good. ... Or stated differently, the proper and only way to express your opinion on whether the library belongs in Boost or not is by submitting a review.
What I am saying is that I believe the author knows the library would not get users on its own and this is why there was no effort to acquire them.
That's not the case. C++ desperately needs a library like this, and there's a reason cppcoro got very popular. I got 82 stars & 128 unique clones so far. The review and its announcement of course got some attention. I am probably excluding users by requiring boost, and could get more by making it optional. We surely disagree on that, but I obviously think my library is great and will attract users, especially younger ones that do not love callbacks as much as you. But you can be very sure, that I am absolutely confident that this library would get users without being in boost and I would urge you not to assume these kinds of motives.
On Sun, Oct 8, 2023 at 6:27 PM Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> wrote:
...I obviously think my library is great and will attract users, especially younger ones that do not love callbacks as much as you.
Okay, that's fair. So in which places where callbacks are currently used, does this library offer the alternative? Thanks
But you can be very sure, that I am absolutely confident that this library would get users without being in boost and I would urge you not to assume these kinds of motives.
Why not get them then? Have you reached out to any of the forks? Do you have a channel where people outside the Boost community came to visit while you worked on the lib? Did you announce the development of the lib on Reddit so people could follow and weigh in? Did you find other projects that might benefit from using your library, and offer them a pull request where you integrate your library as an example to show them how it can be improved with your library? In other words was any there any effort placed into Boost.Klemens.Async other than the bare minimum of what is required to write a library which is to just sit down and over a continuous or intermittent period and simply write it unassisted and without input, and then submit it for a review? And let me ask you this, now that I have taken the time to elaborate in sufficient detail additional methodologies and markers of success which may be applied to library development, what do you think should be done with that information? Speaking for myself if I had done the same with one of my libraries, without going to reddit first, without announcing it first, without shopping it around to other projects to see what they think, without offering to integrate it, without constantly pestering Peter (or Chris, if he answered messages) for advice on how I can design my library to be better, and just carried on developing in a vacuum, then just collect it up and plop it down on the mailing list telling everyone else to review it and shove it into Boost because "we have to put it in Boost because it is great and young people don't like callbacks" - I don't think I would feel very good or proud about that. Now that I've said all that, does any of that resonate with you? Does it inspire you and make you want to do more, so your library can be the absolute best it can be? Is it too much work to do these things? Do you care about setting an example for others? Or perhaps you just know that your library is so great, that these things are not necessary, and want to signal to future potential library authors that if they, too, are confident that their library is "great and will attract users, especially young ones" that there is no need to push themselves to do more when more can be done. Thanks
On Mon, Oct 9, 2023 at 9:50 AM Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Sun, Oct 8, 2023 at 6:27 PM Klemens Morgenstern <klemensdavidmorgenstern@gmail.com> wrote:
...I obviously think my library is great and will attract users, especially younger ones that do not love callbacks as much as you.
Okay, that's fair. So in which places where callbacks are currently used, does this library offer the alternative?
All of them.
Thanks
But you can be very sure, that I am absolutely confident that this library would get users without being in boost and I would urge you not to assume these kinds of motives.
Why not get them then? Have you reached out to any of the forks? Do you have a channel where people outside the Boost community came to visit while you worked on the lib? Did you announce the development of the lib on Reddit so people could follow and weigh in? Did you find other projects that might benefit from using your library, and offer them a pull request where you integrate your library as an example to show them how it can be improved with your library? In other words was any there any effort placed into Boost.Klemens.Async other than the bare minimum of what is required to write a library which is to just sit down and over a continuous or intermittent period and simply write it unassisted and without input, and then submit it for a review?
Where do you get the unassisted from?
And let me ask you this, now that I have taken the time to elaborate in sufficient detail additional methodologies and markers of success which may be applied to library development, what do you think should be done with that information? Speaking for myself if I had done the same with one of my libraries, without going to reddit first, without announcing it first, without shopping it around to other projects to see what they think, without offering to integrate it, without constantly pestering Peter (or Chris, if he answered messages) for advice on how I can design my library to be better, and just carried on developing in a vacuum, then just collect it up and plop it down on the mailing list telling everyone else to review it and shove it into Boost because "we have to put it in Boost because it is great and young people don't like callbacks" - I don't think I would feel very good or proud about that.
Well, boost::asio::experimental::coro is the result of me pestering chris.
Now that I've said all that, does any of that resonate with you? Does it inspire you and make you want to do more, so your library can be the absolute best it can be? Is it too much work to do these things? Do you care about setting an example for others? Or perhaps you just know that your library is so great, that these things are not necessary, and want to signal to future potential library authors that if they, too, are confident that their library is "great and will attract users, especially young ones" that there is no need to push themselves to do more when more can be done.
It really depends on the library I would say. Boost.async came out of 2.5y or working with asio::awaitable and a bunch of workarounds like a `select` that were used by a five person team. Then I wrote asio::experimental::coro, which fulfilled a similar need, gets used and goes as far as that can within asio (with it's requirements). Add to that my experience with python & javascript and real world use cases of their async facilities Hence I feel confident in the design. If I just wrote async without any of the history before you would have a point. So I'd think it depends on the library, just like you said. Boost.json would have been fine to review without any users I reckon.
It's quite a stretch to say C++ desperately needs Async. I've shipped C++ apps using Asio and I can safely say I've never desperately needed a library like this. I kind of agree with Vinnie, no users, not enough tests. This is an alpha library and should come back when its place in the ecosystem has solidified. - Christian
On Sun, Oct 8, 2023 at 7:21 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
I kind of agree with Vinnie, no users, not enough tests. This is an alpha library and should come back when its place in the ecosystem has solidified.
I have to be fair though, the reality is that I cannot back up my claims with strong evidence and it is in fact based only on observation during the library's development of the repository and Slack interactions. So it is very possible that Klemens' is right and there is more to it than I am describing. This is one reason why I did not write a review. Another reason is that I am preoccupied with personal issues which prevent me from really investing a lot of time and energy into anything C++ related (including my own new libraries whose development is paused). Mainly what I am saying is that I believe there is/was room to do more to prepare the library for the review, and these things weren't done. The only reason I bring it up for Klemens' specifically is because I care more about him, as we have been working together for a while now. But this advice is not just for Klemens', if there is a new library with the intention to be proposed for Boost and it makes sense to do so, it is nice to see authors pull out all the stops and do everything in their power to make the library great even before the review. More docs, more tests, more exposition, more explanation, more benchmarks, more reddit posts, more users, more consultations, more... MORE.. you feel me? I want ordinary C++ users to feel shock and awe at the level of preparation and attention to detail that goes into new library submissions. I want them to be inspired. To aspire to become more like Boost authors. Thanks
On 9. Oct 2023, at 09:27, oliver.kowalke--- via Boost <boost@lists.boost.org> wrote:
This is an alpha library and should come back when its >place in the ecosystem has solidified.
I disagree because this restriction was not required in the past. It seems to me unfair to make it mandatory now.
I am using Oliver's comment to add my own. Klemens obviously has a good amount of stars and forks, which signals interest from the community, so he does not need me to defend his proposal. But I also want to give my option on "should libraries proposed for adoption have many users already?". Whether or not a library has a lot of users before submission is fairly irrelevant. It can be a point in favour, but does not have to be. It may address the question "is this library useful"? but does not tell whether the library is well designed. Some people need a lot of user feedback to refine the design, others are good internal critics and can improve without external feedback. Both are valid approaches to design and suit different people. Obviously, everyone needs some external feedback, but it is quality and not quantity that matters. Also, we all know from politics and examples in tech, that popularity is not always a good measure of quality. Usefulness, design, quality, etc are judged by the reviewers. I have high confidence in the Boost reviewers to make this assessment. Users do not get to vote on acceptance, Boost members do. Boost is a meritocracy, not a democracy.
On 09/10/2023 10:12, Hans Dembinski via Boost wrote:
On 9. Oct 2023, at 09:27, oliver.kowalke--- via Boost <boost@lists.boost.org> wrote:
This is an alpha library and should come back when its >place in the ecosystem has solidified. I disagree because this restriction was not required in the past. It seems to me unfair to make it mandatory now. I am using Oliver's comment to add my own.
Klemens obviously has a good amount of stars and forks, which signals interest from the community, so he does not need me to defend his proposal. But I also want to give my option on "should libraries proposed for adoption have many users already?".
Whether or not a library has a lot of users before submission is fairly irrelevant. It can be a point in favour, but does not have to be. It may address the question "is this library useful"? but does not tell whether the library is well designed. Some people need a lot of user feedback to refine the design, others are good internal critics and can improve without external feedback. Both are valid approaches to design and suit different people. Obviously, everyone needs some external feedback, but it is quality and not quantity that matters.
Also, we all know from politics and examples in tech, that popularity is not always a good measure of quality.
Usefulness, design, quality, etc are judged by the reviewers. I have high confidence in the Boost reviewers to make this assessment. Users do not get to vote on acceptance, Boost members do. Boost is a meritocracy, not a democracy.
+1. Also just to add to that, existing libraries with wide user bases come with a legacy that may may it harder for them to make radical improvements to the user interface should that be required. On the other hand brilliant interface design with no user experience also carries it's risks. This is what reviews are for, to balance all this up, and it's good to see some discussion being generated again. It's also worth pointing out that Boost when founded was a place for radical bleeding edge design and experimentation, I see no reason for it not still be so as long as such libraries are well documented as such. With apologies, I'll now go back to lurking again, as I have no knowledge of the problem domain... John.
On 09/10/2023 16:01, John Maddock via Boost wrote:
On 09/10/2023 10:12, Hans Dembinski via Boost wrote:
On 9. Oct 2023, at 09:27, oliver.kowalke--- via Boost <boost@lists.boost.org> wrote:
This is an alpha library and should come back when its >place in the ecosystem has solidified. I disagree because this restriction was not required in the past. It seems to me unfair to make it mandatory now. I am using Oliver's comment to add my own.
Klemens obviously has a good amount of stars and forks, which signals interest from the community, so he does not need me to defend his proposal. But I also want to give my option on "should libraries proposed for adoption have many users already?".
Whether or not a library has a lot of users before submission is fairly irrelevant. It can be a point in favour, but does not have to be. It may address the question "is this library useful"? but does not tell whether the library is well designed. Some people need a lot of user feedback to refine the design, others are good internal critics and can improve without external feedback. Both are valid approaches to design and suit different people. Obviously, everyone needs some external feedback, but it is quality and not quantity that matters.
Also, we all know from politics and examples in tech, that popularity is not always a good measure of quality.
Usefulness, design, quality, etc are judged by the reviewers. I have high confidence in the Boost reviewers to make this assessment. Users do not get to vote on acceptance, Boost members do. Boost is a meritocracy, not a democracy.
+1. Also just to add to that, existing libraries with wide user bases come with a legacy that may may it harder for them to make radical improvements to the user interface should that be required. On the other hand brilliant interface design with no user experience also carries it's risks. This is what reviews are for, to balance all this up, and it's good to see some discussion being generated again.
It's also worth pointing out that Boost when founded was a place for radical bleeding edge design and experimentation, I see no reason for it not still be so as long as such libraries are well documented as such.
With apologies, I'll now go back to lurking again, as I have no knowledge of the problem domain...
Ah nothing like lots of post-review discussion to make the writing of the review report easier! (Apologies for replying to your reply John, yours was just the latest in the chain which is why I chose it) Firstly, I hope to complete writing the review conditions and report this Wednesday. I won't promise it, I set aside last Wednesday morning and then stuff came up and it didn't end up happening. But I'll keep retrying until I get it done. I apologise for the delay, I am doing my best. Secondly, please do not challenge the review until I've actually published the review conditions and report. This particular review currently has three major conditions in my draft report, and it may gain more before I'm done. If after its publishing then people feel it was a bad review, rock on with lodging challenges. Thirdly, I have no idea why Boost has become so conservative about new libraries recently. There is a long and proud tradition of Boost publishing crazy new libraries that so pushed the state of the art they didn't even compile on ANY compiler bar one compiled from trunk. They certainly by definition had ZERO users. We also used to - once upon a time - be comfortable with publishing a library, finding out after users complained it was badly flawed, so then we made a v2 of that library with all those problems fixed and quietly deprecated/discouraged the further use of the v1 library. And whilst not ideal, that's exactly how states of the art get pushed. Sure, it would be even better if a library had lots of users first, but there can be a chicken and egg problem for particularly radical libraries - until somebody solves a problem, nobody realises that that problem should be solved that way. Right now C++ coroutines have a bad rep in the C++ userbase, and they are currently quite unpopular as we saw from the Reddit reaction to the announcement of the review of this library. However that won't last, eventually the userbase will warm to using them where they solve well what they're good at solving well, and more importantly, not using them to solve what coroutines solve elsewhere, because C++ coroutines != coroutines elsewhere. I don't know if when people warm up to C++ coroutines they'll reach for proposed Boost.Async. If they do not, an equally beneficial outcome for Boost and/or the C++ ecosystem is if they make a new C++ coroutine library which incorporates the ideas from proposed Boost.Async but iterates on them. And if that happens, Boost will have enabled that, which is exactly what Boost is supposed to do. In this I'm seeing lots of upsides across the board. I also disagree that Boost gets hurt by experimental libraries which don't work out. Nobody using Boost will ever be forced to use proposed Boost.Async. If it doesn't work out, it will have literally zero negative effect on Boost users apart from a slightly longer download time. In my opinion, a much more likely outcome is that accepting new experimental libraries make watching Boost a must to see what comes. Most of the lurkers on here are here precisely because Boost can be a weather vane onto the future of C++. More experimental libraries makes Boost more relevant in my opinion, even if some will fail to gain traction. Without taking a risk, we would never know. Speaking personally, C++ coroutine programming is tedious and annoying with the current C++ coroutine library frameworks. Proposed Boost.Async restores much of the fun and joy in writing C++, albeit with tradeoffs, but nothing comes for free. At my last job we had a set of custom completion tokens for ASIO which implemented a very similar solution to proposed Boost.ASIO. At my current job I just finished up last week C++ coroutine support which - surprise surprise - looks awfully like proposed Boost.Async again (except these are based on io_uring and use Niall's "much improved" Sender-Receiver design which WG21 rejected). I think there are only a very few of us with sufficient domain expertise in this area to be able to judge whether proposed Boost.Async is a solid generalised solution to this problem domain. I don't claim to be one of them, but having implemented something similar twice now, and having been "in the room" throughout WG21's labours on Sender-Receiver and ASIO, even though WG21 rejected almost everything I said or proposed I would like to think I am less misguided than they are :) Even if I am very misguided, I think accepting this library is worth the punt. It'll be an accept with conditions, and the report will be long as there will be a short list of binding conditions and a long list of non-binding conditions. I'll get it to you all when I can. Niall
On Mon, Oct 9, 2023 at 9:57 AM Niall Douglas via Boost < boost@lists.boost.org> wrote:
Ah nothing like lots of post-review discussion to make the writing of the review report easier!
Thank you for your well thought-out message. There are some good points there. I do wish that there was more documentation and wisdom collated from mailing lists posts regarding the review process. You brought up a lot of informal guide rails, why aren't we committing this to an asciidoc document on the website? Regards
On 09/10/2023 18:00, Vinnie Falco wrote:
On Mon, Oct 9, 2023 at 9:57 AM Niall Douglas via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Ah nothing like lots of post-review discussion to make the writing of the review report easier!
Thank you for your well thought-out message. There are some good points there. I do wish that there was more documentation and wisdom collated from mailing lists posts regarding the review process. You brought up a lot of informal guide rails, why aren't we committing this to an asciidoc document on the website?
As with everything Boost, I would guess nobody has to date sat down and written out the documentation? I think I was the last person to substantially refactor the documentation page on the review process? The one before I did that had been there for years, didn't actually match the review process, and everybody here agreed it needed fixing but nobody had stepped up to do it. I did at the time, after a few people here checked my new text now matched reality (at that time) it was merged and to my best knowledge, nobody has substantially improved upon those docs since then. And that was many years ago now. Documentation can always be improved of course, but getting the right people to do it is always the hard part. Niall
On Mon, Oct 9, 2023 at 10:23 AM Niall Douglas via Boost < boost@lists.boost.org> wrote:
nobody has substantially improved upon those docs since then.
And that was many years ago now. Documentation can always be improved of course, but getting the right people to do it is always the hard part.
We have a repository for the new website docs: https://github.com/cppalliance/site-docs And we have a dedicated Staff Writer, Peter Turcan, who maintains this. So if one or more members of the community would like to start this review process doc, even if it is just copying and pasting select quotes from the mailing list (like some of the things in your previous message), it is a start, and Peter can work on filling that out (he might be asking questions if necessary). The logical place to put this information would be in the "Boost Formal Reviews" documentation which is located here in the new website: https://www.preview.boost.org/doc/formal-reviews/index.html The Antora source (which holds the table of contents and individual asciidoc pages) is here: https://github.com/cppalliance/site-docs/tree/develop/formal-reviews/modules... The #boost-docs channel in the Official C++ Slack Workspace ( https://cpplang.slack.com, email me for an invite) is where Peter toils and responds to the community if you want to drop in and have a chat. Thanks Vinnie
Sent from my iPad
On 9 Oct 2023, at 06:21, Christian Mazakas via Boost <boost@lists.boost.org> wrote:
It's quite a stretch to say C++ desperately needs Async. I've shipped C++ apps using Asio and I can safely say I've never desperately needed a library like this.
I kind of agree with Vinnie, no users, not enough tests. This is an alpha library and should come back when its place in the ecosystem has solidified.
“No users” is a false assertion.
- Christian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
“No users” is a false assertion.
Sure, I'll admit I was wrong. I just remember seeing a user on slack try out Async during the first review period and it immediately segfaulted during a client SSL handshake so I assumed there was no one using this library in production. Or rather, no users with a vested financial stake were using it in an environment where it mattered. As a runtime author, you basically can't write enough tests for this kind of code. I would've advised running Async's `use_op` over an existing Asio codebase/app before being accepted but eh. - Christian
I did learn from NodeJS and it was good at the time as it helped to push people for something better. However I also learnt from Boost.Asio, Boost.Coroutine, Boost.Context, Boost.Asio, and plenty of members inside and outside Boost's community. Honestly, NodeJS just got stuck in time. It can't hope to grow more than it already did. If you provide a complete copy of NodeJS inside C++ so NodeJS programmers can come over, what is it that you'll offer for them to come here? They already have NodeJS. You need a differentiating factor.
I am convinced by this.
You shouldn't be, because this is not an accurate description of my library.
If I were reviewing the library now, after what I have learned from this thread, my recommendation would have been to reject the library for now, as it was the case when Boost was young, on the grounds that the programming model and the scope is not clear. It is still not clear to me, "when I should use this library". My best approximation is "when I already use Boost.ASIO (directly or indirectly) and I find its (ASIO's) interface too clumsy".
Can you elaborate on what changed your mind exactly? Libraries like this need a scheduler, boost.fiber has one, too. In the case of boost.fiber it's much more elaborate, which I don't consider necessary for async. Hence it just uses a generic scheduler that's already in boost: boost::asio::any_io_executor. A nice side effect of that is that users CAN use asio directly with that on a single thread, but that's not a necessity. They can also plugin their own awaitables, that have nothing to do with asio. I got two examples of that 1. co-awaiting a boost.signal2 https://github.com/klemens-morgenstern/async/blob/master/example/signals.cpp 2. co-awaiting an spsc-queue https://github.com/klemens-morgenstern/async/blob/master/example/spsc.cpp The latter does use two functions from the asio namespace, that should probably be pulled into the async namespace. Note that both functions are related to boost::asio::any_io_executor. Now, let's say you got five threads producing values and pushing them out into an spsc-queue. So you got five event sources that now need to feed a state machine. You can model that with async and since the co-await will already make sure that all is running on a single thread, it'll be much easier to write & maintain. I hope that makes sense.
niedz., 8 paź 2023 o 22:03 Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> napisał(a):
I did learn from NodeJS and it was good at the time as it helped to push people for something better. However I also learnt from Boost.Asio, Boost.Coroutine, Boost.Context, Boost.Asio, and plenty of members inside and outside Boost's community. Honestly, NodeJS just got stuck in time.
can't hope to grow more than it already did. If you provide a complete copy of NodeJS inside C++ so NodeJS programmers can come over, what is it
It that
you'll offer for them to come here? They already have NodeJS. You need a differentiating factor.
I am convinced by this.
You shouldn't be, because this is not an accurate description of my library.
If I were reviewing the library now, after what I have learned from this thread, my recommendation would have been to reject the library for now, as it was the case when Boost was young, on the grounds that the programming model and the scope is not clear. It is still not clear to me, "when I should use this library". My best approximation is "when I already use Boost.ASIO (directly or indirectly) and I find its (ASIO's) interface too clumsy".
Can you elaborate on what changed your mind exactly?
As indicated in my original review, I have small experience with asynchronous computations, so to some extent I have to rely on things like intuition or trust in other experts' opinions. Vinnie's description "C++ needs coroutine libraries, this is a coroutine library, so let's have it" correctly addresses my attitude. This is not a criticism of your library, rather of my attitude. I am not particularly proud of it, but I must admit this is the case. And this clouded my judgement. Now that other peoples' critical opinions cooled my enthusiasm, I realise that the concerns I raised as conditions for acceptance are more serious. I believe a Boost.Library should have a solid design that is reflected in its documentation. That is, not only should it be solid, but you also should demonstrate it (in the docs). I am missing this from reading the docs. The choice of names (promise, task), the concepts that I cannot grasp after hours of struggling (spawning, interrupting, detaching), the parts of the design of generator that you admit may make no sense (eager value consuming generator), this all is a signal for me that the library might not have a solid design. I may be wrong about this, of course, but I would rather err on the safe side, and hence my decision. I understand the recommendation to reject as saying, "do not accept the library in its current shape, give the author the time, guidance and opportunity to come back with the improved design." I now think that unclear design is too serious for conditional acceptance. Libraries like this need a scheduler, boost.fiber has one, too. In the
case of boost.fiber it's much more elaborate, which I don't consider necessary for async. Hence it just uses a generic scheduler that's already in boost: boost::asio::any_io_executor. A nice side effect of that is that users CAN use asio directly with that on a single thread, but that's not a necessity. They can also plugin their own awaitables, that have nothing to do with asio.
I understand that an async library needs a scheduler. The docs say, "async uses an asio::io_context as its default event loop" which implies that it can be used with other event loops. You give two examples
I got two examples of that
1. co-awaiting a boost.signal2
https://github.com/klemens-morgenstern/async/blob/master/example/signals.cpp 2. co-awaiting an spsc-queue https://github.com/klemens-morgenstern/async/blob/master/example/spsc.cpp
The latter does use two functions from the asio namespace, that should probably be pulled into the async namespace. Note that both functions are related to boost::asio::any_io_executor.
Now, let's say you got five threads producing values and pushing them out into an spsc-queue. So you got five event sources that now need to feed a state machine. You can model that with async and since the co-await will already make sure that all is running on a single thread, it'll be much easier to write & maintain. I hope that makes sense.
I must admit they are too complicated for me. But let me ask a question instead. If I am using my own event loop in my project, how do I adapt it, so that it is usable with Boost.Async? I do not expect an explanation in this distribution list. I would expect an answer in the docs. I am not that much concerned about the user base, or novelty, or the number of reviews. But it is this lack of certainty that the design is solid and stable. My apologies for not indicating it earlier. I guess I feel uncomfortable recommending a rejection after the author spent so much time developing the library, fine tuning it and answering all my questions. I hope that this reply makes sense. Regards, &rzej;
Am 02.10.2023 um 18:23 schrieb Klemens Morgenstern via Boost:
What would be a genuine asynchronous coroutine library? asynchronous in my lingo means that the coroutine might suspend to an asynchronous event source, e.g. a timer expiring. This is my lingo, but is how other languages that provide an async keyword do it, too.
So if I were to call std::coroutine_handle<some_async_coro>::resume() I can't assume it's done (reached a yield or a return) when resume returns. This is different from a synchronous coroutine like std::generator, where the .resume() will only occur after a value has been yielded or the generator returned.
There is a difference between asymmetric/symmetric coroutine-like control-transfer - see 'P0876: fiber_context - fibers without scheduler'.
Racket does have preemptive fibers which are interrupted asynchronously (much like Golang's goroutines), but coroutines are not fibers. The Lisp community already learned this lesson:
The difference between a fibers facility and just coroutines is that with fibers, you have a scheduler as well. Well, then what I call an async coroutine, is a conceptual fiber implemented via coroutines. I say conceptual, because boost.fiber and the paper you cite below use an entirely different API from what my coroutines do.
There are two kinds of coroutine-like operations - stackful and stackless ops. The C++-20 coroutines are stackless (not realy because some memory has to be allocated to hold the local variables that would usally be stored in the stack frame). The other C++ coroutine-like stackful option has been named 'fiber' by the C++ standards committee (proposal P0876: fiber_context - fibers without scheduler). (C++)-Fibers are asymmetric stackful coroutines implemented by boost.context that do not require a scheduler. boost.fiber is a library using the C++-fibers from boost.context and implements a kind of userland threads (including a scheduler).
https://wingolog.org/archives/2018/05/16/lightweight-concurrency-in-lua
We have some of the best experts in this domain in our own community, and a few of them spared the time just on this topic as well:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf
The least we should do is to at least take the time to listen. I would like to point out that the paper does compare the author's coroutine paper to their fiber paper. It does not compare fibers (since it was written in 2014) to the coroutines standardized in C++20, and thus also provide no await mechanism.
I am pretty sure both had a different vision than what we got, and the dichotomy between fibers & coroutines in this paper arose from their idea of how to separate the concepts.
The paper is deprecated in vafour of P0876. As mentioned above - you have to distinguish between stackless/stackful and symmetric/asymmetric control flow (as described in P0876). Oliver
On Mon, Oct 2, 2023 at 7:40 AM Niall Douglas via Boost <boost@lists.boost.org> wrote:
Seeing as nobody here has raised this concern to date, can I confirm everybody here is fine with proposed Boost.Async being called Boost.Async?
I don't like it at all and I agree with the "land grab" concern. I was hoping this library would be rejected and the naming would be a non-issue. There were only what, 2 reviews?
If you are not, please suggest a preferred alternative name.
Certainly, the naming of a library plays a significant role in its perception and utility. Here are ten alternative names that aim to be specific and descriptive, while avoiding a "land grab": Boost.Coroutinify Boost.Asiotasker Boost.CoAsio Boost.Yielder Boost.AwaitIO Boost.AsioGen Boost.FiberAsync Boost.Eventuals Boost.TaskifyAsio Boost.CoroutineX Choosing a name that resonates with both the functionality and the ethos of the library can be a delightful challenge. Happy coding! --- The ChatGPT-4 prompt which produced the above: A boost library is proposed which is based on Boost.Asio and C++20 coroutines, and calls itself Boost.Async because it provides generators, tasks, and promises to facilitate coroutine implementations. A reviewer has raised the concern that the name Boost.Async constitutes a naming "Land grab" as it is too generic. Propose 10 other names for this library which are not generic. Thanks
On 02/10/2023 17:18, Vinnie Falco wrote:
On Mon, Oct 2, 2023 at 7:40 AM Niall Douglas via Boost <boost@lists.boost.org> wrote:
Seeing as nobody here has raised this concern to date, can I confirm everybody here is fine with proposed Boost.Async being called Boost.Async?
I don't like it at all and I agree with the "land grab" concern. I was hoping this library would be rejected and the naming would be a non-issue. There were only what, 2 reviews?
I believe the current count is six reviews, and two sets of detailed notes which are most of a review each. More than enough. All recommend acceptance incidentally. My work will be to condense the conditions into a feasible set for Klemens to work upon. I see no current reason why it won't be an accept, just with conditions. It's not too late for a review from you or Richard if you have strong feelings that the library ought to be rejected?
If you are not, please suggest a preferred alternative name.
Certainly, the naming of a library plays a significant role in its perception and utility. Here are ten alternative names that aim to be specific and descriptive, while avoiding a "land grab":
Boost.Coroutinify Boost.Asiotasker Boost.CoAsio Boost.Yielder Boost.AwaitIO Boost.AsioGen Boost.FiberAsync Boost.Eventuals Boost.TaskifyAsio Boost.CoroutineX
Choosing a name that resonates with both the functionality and the ethos of the library can be a delightful challenge. Happy coding!
---
The ChatGPT-4 prompt which produced the above:
A boost library is proposed which is based on Boost.Asio and C++20 coroutines, and calls itself Boost.Async because it provides generators, tasks, and promises to facilitate coroutine implementations. A reviewer has raised the concern that the name Boost.Async constitutes a naming "Land grab" as it is too generic. Propose 10 other names for this library which are not generic.
Clever GPT. Niall
On Mon, Oct 2, 2023 at 9:30 AM Niall Douglas via Boost <boost@lists.boost.org> wrote:
It's not too late for a review from you or Richard if you have strong feelings that the library ought to be rejected?
I don't have enough knowledge or experience with C++20 coroutines to be able to write a solid review but I believe there is a pattern of hastily written libraries being proposed for Boost which have reasonable implementations but not well thought out designs or extensive field testing. I am also concerned that coroutines are "in style" and there is a tendency for less seasoned reviewers to rubber-stamp anything related to them. However I lack sufficient evidence to lay this all out in a thoughtful way and thus I remain silent. If this library is accepted we might consider it an experiment to see if my concerns are needless. And allow sufficient time to pass before we review another hastily written library. Thanks
pon., 2 paź 2023 o 18:51 Vinnie Falco via Boost <boost@lists.boost.org> napisał(a):
On Mon, Oct 2, 2023 at 9:30 AM Niall Douglas via Boost <boost@lists.boost.org> wrote:
It's not too late for a review from you or Richard if you have strong feelings that the library ought to be rejected?
I don't have enough knowledge or experience with C++20 coroutines to be able to write a solid review but I believe there is a pattern of hastily written libraries being proposed for Boost which have reasonable implementations but not well thought out designs or extensive field testing. I am also concerned that coroutines are "in style" and there is a tendency for less seasoned reviewers to rubber-stamp anything related to them. However I lack sufficient evidence to lay this all out in a thoughtful way and thus I remain silent. If this library is accepted we might consider it an experiment to see if my concerns are needless. And allow sufficient time to pass before we review another hastily written library.
Thanks for saying this Vinnie. I share the concern. I disagree with your decision, though, to refrain from the review because you think you lack domain knowledge. This is what the review question "how knowledgeable are you in the problem domain" is for. I fit into your description of a "less seasoned reviewer", so I just mention this in the review, and still make my contribution. This works as long as the reviews are not treated as votes. Regards, &rzej;
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
pon., 2 paź 2023 o 18:30 Niall Douglas via Boost <boost@lists.boost.org> napisał(a):
On 02/10/2023 17:18, Vinnie Falco wrote:
On Mon, Oct 2, 2023 at 7:40 AM Niall Douglas via Boost <boost@lists.boost.org> wrote:
Seeing as nobody here has raised this concern to date, can I confirm everybody here is fine with proposed Boost.Async being called Boost.Async?
I don't like it at all and I agree with the "land grab" concern. I was hoping this library would be rejected and the naming would be a non-issue. There were only what, 2 reviews?
I believe the current count is six reviews, and two sets of detailed notes which are most of a review each. More than enough.
All recommend acceptance incidentally. My work will be to condense the conditions into a feasible set for Klemens to work upon.
I see no current reason why it won't be an accept, just with conditions.
I know that you know it, but let me still reiterate here the rules of the Boost Review process for the benefit of all the people reading this list. The review manager makes the decision whether to accept or reject the library based on their discretion. The recommendations from the reviewers are only means to help guide this decision. No democracy or averaging of the reviews is at play. For instance, I mentioned in the review that I have a superficial knowledge of the C++ coroutines, and I expect my recommendation to be weighed accordingly. Regards, &rzej;
It's not too late for a review from you or Richard if you have strong feelings that the library ought to be rejected?
If you are not, please suggest a preferred alternative name.
Certainly, the naming of a library plays a significant role in its perception and utility. Here are ten alternative names that aim to be specific and descriptive, while avoiding a "land grab":
Boost.Coroutinify Boost.Asiotasker Boost.CoAsio Boost.Yielder Boost.AwaitIO Boost.AsioGen Boost.FiberAsync Boost.Eventuals Boost.TaskifyAsio Boost.CoroutineX
Choosing a name that resonates with both the functionality and the ethos of the library can be a delightful challenge. Happy coding!
---
The ChatGPT-4 prompt which produced the above:
A boost library is proposed which is based on Boost.Asio and C++20 coroutines, and calls itself Boost.Async because it provides generators, tasks, and promises to facilitate coroutine implementations. A reviewer has raised the concern that the name Boost.Async constitutes a naming "Land grab" as it is too generic. Propose 10 other names for this library which are not generic.
Clever GPT.
Niall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 02/10/2023 20:24, Andrzej Krzemienski wrote:
I believe the current count is six reviews, and two sets of detailed notes which are most of a review each. More than enough.
All recommend acceptance incidentally. My work will be to condense the conditions into a feasible set for Klemens to work upon.
I see no current reason why it won't be an accept, just with conditions.
I know that you know it, but let me still reiterate here the rules of the Boost Review process for the benefit of all the people reading this list. The review manager makes the decision whether to accept or reject the library based on their discretion. The recommendations from the reviewers are only means to help guide this decision. No democracy or averaging of the reviews is at play.
Very true. However, as I've often said in the past, the review feedback is in my opinion much more valuable than getting a library in or not. High quality feedback on software design is rare and valuable in any context, Boost remains a uniquely high quality source of such feedback. Speaking more widely, I've now had one REJECT review, and a few more expressing negativity about the design and naming. This will make it interesting trying to write a useful summary. I hope to get the review summary written and posted for the end of this week. Non-work life is busy, I built half a solar panel array last weekend (and my muscles remain very sore from it), and non-work time this week is mostly going into visiting glazing showrooms. I'll see if I can find a few hours to collate the reviews. Niall
On Mon, Oct 2, 2023 at 9:18 AM Vinnie Falco <vinnie.falco@gmail.com> wrote:
If you are not, please suggest a preferred alternative name.
Twenty more: Boost.CoroMate Boost.AsioWave Boost.AsyncFusion Boost.PromiseIO Boost.AsioFlow Boost.Awaitables Boost.CoroutineSphere Boost.GenTasks Boost.IOPromise Boost.ASyncor Boost.EvolveAsync Boost.Corollary Boost.AwaitSphere Boost.TaskWave Boost.CoroutineCraft Boost.AsyncNest Boost.AwaitFusion Boost.CoRoutineHub Boost.Genio (Generator + Asio) Boost.ElasticAsync Thanks
On Mon, Oct 2, 2023, 18:31 Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Mon, Oct 2, 2023 at 9:18 AM Vinnie Falco <vinnie.falco@gmail.com> wrote:
If you are not, please suggest a preferred alternative name.
Twenty more:
Boost.CoroMate Boost.AsioWave Boost.AsyncFusion Boost.PromiseIO Boost.AsioFlow Boost.Awaitables Boost.CoroutineSphere Boost.GenTasks Boost.IOPromise Boost.ASyncor Boost.EvolveAsync Boost.Corollary Boost.AwaitSphere Boost.TaskWave Boost.CoroutineCraft Boost.AsyncNest Boost.AwaitFusion Boost.CoRoutineHub Boost.Genio (Generator + Asio) Boost.ElasticAsync
Boost.Awaitables? Regards, &rzej;
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, 2 Oct 2023 at 18:31, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Mon, Oct 2, 2023 at 9:18 AM Vinnie Falco <vinnie.falco@gmail.com> wrote:
If you are not, please suggest a preferred alternative name.
Twenty more:
Boost.CoroMate Boost.AsioWave Boost.AsyncFusion Boost.PromiseIO Boost.AsioFlow Boost.Awaitables Boost.CoroutineSphere Boost.GenTasks Boost.IOPromise Boost.ASyncor Boost.EvolveAsync Boost.Corollary Boost.AwaitSphere Boost.TaskWave Boost.CoroutineCraft Boost.AsyncNest Boost.AwaitFusion Boost.CoRoutineHub Boost.Genio (Generator + Asio) Boost.ElasticAsync
I miss the days when libraries and useful programs are given terse names that were fun and easy to remember. biff, mutt, vi, sed etc spring to mind.
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/2/23 11:26 AM, Richard Hodges via Boost wrote:
I miss the days when libraries and useful programs are given terse names that were fun and easy to remember.
biff, mutt, vi, sed etc spring to mind.
I certainly don't. As my memory deteriorates, I'm less enamored with cleverness for it's own sake than I used to be. e.g. I have no idea what mutt and etc are.
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Le lundi 02 octobre 2023 à 20:26 +0200, Richard Hodges via Boost a écrit :
On Mon, 2 Oct 2023 at 18:31, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
I miss the days when libraries and useful programs are given terse names that were fun and easy to remember.
biff, mutt, vi, sed etc spring to mind.
Well, if we're going for fun, then i dare to propose Boost.ACE, which would stand for Asio Coroutine Extensions. That being said, the doc misses a requirements section. I'm still not sure if asio is a strict requirement or not. Regards, Julien
Well, if we're going for fun, then i dare to propose Boost.ACE, which would stand for Asio Coroutine Extensions.
Well that I could live with.
That being said, the doc misses a requirements section. I'm still not sure if asio is a strict requirement or not.
It is a hard dependency, because writing my own scheduler seemed unreasonable. I'll add a requiremenst section (https://github.com/klemens-morgenstern/async/issues/126).
Regards,
Julien
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 3 Oct 2023, at 09:04, Klemens Morgenstern via Boost <boost@lists.boost.org> wrote:
Well, if we're going for fun, then i dare to propose Boost.ACE, which would stand for Asio Coroutine Extensions.
Well that name may work, but it is sort of a throw-off for me as I am old enough to know about the Adaptive Communication Environment (ACE): https://www.dre.vanderbilt.edu/~schmidt/ACE.html As ACE address related in problem domains, and as it still is live and kicking in its own corners of the C++ world, such a name choice begs the question of what the relation is. So for what it is worth, to me that name is taken to mean something else. Sorry. Also, without having had time to review the proposed Boost.Async as closely as I would like to form an opinion on acceptance. I have read the docs and I was really hoping the ASIO dependency was more of a backend issue in need of executors. If so, adding ASIO in its name is perhaps a poor choice. — Bjørn
On Tue, Oct 3, 2023 at 3:35 PM Bjørn Roald <bjorn.roald@gmail.com> wrote:
On 3 Oct 2023, at 09:04, Klemens Morgenstern via Boost < boost@lists.boost.org> wrote:
Well, if we're going for fun, then i dare to propose Boost.ACE, which would stand for Asio Coroutine Extensions.
Well that name may work, but it is sort of a throw-off for me as I am old enough to know about the Adaptive Communication Environment (ACE):
The ADAPTIVE Communication Environment (ACE) <https://www.dre.vanderbilt.edu/~schmidt/ACE.html> dre.vanderbilt.edu <https://www.dre.vanderbilt.edu/~schmidt/ACE.html> [image: favicon.ico] <https://www.dre.vanderbilt.edu/~schmidt/ACE.html> <https://www.dre.vanderbilt.edu/~schmidt/ACE.html>
As ACE address related in problem domains, and as it still is live and kicking in its own corners of the C++ world, such a name choice begs the question of what the relation is. So for what it is worth, to me that name is taken to mean something else. Sorry.
Absolutely fair point. This is why naming is hard. And for me `async` is associated with the async keyword in other languages, that do something quite similar.
Also, without having had time to review the proposed Boost.Async as closely as I would like to form an opinion on acceptance. I have read the docs and I was really hoping the ASIO dependency was more of a backend issue in need of executors. If so, adding ASIO in its name is perhaps a poor choice.
It is. asio's any_io_executor is a pretty good polymorphic executor, that can run on any event loop (e.g. Qt). I even have an example in async which is using python's asyncio event loop instead of asio's. I think many users remember the early days of asio, when everything was directly dependent on asio's io_context and thus think my dependency means you'll get all of asio included. A lot has happened, and asio contains the proposed standard executors, which is the part async is depending on.
— Bjørn
Em seg., 2 de out. de 2023 às 13:18, Vinnie Falco via Boost < boost@lists.boost.org> escreveu:
Certainly, the naming of a library plays a significant role in its perception and utility. Here are ten alternative names that aim to be specific and descriptive, while avoiding a "land grab":
Boost.Coroutinify Boost.Asiotasker Boost.CoAsio Boost.Yielder Boost.AwaitIO Boost.AsioGen Boost.FiberAsync Boost.Eventuals Boost.TaskifyAsio Boost.CoroutineX
I like the name AwaitIO for what Klemens had developed. FiberAsync is definitely a no. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
Niall Douglas wrote:
I have received a non-public review which raises concerns about the naming land grab by proposed Boost.Async i.e. a Boost library called "Async" claims too much through its name.
Seeing as nobody here has raised this concern to date, can I confirm everybody here is fine with proposed Boost.Async being called Boost.Async?
If you are not, please suggest a preferred alternative name.
Niall
Boost.Asio.Async, or similar. I'd make a similar argument for other libraries that are highly dependent on ASIO. Regards, Phil.
I think Vinnie eloquently put into words my thoughts as well. When I saw on slack that when someone tried an early version of Async and it immediately segfaulted when trying to do a client SSL handshake, I realized the library has seen exactly zero production usage by any real financial stakeholders. I agree with Vinnie's assessment that the library seems hastily written and I'd call it under-tested. Or at least, it was then. Note, I don't call it a coroutine library because it doesn't contain any primitives one would use to write a runtime. Instead, it _is_ a runtime which is something different altogether. Even worse, it's an opinionated runtime favoring I/O workloads and it brings conditional dependencies on Container which I feel ultimately harms it. I haven't formalized my rejection but in similar thoughts as Vinnie's, I'm not opposed to acceptance because I'd be curious if it gains any real users by being included in Boost and who knows, maybe people will actually like it. Note, I've shipped applications written in Asio and I'm also the author of my own coroutine I/O runtime built on top of io_uring so I know both domains well. I don't see much of an onus to ever use Async over Asio but clearly other Asio users do so I'd be curious to see how this library fares. - Christian
On Mon, Oct 2, 2023 at 11:18 AM Christian Mazakas via Boost <boost@lists.boost.org> wrote:
I'd be curious if it gains any real users by being included in Boost and who knows, maybe people will actually like it..
I have mixed feelings about this. One the one hand Boost is supposed to be slightly more relaxed than LEWG with respect to new additions to the collection. But in my opinion, the acceptance of this library is effectively saying to the public that the Boost community of reviewers believes the public interface and intended use-case of the library follows what we believe to be best practices and state of the art for C++ coroutines. Is it, however? I don't know, as I am not a subject matter expert, but I don't think that accepting to answer that question just by "shoving it into Boost" is healthy. Boost.Beast, Boost.JSON, Boost.URL all had users outside the Boost community well before any reviews took place. I would argue that Boost.JSON was so similar to previous popular works that it wasn't that meaningful but Beast and URL are sufficiently novel in their public interfaces that it could not and should not have been taken for granted that they should be accepted without some users. Not all Boost libraries need this, only some. For example Boost.Charconv is essentially already vetted since it is based on an established API. I don't speak for Boost and I am relatively new compared to some folks that have been around from the beginning, so I am unsure whether my criteria about seeing some field experience for this particular library is important. Perhaps someone who has been involved in Boost longer than me and is more familiar with the unwritten rules of the review process can offer clarity on this point.
It's not too late for a review from you or Richard if you have strong feelings that the library ought to be rejected?
I do not believe I have sufficient emotional, mental, and technical resources to write a review for this library at a level of quality that represents Boost's reputation and the interests of the invested parties fairly. All I have are these thoughts, which are not sufficient to arrive at a simple accept or reject conclusion. Other people will need to decide if and what importance to place on it. I'm okay with any outcome. Thanks
I completely share this concern. Even Asio claims to be "Async I/O" with its name, which is less specific than "Async 'Anything'". And this library is more specific than Asio. Not more generic. If I saw some library named "Async" on github, I wouldn't be expecting only Async I/O. I'd be expecting introductory examples showing me how to calculate π using my GPU the best it can without any references to coroutines or I/O, which would be optional. Or how to train my AI model using a GPU cluster. Or how to optimize a function using all of my computer's processing power. *And* some examples involving I/O. It wouldn't have that single-thread limitation, either. Even if it's a bad idea for some use cases because the branding makes a promise to cover all cases. To be clear, the limitation might be OK because it's justified for the use case. Only the relationship with the name seems problematic. Also to be clear, I'm not saying we need these libraries to help me work with GPUs. I don't have a good alternative because identifying a problem with a name is much easier than coming up with good names, let alone good names that Klemens would like. But I can say I like names like Boost.CoAsio better than Boost.Async. It clearly describes that it's about coroutine extensions for Asio. And we do need some Asio extensions because Asio involves lots of concepts and their concrete implementations don't always fit in Boost.Asio or Boost.Beast. Em seg., 2 de out. de 2023 às 11:39, Niall Douglas via Boost < boost@lists.boost.org> escreveu:
Dear Boost,
I have received a non-public review which raises concerns about the naming land grab by proposed Boost.Async i.e. a Boost library called "Async" claims too much through its name.
Seeing as nobody here has raised this concern to date, can I confirm everybody here is fine with proposed Boost.Async being called Boost.Async?
If you are not, please suggest a preferred alternative name.
Niall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Alan Freitas https://alandefreitas.github.io/alandefreitas/ <https://github.com/alandefreitas>
On Tue, Oct 3, 2023 at 5:06 AM Alan de Freitas via Boost <boost@lists.boost.org> wrote:
I completely share this concern. Even Asio claims to be "Async I/O" with its name, which is less specific than "Async 'Anything'". And this library is more specific than Asio. Not more generic.
If I saw some library named "Async" on github, I wouldn't be expecting only Async I/O.
Well, my idea is to have more libraries in the future, e.g. async.gpu or async.http, and hopefully not only written by me personally. The current async is essentially supposed to be async.core if you will. I actually would like to have an async.io library too, that simplifies using sockets and papes and would be an actual asio wrapper.
I'd be expecting introductory examples showing me how to calculate π using my GPU the best it can without any references to coroutines or I/O, which would be optional. Or how to train my AI model using a GPU cluster. Or how to optimize a function using all of my computer's processing power. *And* some examples involving I/O. It wouldn't have that single-thread limitation, either. Even if it's a bad idea for some use cases because the branding makes a promise to cover all cases.
Does it? The limitation is that multi-threading must be explicit, i.e. you can't co_await accross threads. But you can use spawn & async::thread to do cross threads. You basically already have an async.thread minimodule, which could have additional utilities for multi-threading.
To be clear, the limitation might be OK because it's justified for the use case. Only the relationship with the name seems problematic. Also to be clear, I'm not saying we need these libraries to help me work with GPUs.
I don't have a good alternative because identifying a problem with a name is much easier than coming up with good names, let alone good names that Klemens would like. But I can say I like names like Boost.CoAsio better than Boost.Async. It clearly describes that it's about coroutine extensions for Asio.
I don't like asio in the name. async is using asio, yes, but that's because it needs an event loop & cancellation. asio provides a polymorphic executor (which you can use with anything really) so it would be stupid to throw that away and prevent users from using all the asio and asio-based libraries just to be pure. But conceptually async relies on what were the Proposed Standard Executors (https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/std_executors.html) and the cancellation Slots Chris added since (the latter could be replaced by a custom implementation without issues - there just isn't a reason to do so). Async provides seamless integration into the rest of asio through use_op. So I don't think categorizing async as an asio extension or wrapper is entirely accurate. But I get it, asio is so huge these days, it should maybe be more than one library. Regarding other names (let's say co_async): Let's say we build a boost.async based sql library? Isn't boost.async.sql much better than boost.co_asio.sql ? or should that be boost.co_sql? I thought that we could have boost.async.sql here. Especially since the already existing asio based libraries (beast, mysql, redis) Neither use async nor asio in their name. I get it's a bit of a generic name, but it's hardly a land grab. This is homesteading.
And we do need some Asio extensions because Asio involves lots of concepts and their concrete implementations don't always fit in Boost.Asio or Boost.Beast.
On Mon, Oct 2, 2023 at 10:40 PM Niall Douglas via Boost <boost@lists.boost.org> wrote:
Dear Boost,
I have received a non-public review which raises concerns about the naming land grab by proposed Boost.Async i.e. a Boost library called "Async" claims too much through its name.
I wrote a few things in responses and thought it might be good to summarize my thoughts here, as not everyone will read through lengthy discussions. 1. ASYNC The name async is meant to homestead the async name for sure, so we can have other coroutine based modules like async.io, async.http (hopefully working with a future http-proto) and async.mysql etc. This is based on other languages using `async` as a keyword. The asio-based libraries in boost at this moment are beast, mysql & redis. None of those have asio in their name. Redis was aedis, to clarify it's async, but I thought this was bad for searches and proposed Marcelo to change it. That combined with the fact that no one has yet claimed async, made it seem like a good choice, especially if we can have simplified apis for the already existing asio-compatible libraries as async.redis and async.mysql, maybe a low-level io library, called async.io and async.process. That is, the name boost.async would mean C++20 coroutines based. I am unsure if the criticism of the name is that it implies too much (i.e. it should include the above-mentioned modules already) or if it implies to be something different (like a generic async completion solution, akin to asio's completion tokens). If it is the former, this library is probably boost.async.core. Which would be an alright name, but I would expect for all the types to still be in the boost::async namespace, so I don't see the point. An alternative I am not too fond of would be to use the `co_` prefix, as it is the prefix of the coroutine keywords, e.g. making this library `co_async` or just `co`. Then other coroutine libraries could be `co_mysql` etc. I would also like to note that other good names are already taken, such as boost.coroutine. And naming this library boost.coro or something would be much worse than async, because it's ambiguous and would also promise too much. Also note that there is nothing related to IO in this library itself. 2. TASK/PROMISE Since we're bikeshedding already, I might as well throw in the names task & promise which came up during review. It might be cultural, but the implied eager & laziness is obvious to me. Tasks get scheduled, promises should get fulfilled without scheduling. E.g. if you lend me your drill and I promise to return it, that should happen without you asking (i.e. co_awaiting) it. If you give a company the task to paint your fence, you'd expect that to be scheduled. There is of course an issue with promise, as the internal coroutine state is using the same name. The std::packaged_task is a way to create a lazy future. std::promise is the way to create a lazy future, it's just callback based. std::future thus can be both, lazy or eager, depending how it was created. Which is why I opted not to use it. The solution Niall opted for is eager & lazy. I don't like adjectives as class names (similarly I don't like asio::awaitable) because that's a property of a thing. So imo they should be concepts or traits (e.g. is_eager), which is the case with async::awaitable. This could of course be because my native language, german, is big on nouns. boost.context uses "fiber" for the lazy and "continuation" for the eager types. Which makes sense, but `contiunation<T>` would look off to me, because it doesn't continue a T.
Am 03.10.2023 um 07:52 schrieb Klemens Morgenstern via Boost:
1. ASYNC
The name async is meant to homestead the async name for sure, so we can have other coroutine based modules like async.io, async.http (hopefully working with a future http-proto) and async.mysql etc. This is based on other languages using `async` as a keyword.
The asio-based libraries in boost at this moment are beast, mysql & redis. None of those have asio in their name. Redis was aedis, to clarify it's async, but I thought this was bad for searches and proposed Marcelo to change it. That combined with the fact that no one has yet claimed async, made it seem like a good choice, especially if we can have simplified apis for the already existing asio-compatible libraries as async.redis and async.mysql, maybe a low-level io library, called async.io and async.process. That is, the name boost.async would mean C++20 coroutines based. I am unsure if the criticism of the name is that it implies too much (i.e. it should include the above-mentioned modules already) or if it implies to be something different (like a generic async completion solution, akin to asio's completion tokens). If it is the former, this library is probably boost.async.core. Which would be an alright name, but I would expect for all the types to still be in the boost::async namespace, so I don't see the point. +1 An alternative I am not too fond of would be to use the `co_` prefix, as it is the prefix of the coroutine keywords, e.g. making this library `co_async` or just `co`. Then other coroutine libraries could be `co_mysql` etc. I would also like to note that other good names are already taken, such as boost.coroutine. And naming this library boost.coro or something would be much worse than async, because it's ambiguous and would also promise too much.
+1
2. TASK/PROMISE
The solution Niall opted for is eager & lazy. I don't like adjectives as class names (similarly I don't like asio::awaitable) because that's a property of a thing. So imo they should be concepts or traits (e.g. is_eager), which is the case with async::awaitable. +1 boost.context uses "fiber" for the lazy and "continuation" for the eager types. Which makes sense, but `contiunation<T>` would look off to me, because it doesn't continue a T.
boost.context uses 'fiber_context' as requested by the C++ standards committee (proposal P0876: fiber_context - fibers without scheduler). It provides an asymmetric, stackful coroutine-like operation - in contrast to this C++20-coroutines are symmetric and stackless. boost.context provides an additonal API `callcc/continuation' (call-with-current-continuation) - it is based on the Scheme call/cc and is deprecated. The `continuation< T >`is a suspended stack with preserved registers. Oliver
On 03/10/2023 06:52, Klemens Morgenstern wrote:
The solution Niall opted for is eager & lazy. I don't like adjectives as class names (similarly I don't like asio::awaitable) because that's a property of a thing. So imo they should be concepts or traits (e.g. is_eager), which is the case with async::awaitable.
That's not quite accurate. In Outcome I used: `boost::outcome::awaitables::eager<T>` `boost::outcome::awaitables::lazy<T>` The enclosing namespace `awaitables` I think is rather important to the naming choices of "eager" and "lazy". Niall
I emphatically support the name ACE or just Ace for this library as: Asio Coroutine Extensions. This perfectly describes the library and is a nice short name that's unique and pops. One thing I don't understand, the authors insists that Asio is just here for its event loop and cancellation but if you look at the docs, like 80% of Ace's interface contains `boost::asio::` in it. I also wanted to mention that I think I saw a signature that accepted `io_context::executor` when it should just be `asio::any_executor`. This seems to be based on the notion that Asio's executors will someday make it into the standard but that ship has already sailed and no matter what we think, Sender/Receiver are most likely going to be the future of execution in standard C++. I think, in general, Ace should attempt to hide as much of Asio as it physically can. Right now, this library exists in an odd middleground. It's too entrenched in Asio for non-Asio users to really use and if you are an Asio user, Chris is already implementing like 90% of the proposed functionality here in its experimental namespace. - Christian
On Tuesday, October 3, 2023, Christian Mazakas wrote:
I emphatically support the name ACE or just Ace for this library
Not so great for those of us who remember the original ACE C++ libraries: http://www.dre.vanderbilt.edu/~schmidt/ACE.html Glen
On Tue, Oct 3, 2023, 10:14 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
I emphatically support the name ACE or just Ace for this library as: Asio Coroutine Extensions.
This perfectly describes the library and is a nice short name that's unique and pops.
One thing I don't understand, the authors insists that Asio is just here for its event loop and cancellation but if you look at the docs, like 80% of Ace's interface contains `boost::asio::` in it.
Those two statements are unrelated. 80% of things just need an event loop and cancellation support. I also wanted to mention that I think I saw a signature that accepted
`io_context::executor` when it should just be `asio::any_executor`.
Which function was that?
This seems to be based on the notion that Asio's executors will someday make it into the standard but that ship has already sailed and no matter what we think, Sender/Receiver are most likely going to be the future of execution in standard C++.
I dont think we will get either standardized. Until i am proven wrong, asio is the best pick for an event loop.
I think, in general, Ace should attempt to hide as much of Asio as it physically can. Right now, this library exists in an odd middleground.
Why? Why is hiding things an ideal?
It's too entrenched in Asio for non-Asio users to really use and if you are an Asio user, Chris is already implementing like 90% of the proposed functionality here in its experimental namespace.
In which way is this too entrenched? Please provide some specifics. The only thing that supports symmetric transfer in asio is the experimental::coro. Nothing else, so all synchronization utilities must go through an executor.
- Christian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Christian Mazakas wrote:
This perfectly describes the library and is a nice short name that's unique and pops. It would also be another naming land grab - ACE: https://www.dre.vanderbilt.edu/~schmidt/ACE.html ACE used to be *the* library for much of what asio now provides ...
- Espen
participants (21)
-
Alan de Freitas -
Andrey Semashev -
Andrzej Krzemienski -
Bjørn Roald -
Christian Mazakas -
Emil Dotchevski -
Espen Harlinn -
Glen Fernandes -
Hans Dembinski -
John Maddock -
Julien Blanc -
Klemens Morgenstern -
Niall Douglas -
Oliver Kowalke -
oliver.kowalke＠gmail.com
-
Peter Dimov -
Phil Endecott -
Richard Hodges -
Robert Ramey -
Vinnie Falco -
Vinícius dos Santos Oliveira