From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31345 invoked by alias); 7 May 2006 21:27:18 -0000 Received: (qmail 31328 invoked by uid 22791); 7 May 2006 21:27:17 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 07 May 2006 21:27:13 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FcqmW-0004nt-13 for gdb@sourceware.org; Sun, 07 May 2006 17:27:12 -0400 Date: Sun, 07 May 2006 22:01:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: asynchronous MI output commands Message-ID: <20060507212711.GA18344@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: <20060506031435.GE25114@brasko.net> <17500.8198.679332.240864@farnswood.snap.net.nz> <20060506040637.GA14894@nevyn.them.org> <20060506114933.GF25114@brasko.net> <20060506152046.GA24267@nevyn.them.org> <20060506164030.GK25114@brasko.net> <20060506165249.GA25972@nevyn.them.org> <20060506194618.GL25114@brasko.net> <20060506203741.GA29439@nevyn.them.org> <20060507004518.GM25114@brasko.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060507004518.GM25114@brasko.net> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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/msg00067.txt.bz2 On Sat, May 06, 2006 at 08:45:18PM -0400, Bob Rossi wrote: > OK, with that information, I see it is impossible to tell just from > looking at the MI output, to determine if the command is synchronous > or not. Look below for a solution to this problem for me. What? ^done is a synchronous response, *stopped is an asynchronous response. There's not really any way of knowing whether a command might produce later asynchronous output. [Here we run into the limits of the current, mostly synchronous implementation.] > Hmmm. That's interesting, I was hoping to not need to know what the > input command was in order to parse and build an ADT for the output. In > general, I think it would be appropriate if the MI output described > itself well enough that no other information was needed to understand > it, including the MI intput command. What do you mean, in this context, by an ADT (and what does it mean to you)? And what information do you want to represent in your parse result? I think I need to understand what you want to get out of this data a little better. It seems to me that most of the work of an MI parser is in converting the RESULT rule to some more useful tree-like structure. You don't need to know what the data is to do that. If you want to create individual response structure types for each supported MI command, then you ought to know what command is being answered (see my mail a moment ago for why), and be able to convert the _abstract_ tree into an appropriate _concrete_ structure. -- Daniel Jacobowitz CodeSourcery