From: nickerson@pundit.ds.boeing.com ()
Subject: Re: Gnat on OpenVMS
Date: 1999/05/24
Date: 1999-05-24T00:00:00+00:00 [thread overview]
Message-ID: <FC99Mz.5up@news.boeing.com> (raw)
In-Reply-To: 7i98hl$d8a$1@nnrp1.deja.com
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
next prev parent reply other threads:[~1999-05-24 0:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-05-18 0:00 Gnat on OpenVMS Thierry Lelegard
1999-05-18 0:00 ` Larry Kilgallen
1999-05-19 0:00 ` Gautier
1999-05-19 0:00 ` Robert Dewar
1999-05-19 0:00 ` Robert Dewar
1999-05-21 0:00 ` nickerson
1999-05-22 0:00 ` Robert Dewar
1999-05-24 0:00 ` nickerson
1999-05-24 0:00 ` Robert Dewar
1999-05-25 0:00 ` Larry Kilgallen
1999-05-22 0:00 ` Larry Kilgallen
1999-05-19 0:00 ` Robert Dewar
1999-05-19 0:00 ` Daniel Thonon
1999-05-19 0:00 ` Thierry Lelegard
1999-05-19 0:00 ` Larry Kilgallen
1999-05-20 0:00 ` Robert Dewar
1999-05-20 0:00 ` Robert Dewar
1999-05-21 0:00 ` Daniel Thonon
1999-05-21 0:00 ` Larry Kilgallen
1999-05-21 0:00 ` nickerson
1999-05-22 0:00 ` Robert Dewar
1999-05-22 0:00 ` Thierry Lelegard
1999-05-22 0:00 ` Larry Kilgallen
1999-05-23 0:00 ` Robert Dewar
1999-05-24 0:00 ` nickerson [this message]
1999-05-24 0:00 ` Mike
1999-05-25 0:00 ` Matthew Whiting
1999-05-25 0:00 ` Larry Kilgallen
1999-05-25 0:00 ` Thierry Lelegard
1999-05-27 0:00 ` Pascal Obry
1999-05-23 0:00 ` Robert Dewar
1999-05-24 0:00 ` nickerson
1999-05-25 0:00 ` Robert Dewar
1999-05-22 0:00 ` Robert Dewar
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox