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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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

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

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

>> 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. 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! (:-))

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

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

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

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de