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.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	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: nickerson@pundit.ds.boeing.com ()
Subject: Re: Gnat on OpenVMS
Date: 1999/05/24
Message-ID: <FC99Mz.5up@news.boeing.com>#1/1
X-Deja-AN: 481666363
Sender: nickerson@mirage.boeing.com ()
X-Nntp-Posting-Host: pundit.ds.boeing.com
References: <7hshfq$5tc$1@front1.grolier.fr> <FC3wGF.AFz@news.boeing.com>
 <7i6aur$i1g$1@nnrp1.deja.com> <7i74fa$9e2$1@front6.grolier.fr>
 <1999May22.193351.1@eisner> <7i98hl$d8a$1@nnrp1.deja.com>
Organization: Boeing Defense & Space Group / Software Systems
Reply-To: nickerson@pundit.ds.boeing.com ()
Newsgroups: comp.lang.ada
Date: 1999-05-24T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <7i98hl$d8a$1@nnrp1.deja.com>, 
Robert Dewar <robert_dewar@my-dejanews.com> writes:
|>
|>Just to clarify, the contract had no clause *forbidding*
|>integration with the VMS debugger. Rather it insisted on full
|>integration of GDB, so this is where the majority of the work
|>went. I think there were the following issues involved:
|>
|>  1. Digital does not see major long term investment happening
|>     in the future for the VMS debugger, and so there is an
|>     advantage in shifting in the GDB direction (a number of
|>     other work station manufacturers are moving towards GDB
|>     for the same reasons).

are you implying that the VMS debugger is to be dropped in favor
of GDB; I find that a big statement and needing of further proof;

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

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

|>We did in fact do some minimal integration with the VMS
|>debugger, line numbers and procedure names are compatible,
|>and you can look at some very simple kinds of data. This was
|>useful for getting the backtrace to work anyway. But complex
|>data cannot be viewed.

that actually is my usual level of need in VMSdebug; line #s, 
call stack, threads (nowdays), and with only simple expression 
evaluations;

|>With some (non-trivial) amount of work, the integration with
|>VMS debug could be greatly improved. But no one seems interested
|>in funding this at the current time.
|>
|>Note that Digital was not unaware of the issues of switching
|>debuggers. During the formal field test, Bart Nickerson made
|>it clear that he would never be happy with anything other than
|>the VMS debugger, and so Digital was quite aware that some
|>segment of the market would feel this way, and perhaps always
|>will (VMS users can be quite opinionated :-) like Ada folks :-)

that's me;

|>One thing is certain and that is that GDB continues to improve
|>at a rapid pace, and we have found that most problems reported
|>have been in the category of bugs that can be fixed in a fairly
|>straightforward manner. In addition, major improvements to GDB
|>continue to occur from our work, and also the work at Cygnus,
|>and several other large companies (I am not sure I can give
|>names at the current time, but you can expect some interesting
|>announcements in the near future, both concerning companies
|>adopting GDB, and concerning the maintenance of GDB itself).

unless and until it is the native VMS debugger GDB is a nonstarter;
the mixed language case (? wasn't it Larry Kilgallen who pointed
this out) also raises its head here;

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

|>And by the way Larry, if someone wants to contribute the changes
|>to make GNAT work better with VMS debug, that would be fine with
|>us, I would be delighted to see that happen, it is just that ACT
|>does not begin to have the resources to fund such work itself at
|>the current time.
|>
|>Robert Dewar
|>Ada Core Technologies

I understand the lack of resources; but I continue to believe that
GDB is the wrong direction on VMS; 

--bn (Bart Nickerson)
nickerson@pundit.ds.boeing.com
(206) 662-0183