From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3302 invoked by alias); 11 May 2006 10:48:08 -0000 Received: (qmail 3294 invoked by uid 22791); 11 May 2006 10:48:08 -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 10:48:06 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1Fe8i6-0003CD-Gy for gdb@sources.redhat.com; Thu, 11 May 2006 14:48:01 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1Fe8ho-00038S-Hv; Thu, 11 May 2006 14:47:40 +0400 From: Vladimir Prus To: Bob Rossi Subject: Re: asynchronous MI output commands Date: Thu, 11 May 2006 10:52:00 -0000 User-Agent: KMail/1.7.2 Cc: Alain Magloire , gdb@sources.redhat.com References: <3518719F06577C4F85DA618E3C37AB9105359CCA@nimbus.ott.qnx.com> <200605111008.15930.ghost@cs.msu.su> <20060511104034.GE3727@brasko.net> In-Reply-To: <20060511104034.GE3727@brasko.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605111447.37126.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/msg00130.txt.bz2 On Thursday 11 May 2006 14:40, Bob Rossi wrote: > > The "continue" command always produces > > > > *stopped > > > > response and that's mostly enough for frontend. > > OK, this isn't true. I used GDB CVS for this. Yea, I realized that "continue" not only does not produces "^running" but also does not produces "*stopped" right after posting. > > > > 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. > > Sorry, I've described this before, but apparently not good enough. I > definatly can create the abstract parse tree with out knowing the input > command. However, then I want to create C data structures for each > MI output. Why? With C data structures, the above frontend code will be only marginally simpler. - Volodya