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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,8d33ebaa85598950 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.224.71 with SMTP id ra7mr1098763pbc.3.1348233517677; Fri, 21 Sep 2012 06:18:37 -0700 (PDT) Path: t10ni4273025pbh.0!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.news.ucla.edu!nntp.club.cc.cmu.edu!weretis.net!feeder4.news.weretis.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: GPS issues: laundry list Date: Sat, 15 Sep 2012 10:25:30 +0200 Organization: cbb software GmbH Message-ID: References: <854nn34fv2.fsf@stephe-leake.org> <1unaedlxs0o9j$.lbivg0rltyvw$.dlg@40tude.net> <85r4q62nw0.fsf@stephe-leake.org> <1b2nanavkx67n$.1rkpkv1o50bkj.dlg@40tude.net> <85d31p2g9s.fsf@stephe-leake.org> <851ui3ivac.fsf@stephe-leake.org> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 9A8bJrx4NhDLcSmbrb6AdA.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Received-Bytes: 5076 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-09-15T10:25:30+02:00 List-Id: On Sat, 15 Sep 2012 03:45:31 -0400, Stephen Leake wrote: > "Dmitry A. Kazakov" writes: > >> Maybe. But it is still an incredibly bad idea to manage versions by >> altering file names. > > You have misunderstood what I'm proposing; I'm not editing file _names_, > just what directory the project is checked out in. > > For version 07, the project is in mms_version_07/*. For version 08, the > project is in mms_version_08/*. > > How else would you do it? I would have the stuff in a source control system. I mean a true system which maintains consistent project views rather than merely tracking individual files. The project (under the source control) would depend on the project MMS, which is in some DB. You change current view from v7 to v8 by changing the project dependency. This is how we maintain our middleware project. It depends on hundreds of other projects of third-party libraries, drivers etc. It would be impossible to handle it using your way. >> I prefer to concentrate my weak mental powers solely on typing and >> gazing Ada. > > What else does Emacs require you to do? Why would you need the on-line help then? >> GPS is an IDE, it is not a language. > > Correct. But I can customize it by writing Python and XML, so I want > adequate documentation to help me do that. Can /= must. Customizable IDE defeats the purpose of. This is what makes MS Developing Studio so uncomfortable. Once you start customizing anything, you open a hell of problems how do I manage customizations. How do I switch them, how do I store them, how do I version them, how do I train personal on them, how do I keep them in the incoming version of the tool... >>> In my real job, I spend quite a bit of time making sure the manuals that >>> describe our system are correct and up to date. That way, i can just >>> refer people to the manuals, and don't have to spend time answering the >>> same questions over and over. The time spent maintaining the manuals is >>> _very_ well spent! I expect the same from help systems, especially >>> commercially supported ones. >> >> Modern-time systems became too complex for a comprehensive up-front dry >> training. > > It did not say anything about "training"; manuals can be read straight > thru, but mostly they are searched for information on a particular > topic, as that topic comes up. Training is required in order to know where to search for. On-line help /= manual /= FAQ. >>> But the main point here is this: >>> >>>> Since GPS is a GTK application, its debugging must be a nightmare, even if >>>> you know the internals of GPS very well. >>> >>> That is _precisely_ why Emacs is better; debugging elisp is _not_ a >>> nightmare, _because_ it is an interactive system; you can always find >>> out what function a key invokes, you can find the source code that >>> implements that function, you can find the source code for all the >>> functions that calls. And then you can modify one function, and see the >>> results immediately, without quiting and recreating the current situation. >> >> In my GtkAda programs I hook Glib.Messages, which causes an error window to >> pop up with the source code location trace. >> >> The problem is that for GTK the actual error location is never the point >> where the error was detected. This is a problem of any event-driven >> framework. > > Yes. In Emacs, you can also run elisp in debug mode, step by step, and > watch what happens, examine variables. "Step" is already an imperative point of view, which does not apply to events. Deadlocks usually happen when the UI tries to emulate or really be asynchronous. When you, for example, start compilation of a unit, you want still have IDE's UI responsible. This is what opens the can of worms. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de