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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!Xl.tags.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Sun, 02 Nov 2014 09:10:32 -0600 Newsgroups: comp.lang.ada Date: Sun, 2 Nov 2014 10:10:30 -0500 From: Peter Chapin X-X-Sender: pcc09070@WIL414CHAPIN.vtc.vsc.edu Subject: Re: IDE's that support ADA In-Reply-To: <854muiwpsh.fsf@stephe-leake.org> Message-ID: References: <2e8f1414-5556-465f-a7bc-f1513ec973aa@googlegroups.com> <85y4s08x0d.fsf@stephe-leake.org> <85egtqwnte.fsf@stephe-leake.org> <854muiwpsh.fsf@stephe-leake.org> User-Agent: Alpine 2.11 (CYG 23 2013-08-11) Organization: Vermont Technical College MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-5tOVSAhrzEnr8aXS9elyhkcCTEh6U5G0IuYXwKvJQVEe3vNP22RA896SigH5GggTPiJlVJD7LcSTA4j!NQIvLJ5zI3yluv6O4nR1CV+EmW1YMG4gMbT/s446HvUUbausNM04P/eb4ADJrDnPJosZ4i9W31tL!T7Cj8N2voULCiqWlRw== X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 9656 X-Received-Bytes: 9768 X-Received-Body-CRC: 2515449343 Xref: news.eternal-september.org comp.lang.ada:22976 Date: 2014-11-02T10:10:30-05:00 List-Id: On Sat, 1 Nov 2014, Stephen Leake wrote: > Ah, so it's not an obtrusive error display; it doesn't beep and open > another buffer with error messages. That makes sense. Yes, you just see "red squiggles" about things the IDE doesn't like. If you hover over the squiggle a message pops up that tries to explain the problem. > One problem with this approach is that editing file A can easily cause > problems in file B, so you still need some sort of global error list. > How do the IDE's you've used handle that? > > The Eclipse FIRST environment was not good at that, as I recall; you had > to explicitly check each possible file. The IDEs I've used have some kind of project view that shows, usually in a tree structure, all the files of my project. The view typically isn't exactly a representation of the files themselves. For example in the Java world packages are usually collapsed into a single node if there are no intermediate entities whereas in the file system you have to drill down through several subdirectories. For example the class edu.vtc.myproject.Buffer would be stored in the file edu/vtc/myproject/Buffer.java but the IDE project view wouldn't make you navigate all levels of the package hierarchy and just display the package "edu.vtc.myproject" as an individual node. Anyway, files with errors are often shown with red squiggly lines under their names or with some other indication of a problem. That said, I'm actually not 100% sure if you have to visit the file first to see the error indication. It might depend on the nature of the error. I never really paid attention to that. >> With the Java IDEs I've used (Eclipse, IntelliJ), if the IDE "signs >> off" on the code, it will compile. I can't recall a time when that >> hasn't been true. Thus the IDE does full name resolution across >> packages, libraries, and considers inheritance, etc, etc. > > I suspect it actually invokes the compiler, and processes the error > messages. That's easy to do, but the compile can be pretty slow if the > project is big enough, so you don't want to do it for every edit. GNAT > does have a "semantic check only mode", which is faster. I can tell you more precisely how it works with the Scala plug-ins for Eclipse and IntelliJ. I'm a much bigger Scala user than a Java user. The Scala compiler (there is really only one) has a special interface designed to assist IDEs. When used via that interface it's called the "presentation compiler." The Scala plug-in for Eclipse loads the presentation compiler as a library and holds it in memory all the time. It interacts with the compiler via the interface I mentioned which allows, apparently, incremental syntax and semantic checks. I'm not sure about the technical details. As a result you see errors as you type them provided the code you are editing is not exceptionally long or complex. If it is, there is a significant delay. One file in the Scala compiler source code itself is almost 6,000 lines and the presentation compiler lags pretty well when you try to edit that file. However for normal sized files the delay is perfectly acceptable. The main disadvantage to this approach is it uses a LOT of memory. I believe the Emacs extension ENSIME also uses the presentation compiler to do what it does (code completion, type checking, etc, etc). See: https://github.com/ensime. I set ENSIME up once but it was a bit flakey at the time (this was years ago). It's probably worth another look. In contrast the IntelliJ plug-in for Scala completely re-implements the Scala compiler front-end from scratch. This includes semantic analysis (type checking). They did this for two reasons 1. The presentation compiler wasn't available when they started their project. 2. They claim they can integrate more tightly with the rest of their IDE this way. It is certainly true that the Scala plug-in for IntelliJ takes less memory and feels faster. The down side of their approach is that the IDE sometimes gets it wrong and occasionally claims something is wrong that isn't or vice-versa. As the plug-in has matured this doesn't happen much anymore. Martin Odersky, the prime mover of Scala, has applauded IntelliJ because they have "helped debug the Scala Language Specification." In effect, their plug-in is a second implementation of the language. >> Yes, that's a good start. Does it work for references in comments too? > > No, those are not listed in the compiler cross references. Does any > other tool do that? How would it handle overloaded names? Well, I was thinking about Javadoc comments. For example: /** * Blah, blah, blah * * @param size The size of the thingy. */ void someMethod(int size) { .. } If you rename the parameter the IDE knows enough to rename it in the Javadoc too. I've seen IDEs offer to rename things in comments throughout but usually that's an option that's off by default. Typically you can preview a refactoring and I would definitely preview something like that for sure! I'm not sure what it does, exactly; maybe it's just search and replace. >> I'm looking at the refactor menu in Eclipse... there is an option to >> convert a local variable of a method into a field of the class. So in >> Ada terms that would be promoting a local variable of a primitive >> subprogram to a component of the tagged type. > > I gather you have not actually used that? I haven't! To be honest the refactoring I use the most, by far, is renaming. I'm nervous about letting the IDE modify my code at will because, frankly, I don't entirely trust it. Anything with far reaching consequences I tend to preview carefully. Even after renaming I worry about the IDE messing up my formatting. Despite having the formatting configured a certain way there are always exceptions. > I have done that on occasion, when I realize I need to split a primitive > operation into two parts, and save some state in between the two calls. > > But I usually change the variable name, and sometimes the type; I don't > see how having an editor do a small part of that job is useful. > > Having lots of screen space, with lots of windows on lots of source > files, and an easy way to navigate among them, makes editing specs and > bodies simultaneously easy. Using a static language with strong typing is more useful than fancy IDE features in this regard. That's my feeling. >> There are other refactorings too, but you get the idea. > > The only idea I get here is "not worth having the editor do this". I would tend to agree. Still... people coming from the Java world have ideas about what a "modern" IDE is supposed to be able to do. I'm not sure how much the refactorings get used in real life. I suppose someone has studied that question, maybe? >> Well, GPS can display the path associated with an unproved >> verification condition so you get a visual display of the path where >> the failure might occur. > > I gather that's displaying the information in a SPARK tool error > message. Is it really better than just seeing the text of the message? > Can you click on something to navigate to the appropriate source code? Yes. In GPS there is an icon next to the message that when clicked will highlight the path. I'm not sure where the information is coming from; it's not in the error message itself. I suppose GPS is reading some log file or report file generated by gnatprove. >> I actually use Emacs a lot and find myself going to it when I want to >> get real work done (funny about that). > > That's good to hear! I think I keep coming back to Emacs because it is the ultimate generalist. For a while I tried using OneNote to keep notes but I decided, for me, a collection of text files was suitable and I edit those files with... Emacs of course! It doesn't matter what programming language I'm using, what configuration files I'm editing, what document preparation system I'm writing in... Emacs works. Thus I find myself sitting in Emacs a lot of the time. Peter