Re: GDB Console

[Seemanta Dutta <seemanta gmail com>]

Dodji, Jonathon and others,
Wanted to say hello after a long time :), provide an update and finally want to talk about the matter that is being discussed in this thread.

The update is that I have joined grad school at UCSD, here in San Diego. 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. 

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.
I would like to hear on this idea more from all of you and this is something that if implemented, can make Nemiver very popular and well known, IMO.

Thanks and regards,
Seemanta

On Thu, Oct 14, 2010 at 12:01 PM, Venkatram Tummala <venkatram867 gmail com> wrote:

On Thu, Oct 14, 2010 at 6:13 AM, Dodji Seketeli <dodji seketeli org> wrote:
> Venkatram Tummala <venkatram867 gmail com> a écrit:
>
>>>   Another disadvantage is that the set of commands exposed by Nemiver
>>>   would be different from those of GDB. Personally I don't see this as
>>>   a really problem because to me, Nemiver is more about providing a
>>>   nice and consistent debugging experience in GNOME rather that being
>>>   about exposing every little GDB feature one can think about. If a GDB
>>>   command makes sense to be exposed in Nemiver verbatim, the no
>>>   problem. If it doesn't make much sense in a GNOME environment then we
>>>   ought to provide replace commands for it.
>>
>> I personally feel that users would like to have a CLI command
>> interface that is already familiar to them rather than introducing
>> them to new command interface. Personally, i won't have concerns
>> adapting to a new command interface but if we are concerned about
>> increasing the usage of nemiver, this disadvantage will definitely
>> will be a blocker in my opinion.
>
> I certainly hear you. I didn't mean that we'd gratuitously change the
> syntax of the commands introduced by Nemiver under this scheme. When I
> set the "set of commands by Nemiver would be different", I meant more
> that they wouldn't be necessary equal. E,g, some GDB commands might not
> be present. Or their output might be slightly different to bring more
> clarity in the the context of a graphical debugger. This kind of things.
>
> In other words, we'd try very hard to make the commands look the same,
> but no harder :-)
>
> Would that be better in your opinion? Still not enough?

No. That would be good enough. I misunderstood your point.

>
>>>
>>> 2/ Modify GDB so that CLI commands trigger MI protocol replies.  If this
>>>   was done today, Nemiver could just let the user type free form GDB
>>>   commands, send those to the GDB and we would still get MI protocol
>>>   notifications about state changes.
>>>
>>>   The main advantage of this is that it requires much less work on
>>>   Nemiver side. The disadvantages are related to the fact that we
>>>   wouldn't have many of the pros we get with 1/
>>
>> This will work for me. As a user, i would definitely like this option.
>
> OK.
>
>>>
>>>> Atleast for me, Lack of GDB console is the only reason why i can't use
>>>> nemiver as my full-time debugger.
>>>
>>> This is interesting. Whenever I stumble upon a particular feature
>>> missing in Nemiver but present in GDB CLI, I try to implement it in
>>> Nemiver. So I'd be _really_ interested in hearing about what exactly the
>>> GDB CLI provides you that we are lacking in Nemiver today. Can you give
>>> us a couple of concrete examples?
>>
>> Hmmm...Lack of a GDB CLI feature in nemiver is not something i am
>> worried about. Being a command line junkie, i still prefer doing some
>> things on the CLI rather than the GUI. For ex. Everytime i need to set
>> a breakpoint in a file that is not yet opened in the nemiver
>> workspace, i would prefer using the CLI to set it rather than using
>> the Set Breakpoint GUI window.
>
> FWIW, to break on a function, I personally do ctrl-b and then I type the
> name of the function and I hit entier. Is that really longer than typing
> "b function_name"?

Its not really about being faster as i already mentioned but its just
personal preference. I hate extra windows popping up :)

>
> If I want to set a breakpoint to the "current position", then I just do
> shift-control-b. The "set breakpoint dialog" comes up pre-filled with
> the current location. Hit enter and I am done.
>
> I am not a great fan of the mouse either ;-)
>
>> Besides, some minor issues like using
>> CLI as a hex calculator etc. aren't available.
>
> For that, hit F12 and in the (variable) _expression_ _expression_ evaluator,
> just type the _expression_ you want and hit enter. It should be evaluated.

> Similarly, to evaluate a function call (call foo(var) in gdb), type
> ctrl-e and then type the function call _expression_ you want to see
> evaluated. The output comes out in the embedded terminal.

Ok. Didn't realize this. Point noted.

>
>> Its not to say that I hate GUIs in general. O'wise i shouldn't be
>> using nemiver in the first place. I would definitely love to have the
>> best of both worlds in a single convenient package.
>>
>> So, its not about the *lack of a feature*, rather its just about
>> personal preference I would say. Thanks a lot for the info.
>
> Thanks for the clarification. Be assured that this command line feature
> ought to get in in a way or in another, IMO. Hopefully sooner than later :-)

That would be great. Thanks a lot.
>
> --

>        Dodji
> _______________________________________________
> nemiver-list mailing list
> nemiver-list gnome org
> http://mail.gnome.org/mailman/listinfo/nemiver-list
>
_______________________________________________
nemiver-list mailing list
nemiver-list gnome org
http://mail.gnome.org/mailman/listinfo/nemiver-list