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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9d3e1742bbcb99b3
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-09-17 04:11:14 PST
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!blanket.mitre.org!linus.mitre.org!linus!mbunix!eachus
From: eachus@spectre.mitre.org (Robert I. Eachus)
Newsgroups: comp.lang.ada
Subject: Re: Ada DEC Ada for Alpha Computers
Date: 16 Sep 94 10:28:06
Organization: The Mitre Corp., Bedford, MA.
Message-ID: <EACHUS.94Sep16102806@spectre.mitre.org>
References: <1994Sep15.121515.24609@sei.cmu.edu> <35af4b$g6@info.epfl.ch>
NNTP-Posting-Host: spectre.mitre.org
In-reply-to: weber@lglsun.epfl.ch's message of 15 Sep 1994 21:42:35 GMT
Date: 1994-09-16T10:28:06+00:00
List-Id: <comp.lang.ada>

In article <35af4b$g6@info.epfl.ch> weber@lglsun.epfl.ch (Mats Weber) writes:

 > I woudn't expect any vendor to fix debugger problems, at least no to a
 > satisfactory level. I have seen no Ada debugger correctly handling
 > programs with many generics and tasks. I have been participating in the
 > development of a project with approx. 100 KLOC, and we have almost
 > never been able to use a debugger to find the bugs.

 > Note that this comment should not be taken as Ada bashing. Developping
 > a debugger for Ada is much harder than for many other languages. And
 > despite all the tracing we have had to add by hand to our code, I still
 > wouldn't use any other language for a project of this size.

    Ten years ago I thought that debuggers for tasking programs would
take a while to develop, but that they would come.  I am now convinced
that (in spite of, or perhaps because of the excellent work in Canada
by Ray Buhr and Jerry Karam) debuggers for tasking programs are of no
use whatsoever.

    What you really need is to understand how the tasks can interact,
not how they interact in one specific operation/environment.  This
requires analysis tools which can model the high-level interactions
and detect possible deadlocks, etc.  We have done this at MITRE using
hierarchical colored petri nets.  A lot needs to be done to make the
tools easier to use--you want to extract the model from the code
directly--but I am now convinced that the right place to solve task
interaction problems is on a model.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...