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

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

On Mon, 14 Mar 2011 08:07:27 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>>> 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.

No it only says that GPS can be used to navigate the code programmatically.

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

It waits for an input or a command.

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

Does Emacs compile Ada programs by itself, without GNAT?
 
> Because GPS is the program being debugged. The point of this discussion
> is developing additional IDE features, in particular a monotone
> front-end.

OK, I didn't understand that you wanted to extend GPS. I meant using GPS
for developing Ada programs. I didn't want to steal the AdaCore's bread...

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

Because I know that the error is not there.

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

GTK is single threaded. If you don't return from a signal handler
everything is frozen.

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

Sorry for misunderstanding. No, I don't consider either GPS or Emacs as
good in that respect because neither supports Ada as the language for user
plug-ins. GPS uses Python, Emacs does even bigger mess. 

Although the command mode would allow some kind of dynamic plug-ins running
on the context of an alien program, it would not allow to have persistent
plug-ins.

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