public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: "François Dumont" <frs.dumont@gmail.com>
To: Petr Ovtchenkov <ptr@void-ptr.info>
Cc: Jonathan Wakely <jwakely@redhat.com>,
	"libstdc++@gcc.gnu.org" <libstdc++@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: Make istreambuf_iterator::_M_sbuf immutable and add debug checks
Date: Thu, 16 Nov 2017 21:31:00 -0000	[thread overview]
Message-ID: <6b2a3bdf-ba21-27da-c222-80e00e75f3f6@gmail.com> (raw)
In-Reply-To: <20171116211239.5e2edec5@void-ptr.info>

On 16/11/2017 19:12, Petr Ovtchenkov wrote:
> On Thu, 16 Nov 2017 18:40:08 +0100
> François Dumont <frs.dumont@gmail.com> wrote:
>
>> On 16/11/2017 12:46, Jonathan Wakely wrote:
>>
>>> Let me be more clear: I'm not going to review further patches in this
>>> area while you two are proposing different alternatives, without
>>> commenting on each other's approach.
>>>
>>> If you think your solution is better than François's solution, you
>>> should explain why, not just send a different patch. If François
>>> thinks his solution is better than yours, he should state why, not
>>> just send a different patch.
>>>
>>> I don't have time to infer all that from just your patches, so I'm not
>>> going to bother.
>>>
>>>
>> Proposing to revert my patch doesn't sound to me like a friendly action
>> to start a collaboration.
> I'm already say that this is technical issue: this patch present only in
> trunk yet.
Doesn't explain why you want to revert it.
>   Series is more useful for applying in different branches.
Which branches ? There are mostly maintenance branches. None of your 
patches is fixing a bug so it won't go to a maintenance branch.
> BTW, https://gcc.gnu.org/ml/libstdc++/2017-11/msg00037.html
> was inspired by you https://gcc.gnu.org/ml/libstdc++/2017-10/msg00029.html
Which was already rejected, why submitting it again ?
>
>> So current implementation is
>> just fine to me and I'll let Petr argument for any change.
> Please, clear for me: what is the "current implementation"?
> Is it what we see now in trunk?
Yes. Other proposals were mostly code quality changes. None of them had 
no impact so Jonathan decision to keep current implementation is just fine.

  reply	other threads:[~2017-11-16 21:31 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-13 17:14 François Dumont
2017-10-23 19:08 ` François Dumont
2017-11-06 21:19   ` François Dumont
2017-11-16  5:52     ` Petr Ovtchenkov
2017-11-16 10:57       ` Jonathan Wakely
2017-11-16 11:46         ` Jonathan Wakely
2017-11-16 12:08           ` Petr Ovtchenkov
2017-11-16 17:40           ` François Dumont
2017-11-16 18:12             ` Petr Ovtchenkov
2017-11-16 21:31               ` François Dumont [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-09-27 20:16 Make tests less istreambuf_iterator implementation dependent François Dumont
2017-09-28 12:12 ` Jonathan Wakely
2017-09-28 19:59   ` François Dumont
2017-09-28 21:56     ` Jonathan Wakely
2017-10-02  5:43       ` François Dumont
2017-10-03 14:20         ` Jonathan Wakely
2017-10-04 16:21           ` François Dumont
2017-10-04 23:23             ` Jonathan Wakely
2017-11-15 20:52             ` [PATCH 1/4] Revert "2017-10-04 Petr Ovtchenkov <ptr@void-ptr.info>" Petr Ovtchenkov
2017-11-15 20:52               ` [PATCH 2/4] libstdc++: istreambuf_iterator keep attached streambuf Petr Ovtchenkov
2017-11-15 20:52                 ` [PATCH 3/4] libstdc++: avoid character accumulation in istreambuf_iterator Petr Ovtchenkov
2017-11-15 20:52                   ` [PATCH 4/4] libstdc++: immutable _M_sbuf " Petr Ovtchenkov
2017-11-15 21:31                   ` [PATCH 3/4] libstdc++: avoid character accumulation " Paolo Carlini
2017-11-16  5:32                     ` Petr Ovtchenkov
2017-11-16  9:39                       ` Paolo Carlini
2017-11-16 11:03                         ` Petr Ovtchenkov
2017-11-16 11:29                           ` Paolo Carlini
2017-11-16 11:41                             ` Petr Ovtchenkov
2017-11-16 11:51                               ` Paolo Carlini
2017-11-16 10:56               ` [PATCH 1/4] Revert "2017-10-04 Petr Ovtchenkov <ptr@void-ptr.info>" Jonathan Wakely
2017-11-16 11:35                 ` Petr Ovtchenkov
2017-11-16 11:39                   ` Jonathan Wakely
2017-11-16 11:40                     ` Jonathan Wakely
2017-11-16 11:57                     ` Petr Ovtchenkov
2017-09-23  7:10 [PATCH] libstdc++: istreambuf_iterator keep attached streambuf Petr Ovtchenkov
2017-09-25 13:46 ` Jonathan Wakely
2017-09-28 10:34 ` Jonathan Wakely
2017-09-28 12:06   ` Petr Ovtchenkov
2017-09-28 12:38     ` Jonathan Wakely
2017-10-03 20:39       ` Petr Ovtchenkov
2017-10-04  5:04         ` [PATCH v2] " Petr Ovtchenkov
2017-10-06 16:01         ` [PATCH] libstdc++: istreambuf_iterator proxy (was: keep attached streambuf) François Dumont
2017-10-06 18:00           ` Petr Ovtchenkov
2017-10-08 14:59             ` [PATCH] libstdc++: istreambuf_iterator proxy François Dumont
2017-10-09 19:32               ` Petr Ovtchenkov
2017-10-10  5:52               ` Petr Ovtchenkov
2017-10-10 14:21           ` [PATCH] libstdc++: istreambuf_iterator proxy (was: keep attached streambuf) Jonathan Wakely
2017-08-24 11:27 [PATCH] streambuf_iterator: avoid debug-dependent behaviour Petr Ovtchenkov
2017-08-29 20:02 ` François Dumont
2017-08-30  5:05   ` Petr Ovtchenkov
2017-08-31 20:30     ` François Dumont
2017-09-01  9:10 ` Jonathan Wakely
2017-09-07 21:02   ` François Dumont
2017-09-08  5:47     ` Petr Ovtchenkov
2017-09-08  6:15       ` François Dumont
2017-09-09 20:17       ` François Dumont
2017-09-21  5:46         ` François Dumont
2017-09-28 10:50           ` Jonathan Wakely
2017-09-28 10:58             ` Jonathan Wakely
2017-09-21 18:23   ` Petr Ovtchenkov
2017-09-25  9:34     ` Petr Ovtchenkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6b2a3bdf-ba21-27da-c222-80e00e75f3f6@gmail.com \
    --to=frs.dumont@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=ptr@void-ptr.info \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).