From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104035 invoked by alias); 17 Jun 2019 12:14:16 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 104014 invoked by uid 89); 17 Jun 2019 12:14:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jun 2019 12:14:14 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D19C656068; Mon, 17 Jun 2019 08:14:12 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 87ukBdVYjQWX; Mon, 17 Jun 2019 08:14:12 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B2BA256067; Mon, 17 Jun 2019 08:14:12 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 1DBEB83923; Mon, 17 Jun 2019 08:14:12 -0400 (EDT) Date: Mon, 17 Jun 2019 12:14:00 -0000 From: Joel Brobecker To: Jan Vrany Cc: Tom Tromey , Jonah Graham , "gdb@sourceware.org" Subject: Re: MI3 and async notifications Message-ID: <20190617121412.GA4157@adacore.com> References: <70fdd9107d9bb3cee0a1a342aedc05bf3c8e9bae.camel@fit.cvut.cz> <871rzu9at0.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2019-06/txt/msg00037.txt.bz2 > > It seems like a good idea to me. I wonder if it makes sense to go even > > further and say there will only be async notifications for things like > > this. > > Yes, I thought the same initially. But then what about other existing MI > consumers? > > >From what I understood from Jonah's comments earlier, this would break (at least) > CDT. So CDT would either have to stick with MI2 (not great in a long > term) or refactor their code (not sure CDT guys would be happy to do > so, especially as - I presume - CDT needs to support wide range of GDB > versions already in the wild, a problem I do not have). > > While I personally agree with you and will be happy to go that far, > it'd break existing consumers - something that should IMO be carefully > discussed and planned. > > Adding a new option as I proposed as an alternative will be backward > compatible, indeed at the cost of more convoluted code in GDB itself. > > Is anyone from Emacs community around? Or any other MI consumers? My 2 cents: In my opinion, while I think upward compatibility is very important, it is also important to avoid having too many configurability options. Otherwise, we end up with a large number of options and the testing matrix, if we want to verify that they work well together, quickly explodes. In this case, because we have MI versions, and because the notification shouldn't be different from the data of the "^done" message, I think the incompatibility would be acceptable -- assuming existing parsers don't come back to say that it actually is a large effort for them to adapt. -- Joel