From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5701 invoked by alias); 20 Feb 2006 08:11:05 -0000 Received: (qmail 5692 invoked by uid 22791); 20 Feb 2006 08:11:04 -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; Mon, 20 Feb 2006 08:11:03 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1FB68J-0008Hr-QU for gdb@sources.redhat.com; Mon, 20 Feb 2006 11:11:00 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1FB68C-0008Hd-B2; Mon, 20 Feb 2006 11:10:53 +0300 From: Vladimir Prus To: Eli Zaretskii Subject: Re: MI: type prefixes for values Date: Mon, 20 Feb 2006 13:48:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb@sources.redhat.com References: <200602171724.03824.ghost@cs.msu.su> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602201110.50065.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-02/txt/msg00268.txt.bz2 On Friday 17 February 2006 21:59, Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Fri, 17 Feb 2006 17:24:03 +0300 > > Cc: gdb@sources.redhat.com > > > > > > - The parsing of that value will have to be done by ad-hoc code, > > > > which is contrary to MI-goal of being easily parsable. > > > > > > Why ad-hoc? if you have {}, parse it, if not, don't. Why is this > > > simple rule hard for a parser? > > > > Here's the relevant part from KDevelop: > > > > if (*start == '{') > > { > > // Gdb uses '{' in two cases: > > // - composites (arrays and structures) > > // - pointers to functions. In this case type is > > // enclosed in "{}". Not sure why it's so, as > > // when printing pointer, type is in parenthesis. > > if (type == typePointer) > > { > > // Looks like type in braces at the beginning. Strip it. > > start = skipDelim(start, '{', '}'); > > } > > else > > { > > // Looks like composite, strip the braces and return. > > return QCString(start+1, end - start -1); > > } > > I'd never suspect that someone would try to parse MI with such > ad-hoc'ish code. I assumed that a decent parser was being used, and > that this parser could simply choose the right template--either the > one for response with braces, or the one for without. > > With such one-character-at-a-time parsing of MI's output, I now > understand why you want MI to talk in small chunks. This code is okay > for parsing irregular streams such as what CLI produces, but that's not > the right way of dealing with structured data streams such as the one > produced by MI. You need a fairly general-purpose reader that would > create a data structure for what it reads and populate the structure's > members with what it finds in MI's output. Then you just pluck > whatever you need from that data structure. > > I really don't think that we should cater to such ``parsers''. They > need to be thrown away and rewritten, IMO. Eli, I'm disappointed by you making such broad statements based on no data. Had you looked at code: http://websvn.kde.org/branches/work/kdevelop-debugger-mi/mi/ http://websvn.kde.org/branches/work/kdevelop-debugger-mi/mi/gdbmi.h?rev=504799&view=markup you'd notice that a data structure is being created. And as I've already said in this thread: http://article.gmane.org/gmane.comp.gdb.devel/15652 the "breace-removing" code is specifically for removing uncessary data from "value" literals, which have no formal grammar. > > You see, if I strip everything {}-enclosed at the beginning of value, > > I'll never show any structures. And how do I decide if the value is a > > pointer, or structure? > > The same way a compiler's parser decides: by writing code that checks > the text against several templates and finding the one that matches. > I believe people who defined and implemented MI intended for its > output to be structured so that it could be easily parsed, but you > need to write a parser that knows how to deal with structured text. > Take a look at an XML parser, for example, or at a Lisp reader. Can you please avoid giving generic advice about writing parsers? > That's how you should deal with this, IMO, not by looking at each > individual character in turn and trying to decide, based on that > single character, what could that mean. I belive you're missing something. The *formal grammar* of MI is actually LL(1), so it can be parsed exactly by looking at one next character and deciding what to do. > > > > > Then perhaps we should add the type info to all arguments, instead > > > > > of removing it from where it exists now.the writers > > > > > > > > It might be good idea, but why don't add it as a separate field? I.e. > > > > instead of > > > > > > > > ^done,value="(int *) 0x0" > > > > > > > > you'll get > > > > > > > > ^done,value="0x0",type="int *" > > > > > > Fine with me. > > > > So, are patches to the effect of removing type from value, and moving it > > to a separate field welcome? > > I won't object. But I still think you need to replace that parser. I think not. - Volodya