Developer Forum

Per Sandberg < XXXX@XXXXX.COM > writes:


Perhaps you should try again; Emacs Ada-mode now parses .gpr files to get
the required info.

On the other hand, perhaps I should try GPS again; it's been a few
years. My last impression was that it was a toy compared to Emacs :).

.gpr files are more important to the compiler than to the IDE.


and doesn't do anything useful.


Ok.


Since Emacs does .gpr, what is left in GPS that is so much better?

Last I checked, GPS doesn't do VHDL, LaTeX, Maxima, Matlab, bash mode,
make mode, monotone, read/send mail; all tools I need in my integrated
development environment. I even need C++ for monotone, but I assume GPS
does that.

I understand the Ada navigation is slightly better in GPS. I haven't
tried it, so I don't miss it.

I haven't tried customizing GPS. I have customized Emacs extensively;
for example, I've significantly improved the monotone front-end.

Hmm. I assume it would not be too hard to teach GPS to colorize VHDL;
adding intelligent indentation is probably harder (is it possible
without writing Ada for GPS? maybe it has been done). To be fair, the
intelligent indentation for Ada in Emacs is the hairiest code I have
every seen.

It might even be possible to build a vhdl.xml for gprbuild to run the
VHDL toolchain. Is there another way to teach GPS to run a toolchain?

If GPS could integrate the gtkwave viewer for VHDL debugging, that would
be great; it's run as a separate process from Emacs.

My understanding is that to add something like the monotone front-end in
GPS requires writing Ada code, which requires compiling, linking, and
restarting GPS for each modification.

In Emacs, the monotone front-end is in elisp, where each subroutine can
be edited and loaded without restarting Emacs, and each variable can be
set on the fly. There is an interactive de *** for stepping thru the
elisp. Once it is debugged, it can be batch compiled for faster
execution.

For most applications, I pick Ada hands down over Lisp. But for user
interface GUIs, a dynamically loaded interpreted/debugged environment is
_much_ better. So I stick with elisp for that.

If GPS can do dynamically loaded Ada with source-code debugging, that
would be a huge selling point. But I suspect the technical requirements
of such an environment require a much simpler language like Lisp.

Lua might work in such an environment; it's better than Lisp, not as
good as Ada. monotone uses Lua as a user customization language.

Apparently Java is used this way in Eclipse; does that have source-code
debugging for dynamically loaded subprograms?

--
-- Stephe

I believe GPS is extendable using Python.

Peter

What about retouching private album photos and ripping CDs?

[...]

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

See here:

http://www.yqcomputer.com/ #1.4

--
Regards,
Dmitry A. Kazakov
http://www.yqcomputer.com/

"Dmitry A. Kazakov" < XXXX@XXXXX.COM > writes:



No, I don't expect Emacs to do that. But I wouldn't be surprised if
there is a mode that does!

Are you saying GPS supports that?


I gather you are saying you can use one GPS instance to debug the Ada
code in another GPS instance. That makes sense; in this mode, GPS is a
front-end for gdb. Emacs can do the same thing.

That would be the equivalent of the Emacs interactive lisp de *** .

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.

--
-- Stephe

No, I wondered why it should. I don't want a mail-sending IDE.


No, I mean that you can communicate to GPS from your Ada program, e.g.
while debugging it.


gdb is garbage. But even if there were a decent de *** for GNAT, you may
want to have some tracing tool. GPS gives you an opportunity to browse the
sources while tracing.


I am not sure how it can be faster than in GPS: F4, shift+F2. Debugging
GtkAda with gdb cannot work, because GTK does not use exceptions to
indicate errors. Also if you stop GTK in an unfortunate state, you would
corrupt GUI in a way unrelated to the original problem. 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.

--
Regards,
Dmitry A. Kazakov
http://www.yqcomputer.com/

Dmitry A. Kazakov" < XXXX@XXXXX.COM > writes:


I often need to quote parts of code in email; it's convenient if the
code and the email are in the same tool.

In addition, many editing operations are similar between code and email;
cut/paste, fill, spellcheck. So I prefer a consistent interface, which
is much easier to achieve with a single tool.


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.


There is; gdb.

gdb is a backend. You can use it directly from the command line (I
actually often prefer that), or via a front end such as Emacs or GPS.
The front end displays the appropriate source, allows setting
breakpoints, and also displays specified variables, the current CPU
registers, etc. I don't think GPS is significantly different in
functionality from Emacs here; it is different in the details of how
the windows are manipulated.


That capability is based on gdb reporting the source line relevant to
the current code position. Emacs and GPS both provide ways to display
that source code.


That's just the first keystrokes. How long does it take after that
before the results are known?

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.

In Emacs, the context doesn't change when I recompile one elisp
program; I don't have to repeat anything.

You'll have to try it to truly appreciate the difference.


You can still set break points in the error handling code.


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.


What, exactly, do you mean by "tracing"?

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.

--
-- Stephe

n Sun, 13 Mar 2011 11:17:42 -0400, Stephen Leake wrote:


I didn't blame GPS. I did gdb.


No. It is based on the debugging information. You need not to have gdb in
order to use GNAT.Traceback.Symbolic.


As long as GNAT gets it compiled.


I didn't understand this. Why should I restart GPS? I start it once I
booted the computer.


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


No. GPS is an independent application, so whatever may happen with my
program it cannot influence GPS.


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.


Yes, that would consume too many system resources.

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

Dmitry A. Kazakov" < XXXX@XXXXX.COM > writes:


You said:


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.


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


Yes, which is a relatively long time.


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.


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.


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


Once again, the program under development is GPS.


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


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.


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


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

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


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


It waits for an input or a command.


Does Emacs compile Ada programs by itself, without GNAT?


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


Because I know that the error is not there.


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


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