From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113436 invoked by alias); 17 Jun 2019 21:50:50 -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 113426 invoked by uid 89); 17 Jun 2019 21:50:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=H*i:sk:a6128e1, H*f:sk:a6128e1, H*c:alternative X-HELO: pb-smtp20.pobox.com Received: from pb-smtp20.pobox.com (HELO pb-smtp20.pobox.com) (173.228.157.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jun 2019 21:50:47 +0000 Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 4A4D374DC0 for ; Mon, 17 Jun 2019 17:50:46 -0400 (EDT) (envelope-from jonah@kichwacoders.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=g3UG2Yq6RMcHm8Oar49F+UR9G4k=; b=QLFfjO eOdVGxD4kiD+7BHC8WaKIS0+yFMy64nStVgSDNC6Cf0NrjEUSf9Q6iAaxd+xZ9lP yXvMySaPFXazz+FmtRTm9zgqKA45k8S1MWtETExFlW+Tu1g+5JTcYCiySjj13XAU VIJuwGMjLn6at4se5Q/+ve+WduRBLCShhfGk4= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 4208174DBF for ; Mon, 17 Jun 2019 17:50:46 -0400 (EDT) (envelope-from jonah@kichwacoders.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=kichwacoders.com; h=mime-version:references:in-reply-to:from:date:message-id:subject:to:cc:content-type; s=mesmtp; bh=MS4V3Z1K3ZP4uCZl44avUMbGPQ6Rfcp0dDA70Zb5ev8=; b=Tx+qwbGjLzdOQoUSjbhbmej5t9PpU+oLtKoFGFV/kQtCAFyjaAAlY2cC4mffzMIjSWD+hZV55S3BYLApFV9I4a79HdtCMgfJ1WDfRehaRph4TZ/KJme7vhis6FAiIADY2V8znzzko1CPVqf5EzvyGnxXTrPqA4lsk9/fzMcyu/o= Received: from mail-qk1-f176.google.com (unknown [209.85.222.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id EE22574DBE for ; Mon, 17 Jun 2019 17:50:42 -0400 (EDT) (envelope-from jonah@kichwacoders.com) Received: by mail-qk1-f176.google.com with SMTP id b18so7208588qkc.9 for ; Mon, 17 Jun 2019 14:50:42 -0700 (PDT) MIME-Version: 1.0 References: <70fdd9107d9bb3cee0a1a342aedc05bf3c8e9bae.camel@fit.cvut.cz> <871rzu9at0.fsf@tromey.com> <20190617121412.GA4157@adacore.com> <20190617125638.GA6859@adacore.com> <20190617204515.GB6859@adacore.com> In-Reply-To: From: Jonah Graham Date: Mon, 17 Jun 2019 21:50:00 -0000 Message-ID: Subject: Re: MI3 and async notifications To: Jan Vrany Cc: Joel Brobecker , Tom Tromey , "gdb@sourceware.org" , =?UTF-8?B?QW5kcsOpIFDDtm5pdHo=?= X-Pobox-Relay-ID: F45C735C-9149-11E9-B992-B0405B776F7B-18936988!pb-smtp20.pobox.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00046.txt.bz2 On Mon, 17 Jun 2019 at 16:58, Jan Vrany wrote: > On Mon, 2019-06-17 at 16:45 -0400, Joel Brobecker wrote: > > > > Jonah, I was about to ask the same. I understand that you need to > know > > > > which breakpoint has been inserted by given command, but this > > > > if we respond with something like > > > > > > > > 1-break-insert main > > > > =breakpoint-created,bkpt={number="1",type=...} > > > > 1^done,bkpt-number=1 > > > > > > > > then you just search for breakpoint with that id, no? Given that MI > > > > guarantees that =breakpoint-created arrives before ^done reply to > command. > > > > Am I missing something? > > > > > > > > > > No you aren't missing anything. That would be a perfectly acceptable > > > solution for CDT. > > > > > > There would still be some other new logic needed for CDT, we would > > > still have to store all the =breakpoint-created if there is a > > > -break-insert active and then process all of them when the ^done is > > > received. However that seems fairly reasonable. > > > > Do we even need the bkpt-number=1 attribute in the "done" command? > > The notification includes that information, so the GUI should have > > enough info from there to determine which UI element to update, right? > > > > I think so. Imagine you have a UI with breakpoint list and there's > an "Add Breakpoint" button. When "Add Breakpoint" is pressed, user > fills location, press "OK", new breakpoint is added and > *UI pre-selects just added breakpoint*. This is IMO sensible UI behavior. > > Now, when you press "OK" to add the breakpoint on a location, behind the > scenes > frontend issues -break-insert command and waits for ^done confirmation. > But as Jonah mentioned, another breakpoint could be inserted meanwhile so > you'd get something like this on MI channel. > > 10-break-insert main > =breakpoint-created,bkpt={number="1",type=... from CLI or script>} > =breakpoint-created,bkpt={number="2",type=... just requested>} > =breakpoint-created,bkpt={number="3",type=... from CLI or script>} > 10^done > > Now, if ^done response would not contain bkpt-number=2 attribute, how > would you know which > is the breakpoint you need to pre-select in the UI? > > > Thanks Jan, that looks like a good example to show the problem.