From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15409 invoked by alias); 6 May 2006 04:06:01 -0000 Received: (qmail 15047 invoked by uid 22791); 6 May 2006 04:05:59 -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; Sat, 06 May 2006 04:05:55 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FcE3F-0003ri-BY; Sat, 06 May 2006 00:05:53 -0400 Date: Sat, 06 May 2006 04:06:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org, gdb@sources.redhat.com Subject: Re: asynchronous MI output commands Message-ID: <20060506040553.GA14819@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org, gdb@sources.redhat.com References: <20060506012706.GA25114@brasko.net> <20060506015903.GA13095@nevyn.them.org> <20060506024902.GD25114@brasko.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060506024902.GD25114@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/msg00048.txt.bz2 On Fri, May 05, 2006 at 10:49:02PM -0400, Bob Rossi wrote: > OK, I could do this, and if that's the prefered way, then I will. The > only strange thing about it, is either I need to hack up the parser to > set a flag when it reaches that point, or I need to walk the parse tree > semi-deep to get that info. Do you still think that would be the > prefered way? Actually, I could just see if I ever get to the > async-record to determine if the command is asynchronous, right? I just don't understand what your goals and terms are here. The MI output syntax has a grammar, and the grammar has semantic information. One part of the grammar identifies what is synchronous and what is asynchronous. If your parser can't keep track of that information, then perhaps you should think a little more about what information you need from parsing - that's pretty much the point of having a parser. > I just happened to notice that -exec-next and -interpreter-exec console > next are surprisingly different. -interpreter-exec, essentially, is synchronous. This is subject to change. The interaction between multiple interpreters is very difficult. -- Daniel Jacobowitz CodeSourcery From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15039 invoked by alias); 6 May 2006 04:05:58 -0000 Received: (qmail 15031 invoked by uid 22791); 6 May 2006 04:05:57 -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; Sat, 06 May 2006 04:05:55 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FcE3F-0003ri-BY; Sat, 06 May 2006 00:05:53 -0400 Date: Sat, 06 May 2006 04:05:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org, gdb@sources.redhat.com Subject: Re: asynchronous MI output commands Message-ID: <20060506040553.GA14819@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org, gdb@sources.redhat.com References: <20060506012706.GA25114@brasko.net> <20060506015903.GA13095@nevyn.them.org> <20060506024902.GD25114@brasko.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060506024902.GD25114@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/msg00047.txt.bz2 Message-ID: <20060506040500.gTz_r26cclHkDSvZYB9MNmP_6dt1BETl3hY5b9xWVZo@z> On Fri, May 05, 2006 at 10:49:02PM -0400, Bob Rossi wrote: > OK, I could do this, and if that's the prefered way, then I will. The > only strange thing about it, is either I need to hack up the parser to > set a flag when it reaches that point, or I need to walk the parse tree > semi-deep to get that info. Do you still think that would be the > prefered way? Actually, I could just see if I ever get to the > async-record to determine if the command is asynchronous, right? I just don't understand what your goals and terms are here. The MI output syntax has a grammar, and the grammar has semantic information. One part of the grammar identifies what is synchronous and what is asynchronous. If your parser can't keep track of that information, then perhaps you should think a little more about what information you need from parsing - that's pretty much the point of having a parser. > I just happened to notice that -exec-next and -interpreter-exec console > next are surprisingly different. -interpreter-exec, essentially, is synchronous. This is subject to change. The interaction between multiple interpreters is very difficult. -- Daniel Jacobowitz CodeSourcery