From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14655 invoked by alias); 17 Feb 2006 18:59:58 -0000 Received: (qmail 14642 invoked by uid 22791); 17 Feb 2006 18:59:54 -0000 X-Spam-Check-By: sourceware.org Received: from gandalf.inter.net.il (HELO gandalf.inter.net.il) (192.114.186.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Feb 2006 18:59:52 +0000 Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id HXG13710; Fri, 17 Feb 2006 20:59:35 +0200 (IST) Received: from HOME-C4E4A596F7 (IGLD-80-230-152-98.inter.net.il [80.230.152.98]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id CSN91984 (AUTH halo1); Fri, 17 Feb 2006 20:59:33 +0200 (IST) Date: Fri, 17 Feb 2006 19:25:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus CC: gdb@sources.redhat.com In-reply-to: <200602171724.03824.ghost@cs.msu.su> (message from Vladimir Prus on Fri, 17 Feb 2006 17:24:03 +0300) Subject: Re: MI: type prefixes for values Reply-to: Eli Zaretskii References: <200602171658.23427.ghost@cs.msu.su> <200602171724.03824.ghost@cs.msu.su> 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-02/txt/msg00191.txt.bz2 > 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. > 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. 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. > That code was written before me, and is 100 lines in size. My advice is to throw it out and write a new one. It is not suitable for working with GDB/MI. > > > > 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.