Date: Tue, 17 May 2022 11:23:05 +0000
Hi Inbal,
Thank you for the summary. I notice that you quoted my comments from earlier in this discussion. Fortunately, my concerns have been assuaged by subsequent author feedback.
Best regards,
Peter
From: Lib-Ext <lib-ext-bounces_at_[hidden]> On Behalf Of Inbal Levi via Lib-Ext
Sent: 17 May 2022 12:07
Hello all,
Thank you for your input! to summarize this thread:
We have 9 (+1), but also 2 (-1).
Main concerns are about precormance, lack of implementation experience, and how (and weather) this will affect real-world applications:
1. I'd also like to see a discussion of the performance implications. As I understand it, the sync_with_stdio mechanism is one part of the poor performance associated with iostreams.
Why will the same consequence not apply here?
2. I would like to hear about:
* actual real-world application problems caused by the current {fmt} and Rust behaviour
* implementation experience of the proposed change, and especially measurements of performance impact in representative usage scenarios.
I think it would be most helpful for the author to add a paragraph addressing the performance overhead (+ benchmarks), before our last LEWG electronic poll period, if possible. Considering the reservations, I would bring it up with chairs to see how we proceed.
Best regards,
Inbal Levi
On Tue, 10 May 2022 at 19:44, Inbal Levi <sinbal2l_at_[hidden]<mailto:sinbal2l_at_[hidden]>> wrote:
Yes, you're right, thank you Mark & Barry. Sorry again about that typo, the correction was lost in the thread.
Re-adding the mid-discussion data so that we'll have everyone on the same page:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Let's reopen this review with the new revision, R1, proposing wording for synchronizing std::print with the underlying stream:
P2539R1: Should the output of std::print to a terminal be synchronized with the underlying stream? (wg21.link/P2539<https://urldefense.com/v3/__http:/wg21.link/P2539r1__;!!EHscmS1ygiU1lA!A_oyxO-AOAoM8pc5kDqmW7nsBippSlf-WxJ-dYgKmvxLUZKJVEr-9FGv6jUBS7YmOe7WAkZXDjZot9WtSFU$>)
by: Victor Zverovich
Please vote +1 for supporting moving this change forward for C++23.
***
From the Discussion:
To prevent mojibake std::print may use a native Unicode API when writing to a terminal bypassing the stream buffer. During the review of [P2093]<https://urldefense.com/v3/__http:/www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2539r0.html*biblio-p2093__;Iw!!EHscmS1ygiU1lA!A_oyxO-AOAoM8pc5kDqmW7nsBippSlf-WxJ-dYgKmvxLUZKJVEr-9FGv6jUBS7YmOe7WAkZXDjZopSD-bXk$> "Formatted output" Tim Song suggested that synchronizing std::print with the underlying stream may be beneficial for gradual adoption.
Some meta data:
· Bottom Line: Although the issue appears to be mostly theoretical, it might still be beneficial to clarify in the standard that synchronization is desired. Neither {fmt} ([FMT]) nor Rust ([RUST-STDIO]) do such synchronization in their implementations of print.
· To indicate your opinion on whether a change is needed (reasoning is, of course, welcome):
o If you support the status quo (no change): please response with "No Change"
o If you support making the change for C++23 (synchronize the output with the underlying steam): please response "+1"
***
Weekly reviews improve quality!
Running weekly reviews allows more iterations on each proposal, which hopefully, in turn, will result in more accurate and subtle fixes.
Thank you for taking the time to review the proposal,
and have a great week!
Inbal Levi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Tue, 10 May 2022 at 18:33, Barry Revzin <barry.revzin_at_[hidden]<mailto:barry.revzin_at_[hidden]>> wrote:
On Tue, May 10, 2022 at 10:17 AM Mark Hoemmen <mark.hoemmen_at_[hidden]<mailto:mark.hoemmen_at_[hidden]>> wrote:
It looks like P2549R0's title is "std::unexpected<E> should have
error() as member accessor" -- on the original question, though, I
would vote +1, since I would want new introductions of std::print into
existing code to interoperate correctly.
mfh
Yeah it's supposed to be P2539 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2539r1.html<https://urldefense.com/v3/__https:/www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2539r1.html__;!!EHscmS1ygiU1lA!A_oyxO-AOAoM8pc5kDqmW7nsBippSlf-WxJ-dYgKmvxLUZKJVEr-9FGv6jUBS7YmOe7WAkZXDjZody6xb_8$>). The original email got this right, just the subject had a typo. This is why it's good to always include the title (thanks, Inbal!) so it's obvious which paper we're discussing (which, in this case, clearly the std::print synchronization one with just the wrong number... rather than the unexpected one with the wrong title). Very difficult to typo the whole title. The keys aren't exactly right next to each other...
Barry
Thank you for the summary. I notice that you quoted my comments from earlier in this discussion. Fortunately, my concerns have been assuaged by subsequent author feedback.
Best regards,
Peter
From: Lib-Ext <lib-ext-bounces_at_[hidden]> On Behalf Of Inbal Levi via Lib-Ext
Sent: 17 May 2022 12:07
Hello all,
Thank you for your input! to summarize this thread:
We have 9 (+1), but also 2 (-1).
Main concerns are about precormance, lack of implementation experience, and how (and weather) this will affect real-world applications:
1. I'd also like to see a discussion of the performance implications. As I understand it, the sync_with_stdio mechanism is one part of the poor performance associated with iostreams.
Why will the same consequence not apply here?
2. I would like to hear about:
* actual real-world application problems caused by the current {fmt} and Rust behaviour
* implementation experience of the proposed change, and especially measurements of performance impact in representative usage scenarios.
I think it would be most helpful for the author to add a paragraph addressing the performance overhead (+ benchmarks), before our last LEWG electronic poll period, if possible. Considering the reservations, I would bring it up with chairs to see how we proceed.
Best regards,
Inbal Levi
On Tue, 10 May 2022 at 19:44, Inbal Levi <sinbal2l_at_[hidden]<mailto:sinbal2l_at_[hidden]>> wrote:
Yes, you're right, thank you Mark & Barry. Sorry again about that typo, the correction was lost in the thread.
Re-adding the mid-discussion data so that we'll have everyone on the same page:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Let's reopen this review with the new revision, R1, proposing wording for synchronizing std::print with the underlying stream:
P2539R1: Should the output of std::print to a terminal be synchronized with the underlying stream? (wg21.link/P2539<https://urldefense.com/v3/__http:/wg21.link/P2539r1__;!!EHscmS1ygiU1lA!A_oyxO-AOAoM8pc5kDqmW7nsBippSlf-WxJ-dYgKmvxLUZKJVEr-9FGv6jUBS7YmOe7WAkZXDjZot9WtSFU$>)
by: Victor Zverovich
Please vote +1 for supporting moving this change forward for C++23.
***
From the Discussion:
To prevent mojibake std::print may use a native Unicode API when writing to a terminal bypassing the stream buffer. During the review of [P2093]<https://urldefense.com/v3/__http:/www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2539r0.html*biblio-p2093__;Iw!!EHscmS1ygiU1lA!A_oyxO-AOAoM8pc5kDqmW7nsBippSlf-WxJ-dYgKmvxLUZKJVEr-9FGv6jUBS7YmOe7WAkZXDjZopSD-bXk$> "Formatted output" Tim Song suggested that synchronizing std::print with the underlying stream may be beneficial for gradual adoption.
Some meta data:
· Bottom Line: Although the issue appears to be mostly theoretical, it might still be beneficial to clarify in the standard that synchronization is desired. Neither {fmt} ([FMT]) nor Rust ([RUST-STDIO]) do such synchronization in their implementations of print.
· To indicate your opinion on whether a change is needed (reasoning is, of course, welcome):
o If you support the status quo (no change): please response with "No Change"
o If you support making the change for C++23 (synchronize the output with the underlying steam): please response "+1"
***
Weekly reviews improve quality!
Running weekly reviews allows more iterations on each proposal, which hopefully, in turn, will result in more accurate and subtle fixes.
Thank you for taking the time to review the proposal,
and have a great week!
Inbal Levi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Tue, 10 May 2022 at 18:33, Barry Revzin <barry.revzin_at_[hidden]<mailto:barry.revzin_at_[hidden]>> wrote:
On Tue, May 10, 2022 at 10:17 AM Mark Hoemmen <mark.hoemmen_at_[hidden]<mailto:mark.hoemmen_at_[hidden]>> wrote:
It looks like P2549R0's title is "std::unexpected<E> should have
error() as member accessor" -- on the original question, though, I
would vote +1, since I would want new introductions of std::print into
existing code to interoperate correctly.
mfh
Yeah it's supposed to be P2539 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2539r1.html<https://urldefense.com/v3/__https:/www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2539r1.html__;!!EHscmS1ygiU1lA!A_oyxO-AOAoM8pc5kDqmW7nsBippSlf-WxJ-dYgKmvxLUZKJVEr-9FGv6jUBS7YmOe7WAkZXDjZody6xb_8$>). The original email got this right, just the subject had a typo. This is why it's good to always include the title (thanks, Inbal!) so it's obvious which paper we're discussing (which, in this case, clearly the std::print synchronization one with just the wrong number... rather than the unexpected one with the wrong title). Very difficult to typo the whole title. The keys aren't exactly right next to each other...
Barry
Received on 2022-05-17 11:23:12