From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21729 invoked by alias); 17 Jun 2019 19:52:18 -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 21544 invoked by uid 89); 17 Jun 2019 19:52:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=andre, consumer, H*r:sk:mailout, H*RU:sk:mailout X-HELO: mailout05.t-online.de Received: from mailout05.t-online.de (HELO mailout05.t-online.de) (194.25.134.82) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jun 2019 19:52:16 +0000 Received: from fwd17.aul.t-online.de (fwd17.aul.t-online.de [172.20.27.64]) by mailout05.t-online.de (Postfix) with SMTP id 74C6F4236037; Mon, 17 Jun 2019 21:52:13 +0200 (CEST) Received: from localhost (Xj9dLoZJrhovgXiNB77pif+G7v7OodphlUUTb4oMvJoDOgGLLeeBXeF6uZ19ICrgNe@[95.91.240.2]) by fwd17.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1hcxfj-0TFmam0; Mon, 17 Jun 2019 21:52:07 +0200 Date: Mon, 17 Jun 2019 19:52:00 -0000 From: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= To: Jan Vrany Cc: Tom Tromey , Jonah Graham , "gdb@sourceware.org" Subject: Re: MI3 and async notifications Message-ID: <20190617195212.GB1223@klara> 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: X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00043.txt.bz2 On Mon, Jun 17, 2019 at 11:53:14AM +0100, Jan Vrany wrote: > On Sat, 2019-06-15 at 08:34 -0600, Tom Tromey wrote: > > > > > > > "Jan" == Jan Vrany writes: > > > > Jan> as an user og GDB/MI (and frontent developer), I'd like to Jan> > > open a discussion about one aspect of MI that I'd like to change Jan> in > > MI3 before it is released into the wild. ... Jan> Emitting > > notifications unconditionally would simplify things a lot Jan> - again > > at least in my case. > > > > 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? Some "other (partial) MI consumer" here. And thank you for considering that possibility. 1. I also need to support a range of GDB versions (current lower limit is 7.4.1, but I guess I could bump that a bit if really needed) 2. Any kind of additional notification that does not change change sequencing or contents of messages of older versions sounds ok to me. 3. Output of gdb --version/show version, -list-features etc was in the past insufficient for me for feature discovery, so I typically use trial-and-error-and-fallback on some test input, or, in the areas where it is available, use the Python interface instead of MI. Insofar, I do not need backward compatibility in the sense that later versions need to continue to provide a specific feature, it's typically ok if a feature/command is either there or not. I believe completely removing features/command would be easier for me to handle than certain cases where there features only slightly change behaviour or need special setup to establish a "compatibility mode" or such. Andre'