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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,31b8879c52cdbc65 X-Google-Attributes: gid103376,public From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: Gnat on OpenVMS Date: 1999/05/25 Message-ID: <1999May24.232851.1@eisner> X-Deja-AN: 481761193 X-Nntp-Posting-Host: eisner.decus.org References: <7hshfq$5tc$1@front1.grolier.fr> <7i6aur$i1g$1@nnrp1.deja.com> <7i74fa$9e2$1@front6.grolier.fr> <1999May22.193351.1@eisner> <7i98hl$d8a$1@nnrp1.deja.com> X-Trace: news.decus.org 927602942 28346 KILGALLEN [216.44.122.34] Organization: LJK Software Reply-To: Kilgallen@eisner.decus.org.nospam Newsgroups: comp.lang.ada Date: 1999-05-25T00:00:00+00:00 List-Id: In article , nickerson@pundit.ds.boeing.com () writes: > > In article <7i98hl$d8a$1@nnrp1.deja.com>, > Robert Dewar writes: > |> 2. In particular, there was no possibility of finding > |> resources at Digital for Ada 95 specific modifications > |> to the VMS debugger (remember that Digital's first > |> inclination was to completely abandon Ada on VMS and > |> push all their customers to DEC Unix, it was only when > |> a number of customers notified Digital that this was > |> not acceptable, that some attention was given to Ada 95 > |> on VMS. > > I am unable to rationally comment on Digital's eratic behaviors; It is good to remember that at the time this contract was drawn up support for the VMS debugger was rather far from support for the DEC Ada compiler (and presumably from the DEC folk arranging the contract with ACT) within the DEC organization. Viewed from that standpoint, VMS debugger changes may have been _considerably_ more difficult than the technical issues would be alone. So while from the outside you may see irrational behavior, at the time and in that place it may have been quite reasonable for DEC to approach it that way. Note that implementing the contract took considerably longer than it took DEC to rearrange their internal organization, but the standards for correctness of a compiler are somewhat more rigid :-). > |> 3. Adapting GNAT to use the VMS debugger would have been a > |> major work item. Would it have been more expensive than > |> adapting GDB? Probably, but who knows, we were never asked > |> to bid on that adaptation. > > yes DEC made a $ decision; it was the wrong decision; DEC made the wrong decision for my business interests. That is quite different from saying that they made the wrong decision for _their_ business interests. VMS folk and Ada folk should be quite accustomed to decisions being made that do not favor what they see as superior technology. Then again, I don't think Ada advocates should wish for those lightening bolts from the blue like Microsoft deciding to implement Windows 2002 in Ada, because certainly they would call it A++ in order to justify certain important syntax changes preserving their freedom to "innovate". > |>Yes, there will be some people who always will prefer the VMS > |>debugger, and just as no amount of improvement to VI will woo > |>away EMACS users, I am sure they will feel that way > |>indefinitely. But in the long run, we are confident that VMS > |>Ada users will find that GDB meets their requirements, and > |>indeed a number of users are finding that it works fine for > |>them right now. > > the native editor of VMS is the TPU editor; given that I started > with VMS when edt was native that is the keypad of choice; neither > VI nor EMACS are on the event horizon for me - I'd go with NEDIT; > I have heard of EMACS with edt keypad but there again even the look > of EMACS puts me off; You may have chosen that newfangled TPU editor, but for me the native editor of VMS is TECO, since it was there from the initial release (and already familiar). So being in the minority (but technically superior, as I see it) in the editor realm too, I have perspective on the other areas where I do not get what I want on the first go-round. > I understand the lack of resources; but I continue to believe that > GDB is the wrong direction on VMS; GDB may be the wrong choice for the existing VMS customer base, but it may be the right choice for GNAT in general and even for VMS in terms of attracting new users. If VMS dreams of Galaxy dominance should come to pass, there will be people who want to port previously non-VMS software to VMS, and if they are accustomed to GDB elsewhere finding an "old friend" (not mine, but perhaps theirs) will speed them along. Finding Ada should help them on the portability front as well. I recently had a look at some Ada software from a non-DEC Unix system for looking at the feasibility of porting it to VMS. The response I gave was that it was highly viable to use the DEC Ada (83) compiler for this project, since only two out of several hundred modules were not readily portable (without even a description of what the software does). If that had been Ada95 code, there would be no chance without an Ada95 compiler, and having a compiler would be much more important than having the best debugger. I do not view the current GNAT situation as necessarily being the last chance to debug Ada95 on VMS, but certainly an important milestone. Larry Kilgallen