From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20315 invoked by alias); 22 Sep 2004 16:18:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20186 invoked from network); 22 Sep 2004 16:18:09 -0000 Received: from unknown (HELO lakermmtao07.cox.net) (68.230.240.32) by sourceware.org with SMTP; 22 Sep 2004 16:18:09 -0000 Received: from white ([68.9.64.121]) by lakermmtao07.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20040922161807.FJWT11096.lakermmtao07.cox.net@white>; Wed, 22 Sep 2004 12:18:07 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CA9ok-0006ti-00; Wed, 22 Sep 2004 12:18:06 -0400 Date: Wed, 22 Sep 2004 16:18:00 -0000 From: Bob Rossi To: Alain Magloire Cc: Fabian Cenedese , gdb@sources.redhat.com Subject: Re: MI rules Message-ID: <20040922161806.GC26132@white> Mail-Followup-To: Alain Magloire , Fabian Cenedese , gdb@sources.redhat.com References: <5.2.0.9.1.20040922155506.01d24ab8@NT_SERVER> <200409221458.KAA07092@smtp.ott.qnx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409221458.KAA07092@smtp.ott.qnx.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-09/txt/msg00185.txt.bz2 On Wed, Sep 22, 2004 at 10:58:34AM -0400, Alain Magloire wrote: > > > > > > >I currently have a set of rules that parse an MI output command. This > > >includes the flex file, the bison file and an extra source file that > > >populates an in memory data structure representing the MI output > > >command. > > > > > >The rules from the documentation had to change only slightly to conform > > >to what GDB is actually outputting. The problem is, I haven't tested the > > >parser extensively. The reason for this is because I am waiting to here > > >from the GDB developers how to interpret the data semantically once it > > >is acquired. I believe that every MI output command needs to have a > > >header describing what type of MI output command is being transmitted. > > >With this knowledge, the front end would understand exactly what > > >information it needs to grab from the parse tree. Otherwise, the front > > >end gets confusing at best. > > > > How are the existing frontends doing it then? Do they just wait after > > a sent command until they receive a reply and take it as the one they're > > looking for? > > > > >BTW, I took a look at the eclipse MI parser, from what I can tell, it > > >uses a hybrid MI/CLI approach, and simply parses the MI command with > > >string compares. As far as I can tell, this method will be very buggy > > >and confusing in the long run. > > > > 8-), a very severe criticism. > It is a hand written decent parser. It was simple to write instead of > using JavaCC(flex/bison). The problem is not the parser but > the non conformity or rather the lack of feature of the MI Protocol implementation, > but that said it should not be seen as a complaint to the GDB folks, > MI was a great step in the right direction. I wasn't being critical at all. Personally, I don't like the fact that Eclipse use's a hybrid approach to getting data out of GDB. I have not even started adding MI to CGDB because I've been working on GDB, bringing it up to the standards I need to get CGDB fully usable by only using MI. If others would follow this approach, I'm sure my life would have been a lot easier, and CGDB would have been far more along. > > >string compares. As far as I can tell, this method will be very buggy > > >and confusing in the long run. > > I'm not sure on what you base such analysis ... but patches are always > welcome, it is an open source project. > And if you have a performing MI parser in Java, please send it to the Eclipse/CDT > folks, we will be ecstatic. This isn't outlandish. You could easily convert the MI parse tree I've created into XML, and do what you like with it on the Java side. > > That's why I asked. There are Eclipse, KDevelop and I don't know how > > many other frontends it's hard to believe they always wrote a new parser. > > And even if they did was it handwritten or generated... I guess then I'm > > looking forward to your results :) > > > > Eclispe uses the Java language, I suppose KDevelop C++, or other languages. > Writing a parser, is not the problem, or IMHO is not the problem > that GDB was trying to solve(You can write a parser for MI within a day). > Read the followup/feedback posts on the XMI proposals thread. Anyways, hope I didn't insult you or the eclipse project, we are all working on the same side here. Bobby