Re: [RFC] Interpreters (~final) (fwd)

[Jim Ingham <jingham@apple.com>]

The first motivation, actually, was to separate out the MI and Console 
"interpreters" in gdb so that you can run gdb under a GUI using the MI, 
but still provide a way to run "real" console commands.  By this I mean 
that you get correct console output, the extra prompts - completion, 
command entry mode for breakpoint commands, etc and everything else you 
need to make a convincing console window within an MI driven use of 
gdb.  Project Builder provides such a console window, so I hacked this 
up for PB, and I think Eclipse wants the same thing for its debugger, 
so Keith is working on merging our patches (this latter bit is just a 
guess, he could be doing it out of the goodness of his heart...)

I started to also think about how to do the more complex job of 
providing a way to "lash another interpreter onto gdb", but I didn't 
get very far with this.  The main issue with this is how to 
intelligently share events with the gdb interpreter.  Fortunately, the 
MI and the gdb CLI share the same event sources, etc.  So this bit it 
trivial.  Something like Tcl will have its own wait loop and thus list 
of wait sources, and to get good behavior you really need to convert 
the event sources from something the CLI & MI likes to something the 
other interpreter likes.

But this second stage is not necessary for getting Console behaviors 
from the MI.  The stuff Keith extracted from our sources is sufficient 
for that.

Jim

On Tuesday, August 27, 2002, at 03:01  PM, 
gdb-patches-digest-help@sources.redhat.com wrote:

> Keith Seitz wrote:
>>
>> Ping.
>
> Hi Keith,
>
> I'm not sure whose domain this is.  /me lacks context.
> What is it we're trying to do here?  Provide replacements
> to the CLI interpreter?  Lash an extension language into gdb?
> Excuse my ignorance, I haven't followed the conversation
> too closely.
>
> Michael
>
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer