Re: GDB Console

[Dodji Seketeli <dodji seketeli org>]

Hello Seemanta,

Seemanta Dutta <seemanta gmail com> a écrit:

[...]


> The update is that I have joined grad school at UCSD, here in San
> Diego.

Oh, nice. Great to see you doing more than OK :-)

> That also explains why my open source activities have been curtailed
> of late and why I have not posted more frequently or done more work in
> contributing to Nemiver. Grad life is far hectic than when I was
> working, I realized this :) But even then, I shall try to help this
> project in whatever small way I can.
>

:-)

> And now my insight into this matter. Actually, I am in favor of a two
> pronged approach:
>
> 1. Provide a scripting front-end to Nemiver, preferably in
> Python. This front-end could really empower users in ways we can't
> even imagine. Come on, its *Python*, guys !!! Users can write
> automated debugging scripts and what not.
>

Yeah, the scripting feature has been in my mind for some time now. I
guess I [and people who sent patches so far ;-)] just felt there were
more urgent stuff needed until now ;-)

Since we are dreaming, why not dreaming high and settle on a lisp
implementation for the extension? :-) I am quite sure almost nobody
would follow me in that direction but I guess I had to at least mention
that possibility ;-)

> 2. Implement a faux "GDB Console" below the scripting front end which will
> try to mimic the actual GDB CLI, but will have the MI below it. This faux
> 'GDB console' will make older GDB users feel at ease but at the same time,
> use MI below it for the reasons mentioned earlier.
>
> The user can of course, decide to switch between the Python and the
>faux 'GDB Console' depending on her preference.

Another possibility would be to wrap IDebugger in our scripting language
of choice and write the command line interpreter [what you call the Faux
GDB Consol] in that scripting language entirely. A concern I would have
with this approach are size related; how big would that be? Another
concern is the that I'd like the command line interpreter to be easily
reusable from C++. So your point about making the command line
interpreter in C++ does IMHO have legs.

-- 
	Dodji