From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30560 invoked by alias); 11 May 2006 06:08:40 -0000 Received: (qmail 30551 invoked by uid 22791); 11 May 2006 06:08:38 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 11 May 2006 06:08:36 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1Fe4Le-0002Ka-Ea for gdb@sources.redhat.com; Thu, 11 May 2006 10:08:32 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1Fe4LQ-0002Hf-6u; Thu, 11 May 2006 10:08:16 +0400 From: Vladimir Prus To: Bob Rossi Subject: Re: asynchronous MI output commands Date: Thu, 11 May 2006 08:58:00 -0000 User-Agent: KMail/1.7.2 Cc: Alain Magloire , gdb@sources.redhat.com References: <3518719F06577C4F85DA618E3C37AB9105359CCA@nimbus.ott.qnx.com> <20060511023711.GB3727@brasko.net> In-Reply-To: <20060511023711.GB3727@brasko.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605111008.15930.ghost@cs.msu.su> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00123.txt.bz2 On Thursday 11 May 2006 06:37, Bob Rossi wrote: > > > It's hard to believe that response from MI can be useful without > > > knowing the > > > last issued command. Say, response from -data-evaluate-expression is > > > useless if you don't know what part of frontend wants that data -- > > > evaluating expression is used in many use cases. So, you need to > > > associate extra data with commands anyway. > > > > I agree, the example that comes to my mind is "next", "step", "finish", > > "continue" etc ... To do some optimization front-ends will probably need > > to know the last command issue (for example clearing all the variable > > state in a variable view for "continue"). > > I see the point, however, how do you know if the user typed continue? I > allow the user to have access to the console, and by doing so, I can't > make any assumptions on what GDB is doing. The "continue" command always produces *stopped response and that's mostly enough for frontend. > > > Maybe I'm mistaken but I have the impression, looking at the thread, some > > folks are confusing OOB and synchronous response that comes after issuing > > a command. > > I'm hopefull not confusing them, but maybe. For synchronous commands, I > just think it's a little ugly that you need the MI input command to > determine what an MI output command is. What do you mean by "determine what an MI output command is"? You certainly can parse the response into DOM-like tree without knowing the output command. If you want to create C data structures for each response, then yes, you'd need to know the exact type of the last command. But then, I'm not sure why you want to use C data structures. In KDevelop, the DOM is fully dynamic and that works just fine, for example: const GDBMI::Value& children = r["children"]; for (unsigned i = 0; i < children.size(); ++i) { QString exp = children[i]["exp"].literal(); If you have specific structures for each response this won't be very much simpler. > For asynchronous commands, there is simply no way to know what you are > looking at AFAIK. What exactly do you want to know that's not obtained from parse tree? - Volodya