Re: Emacs vs GPS vs Eclipse, Ada vs Lisp vs Lua vs Java

[Stephen Leake <stephen_leake@stephe-leake.org>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 13 Mar 2011 11:17:42 -0400, Stephen Leake wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Sat, 12 Mar 2011 07:53:48 -0500, Stephen Leake wrote:
>>>
>>>> That makes sense; in this mode, GPS is a
>>>> front-end for gdb. Emacs can do the same thing.
>>>
>>> gdb is garbage. 
>> 
>> You seem to not understand how GPS works; it uses gdb as the backend for
>> all debugging operations. This is true of all frontends for the Gnu toolset.
>
> I didn't blame GPS. I did gdb.

You said:

>>> You can start GPS in a command mode listening for connections from the
>>> program being debugged and navigate the project sources from there. (It is
>>> a huge help when debugging GtkAda applications.) You can walk the call
>>> stack from an exception handler or at any point you wanted, without messing
>>> up with gdb (which does not work anyway).

This says you think GPS is a good debugger, while gdb is not. That
doesn't make any sense, since GPS uses gdb as a back-end.

Perhaps you mean GPS is a good debugger front-end, while gdb is not a
good front-end. That I can agree with.

>>> you may want to have some tracing tool. GPS gives you an opportunity
>>> to browse the sources while tracing.
>> 
>> That capability is based on gdb reporting the source line relevant to
>> the current code position.
>
> No. It is based on the debugging information. You need not to have gdb in
> order to use GNAT.Traceback.Symbolic.

Well, yes. But is that what GPS actually does while debugging? I doubt it.

>>>> But I have debugged GtkAda programs at that level, and it is not nearly
>>>> as productive (for the task of implementing simple GUIs for programmer
>>>> tools) as the Emacs environment. Mostly because the edit/compile/test
>>>> cycle for a single subprogram is much faster in the Emacs environment.
>>>
>>> I am not sure how it can be faster than in GPS: F4, shift+F2. 
>> 
>> That's just the first keystrokes. How long does it take after that
>> before the results are known?
>
> As long as GNAT gets it compiled.

Yes, which is a relatively long time.

>> In particular, since you have to restart GPS to see the change, you have
>> to rerun the steps needed to get to the point where the bug occured.
>> For example, suppose I'm working on DVC, the Emacs front end to
>> monotone. One operation is to review changed files, collect a commit
>> statement, and do the commit. If the last step is failing, I have to
>> repeat the other steps each time I want to try a bug fix.
>
> I didn't understand this. Why should I restart GPS? I start it once I
> booted the computer.

Because GPS is the program being debugged. The point of this discussion
is developing additional IDE features, in particular a monotone
front-end. I believe that requires writing Ada code that is linked with
GPS. I could be wrong.

>>> Debugging GtkAda with gdb cannot work, because GTK does not use
>>> exceptions to indicate errors. 
>> 
>> You can still set break points in the error handling code.
>
> No, I cannot because it is in glib, gobject or any of other C libraries for
> many of which I don't even have the source code. 

That's not GPS's fault, that's yours. The libraries you mention are
open source; why don't you have the code. 

Please stop raising straw men, and focus on the actual discussion.

In any case, you continue to bolster my point; elisp in Emacs is better for
developing IDEs than Ada in GPS.

> Besides it is useless to look at them, since the problem is definitely
> on the caller's side. (And if you did you would never want to do it
> again! (:-))

Figuring out what the user problem is may require reading the library
code, if the library documentation is not sufficiently clear.

>>> Also if you stop GTK in an unfortunate
>>> state, you would corrupt GUI in a way unrelated to the original
>>> problem. 
>> 
>> Yes, that is true of GUIs in general.
>> 
>> But it is better in Emacs, because the elisp is at a higher level; the
>> low level GUI operations are not interrupted by elisp breakpoints.
>>
>> So you are supporting my position that debugging GUIs is better in Emacs
>> than in GPS.
>
> No. GPS is an independent application, so whatever may happen with my
> program it cannot influence GPS.

Once again, the program under development is GPS.

>>> It is similar to real-time applications, which break when stepped.
>>> Tracing works much better and an ability to ask GPS to show the source
>>> where the message came from is a great help.
>> 
>> What, exactly, do you mean by "tracing"?
>
> User-made code insertions causing output upon program execution.

Ok. That is completely independent of GPS, gdb, and everything else I am
trying to discuss.

> I do visual tracing, i.e. the output is made into a GTK window rather than
> into a file. The most useful part is done from a log handler (see
> Glib.Messages). It also stops the program, before it crashes. 

How can user written output stop the program? Apparently the code does
something more than just output.

Obviously, such techniques are also available in elisp. For example, I
sometimes use them to see what commands are being issued to the monotone
back-end.

> Because if you get an error of Log_Level_Critical, crash is almost
> imminent. At this point I can inspect the call stack and go to the
> source just per mouse click.

In elisp I can call (debug) and get the same effect.

>> Emacs elisp uses that term to mean roughly "display the source lines as
>> they are executed". I rarely use that mode in Emacs. In realtime code it
>> can be useful, but any IO can change the timing.
>
> Yes, that would consume too many system resources.

If it displays every line, while your user intertions display less
information, I agree.


I am trying to discuss this assertion:

Developing user-interactive GUI add-ons for programming IDEs is better
using elisp in Emacs (with Emacs as the target IDE) than using Ada in
GPS (with GPS as the target IDE).

If you have a point relevant to that, I'd like to hear it.

-- 
-- Stephe