Re: MI rules

["Alain Magloire" <alain@qnx.com>]

> 
> 
> >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.

> >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.  

> 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.

> bye  Fabi
> 

EOT.