From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1630 invoked by alias); 8 May 2006 00:29:05 -0000 Received: (qmail 1622 invoked by uid 22791); 8 May 2006 00:29:05 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao01.cox.net (HELO eastrmmtao01.cox.net) (68.230.240.38) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 08 May 2006 00:29:03 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao01.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060508002900.IMCO17255.eastrmmtao01.cox.net@localhost.localdomain> for ; Sun, 7 May 2006 20:29:00 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1Fctd1-0004Wb-BI for gdb@sourceware.org; Sun, 07 May 2006 20:29:35 -0400 Date: Mon, 08 May 2006 01:22:00 -0000 From: Bob Rossi To: gdb@sourceware.org Subject: Re: asynchronous MI output commands Message-ID: <20060508002935.GN25114@brasko.net> References: <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> <20060507212711.GA18344@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060507212711.GA18344@nevyn.them.org> User-Agent: Mutt/1.5.9i 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/msg00072.txt.bz2 > > 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. OK. I start with the MI output. I use bison to convert that into an abstract parse tree. Now, I am working on a solution to take the abstract parse tree and turn it into a simple to use representation for the front end (ADT). I gave the example earlier, taking the abstract parse tree for -file-list-exec-source-file ^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c" and turn that into struct file_list_exec_source_file { int line; char *file; char *fullname; }; struct file_list_exec_source_file result = { 26, "test.c", "/home..."}; My goal is to do this for each MI output command. I would also like to make sure the manual reflects all the current MI commands, with the appropriate fields, and at the end, generate the documentation from this simple program (with ELI's help). BTW, this is all before I even try to implement the MI implementation into my front end, so that others can benefit from this work. Having a LISP or XML output from this program would be trivial and I'm sure would help others down the road. > 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. Yes, this is already done. > 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. Yes, I agree, if I knew the MI input command, I could use that to determine what type of command I was looking at. If I won't be allowed to add the command to the output record, then this is what I will do. However, I would like to be able to do this with out knowing the MI input command. First, it makes the code more modular that takes the MI output and turns it into something meaningful. Second, it's easy to gather a bunch of MI output commands from the test suite or from FE user's with FE problem, and parse just that output. Third, it validates that what the user requested is what the user is getting. It is possible that the FE and GDB could get mixed up I'm assumming. Anyways, Daniel, thanks for taking time out of your busy schedule to think about this issue. If you simply don't want something like this in MI right now, I'll find a way to match the input with the output. Bob Rossi