From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e36020a4e7d24836 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Emacs vs GPS vs Eclipse, Ada vs Lisp vs Lua vs Java References: <87zkp4uhjl.fsf@ludovic-brenta.org> <82mxl2yq9j.fsf_-_@stephe-leake.org> <82vczowlcz.fsf@stephe-leake.org> <4wxehmr0odbn.so98kpo0i6do.dlg@40tude.net> Date: Sun, 13 Mar 2011 11:17:42 -0400 Message-ID: <821v2bvyll.fsf@stephe-leake.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt) Cancel-Lock: sha1:wXav4kKbPqYVWV6pGMJDKCAX7nw= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: aaf1f4d7cdfe1e26b0de802238 Xref: g2news2.google.com comp.lang.ada:19110 Date: 2011-03-13T11:17:42-04:00 List-Id: "Dmitry A. Kazakov" writes: > On Sat, 12 Mar 2011 07:53:48 -0500, Stephen Leake wrote: > >> "Dmitry A. Kazakov" writes: >> >>> On Fri, 11 Mar 2011 04:12:40 -0500, Stephen Leake wrote: >>> >>>> 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 don't want a mail-sending IDE. 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. >>>> If GPS can do dynamically loaded Ada with source-code debugging, that >>>> would be a huge selling point. >>> [...] >>>> Apparently Java is used this way in Eclipse; does that have source-code >>>> debugging for dynamically loaded subprograms? >>> >>> 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). >> >> I gather you are saying you can use one GPS instance to debug the Ada >> code in another GPS instance. > > No, I mean that you can communicate to GPS from your Ada program, e.g. > while debugging it. > >> 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. > But even if there were a decent debugger for GNAT, 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. > 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. Emacs and GPS both provide ways to display that source code. >> 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? 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. > 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. > 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. > 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"? 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