karl@grebyn.COM (Karl A. Nyberg) (10/20/87)
Here's (hopefully all) of the info-ada mail that arrived during the last
couple weeks while the conversion to ajpo.sei.cmu.edu was taking place.
(If you're reading comp.lang.ada, you can probably hit 'n' now.)
-- Karl --
------------------------------------------------------------------------
From umd5!mitre-bedford.ARPA!johnm Fri Oct 16 20:41:38 1987
To: info-ada@ada20.isi.edu
Cc: sfc@mitre-bedford.ARPA, johnm@mitre-bedford.ARPA
Subject: Requesting info on Ada for MVS
Date: Tue, 29 Sep 87 17:20:37 EDT
From: John Maurer <umd5!mitre-bedford.ARPA!johnm>
All:
I'm interested in hearing any experiences people may have had using
Ada on MVS. In particular, I know about two compilers for MVS (one
from Intermetrics and one from Telesoft) and would be interested in
hearing from anyone who has used these products. (General
impressions, great features, gotchas, etc.)
Please reply directly to me. I will summarize for the net.
Thanks.
-John Maurer
johnm@mitre-bedford.arpa
------------------------------------------------------------------------
From umd5!ucdavis.ucdavis.edu!uop!avatar Fri Oct 16 20:41:42 1987
Date: 30 Sep 87 02:23:45 GMT
From: umd5!ucdavis.ucdavis.edu!uop!avatar
Subject: Verdix Compiler
To: info-ada@ada20.isi.edu
Will those of you who replied to my message about the Verdix Ada Cross
Compiler please resend your messages. Through every fault of my own, I
lost your addresses (hit 'w' instead of 's'). Sorry to burden the net
due to operator headspace errors. Thanks.
avatar
_______ _________ ____
Don Christensen (avatar) |_____ \ |___ _| / __ \
US Post: South/West #107 UOP | | | | | | / / |_|
Stockton, CA 95211 | | | | ___ | | | | _
209-944-7048 |_|__| | | |_| | \ \__| |
UUCP: ...!ucbvax!ucdavis!uop.edu!avatar |______/ o \___/ o \____/ o
...!lll-crg!ucdavis!uop.edu!avatar (Well, it's original!)
...!{ptsfa!cogent, cepu!retix}!uop.edu!avatar
------------------------------------------------------------------------
From umd5!rutgers.edu!dayton!umn-cs!shamash!jwabik Fri Oct 16 20:41:50 1987
Date: 28 Sep 87 19:54:53 GMT
From: umd5!rutgers.edu!dayton!umn-cs!shamash!jwabik (Jeff Wabik)
Subject: Ada YACC & LEX (Epilogue)
To: info-ada@ada20.isi.edu
Just a followup. After sitting in queue one site away for several
days, my informants tell me that my 3-part YACC & LEX posting made it
to the world. A few things:
1) In my posting I said something like:
"I fixed the LEX so that it is now correctly case
sensitive."
Of course, I typoed.. Make the following change:
"I fixed the lEX so that it is now correctly case
blind."
2) I've still been getting many requests in my mailbox.
If you didn't get the goodies via MAIL or NEWS, please
contact me and I'll get them there somehow.
-Jeff
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jeff A. Wabik (HQM207B) { umn-cs \
Control Data Corporation UUCP: -> !shamash!jwabik }
Bloomington, MN 55440 { meccts /
Disclaimer of the day: Of course my employer has no idea what I'm doing ..
Moral of the day: Live long and program.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
------------------------------------------------------------------------
From umd5!rutgers.edu!clyde!watmath!utgpu!utcsri!uthub!ecf!apollo Fri Oct 16 20:41:55 1987
Date: 29 Sep 87 15:10:37 GMT
From: umd5!rutgers.edu!clyde!watmath!utgpu!utcsri!uthub!ecf!apollo (Vince Pugliese)
Subject: fortran --> ada translators
To: info-ada@ada20.isi.edu
I was hoping to get a feel for the state-of-the-art in Fortran to
Ada conversion. Feel free to e-mail, or post to the net, any
information regarding either commercially available or public-domain
programs that purport to do Fortran to Ada translation.
In order to be of greatest use, I would imagine a synopsis of one's
experience with the program would be most beneficial, if in fact there
is any experience to speak of.
Thanks in advance,
Vince Pugliese
apollo@ecf.toronto.edu
------------------------------------------------------------------------
From umd5!rutgers.edu!dayton!umn-cs!shamash!jwabik Fri Oct 16 20:41:59 1987
Date: 28 Sep 87 21:24:45 GMT
From: umd5!rutgers.edu!dayton!umn-cs!shamash!jwabik (Jeff Wabik)
Subject: Needed: Some Ada source code for testing purposes.
To: info-ada@ada20.isi.edu
I recently finished the project that I rewrote the Ada YACC & LEX for,
(Posted to comp.lang.ada 9/26/87) and now am ready for some serious
testing. HELP NEEDED: While I've written some (what I believe to be)
good tests for my parser, I'm sure I've missed something.. If anyone
(especially those who took copies of my mods ;-) has any
"non-sensitive" Ada code lying around that I could throw at my parser,
for testing purposes only, I'd appreciate hearing from you ..
Thanks in advance ..
-Jeff
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jeff A. Wabik (HQM207B) { umn-cs \
Control Data Corporation UUCP: -> !shamash!jwabik }
Bloomington, MN 55440 { meccts /
Disclaimer of the day: Of course my employer has no idea what I'm doing ..
Moral of the day: Live long and program.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
------------------------------------------------------------------------
From umd5!Sierra.Stanford.EDU!Mendal Fri Oct 16 20:42:13 1987
Date: Thu 1 Oct 87 22:05:40-PDT
From: Geoff Mendal <umd5!Sierra.Stanford.EDU!Mendal>
Subject: Expanded Names Question
To: info-ada@ADA20.ISI.EDU
Dear Anna Fans,
Here's a strange thing I encountered today. Both the Verdix and DEC VMS
Ada compilers state that the following program is semantically illegal:
procedure Expanded_Names is
begin
Loop_Name:
loop
Block_Name:
declare
X : constant INTEGER := 1;
Y : constant INTEGER := STANDARD.Expanded_Names.Loop_Name.Block_Name.X;
-- Both the DEC VMS and Verdix Sun/3 compilers say that the above
-- expanded name is semantically illegal, referencing 4.1.3.
begin
null;
end Block_Name;
end loop Loop_Name;
end Expanded_Names;
I am confused as to why the expanded name is semantically illegal. (Or
is it legal and both compilers are in error?)
It would seem to me that the Ada rules regarding expanded names allow such
a case as above. I've tried several variations on this theme and only
when a named block is within a named loop do the compilers complain.
What am I missing?
Ada References: 4.1.3(13, 16 .. 18); 5.6(7); 8.3(13)
Thanks in advance for any (correct) answers.
gom
-------
------------------------------------------------------------------------
From umd5!TL-20B.ARPA!PLOEDEREDER Fri Oct 16 20:42:19 1987
Date: Thu 24 Sep 87 18:54:46-EDT
From: umd5!TL-20B.ARPA!PLOEDEREDER
Subject: "1:=" is legal
To: ada-info@ada20.isi.edu
Cc: ploedereder@tl-20b.arpa
re: discussion on legality of "+1:=".
The ARM is explicit about " +1:=" being legal. 2.2.(2) states
"In some cases an explicit separator is required to separate adjacent lexical
elements (namely, when without separation, interpretation as a single
lexical element is possible)."
The only other interesting rule that isn't included in the above is 2.2(4)
which requires separators between identifiers and numeric literals.
Consider:
(the plus is really not in question, so I omit it).
"1" legal lexical element
"1:" possibly legal fragment of a lexical element like "1:555:"
"1:=" illegal lexical element; no way to interpret this as any legal
lexical element or portion thereof.
"1" ":=" two legal lexical elements (therefore the only interpretation and
no separator required)
Yes, this says that LR(1) lexers are insufficient for Ada.
On the subject of lexical ideosyncracies. Here are two more that make pure
LR(1) lexers unsuitable:
Consider: "IF A = 3THEN...." -- illegal by ARM 2.2(4).
Note that a LR(1) lexer would know that "3" is a lexical element and
therefore would not require the separator mandated by ARM 2.2(4).
Finally, the "piece of resistance" which shows that proper Ada lexing either
requires unbounded lookahead or interaction with the syntactic parsing.
Consider:
...X'('a','b',...) -- a qualified aggregate consisting of character literals
Here the lexical analysis could return lexical elements "X" "'('" "a" "','" "b"
etc., until it runs into the end of the aggregate and discovers that it was all
wrong, since the proper sequence of elements should have been "X" "'" "("
"'a'", etc.
Short of unbounded look-ahead, the lexer needs guidance by syntax rules to
analyze this example correctly.
Erhard Ploedereder
Tartan Laboratories
(412) 621-2210
P.S. Needless to say, all released versions of the validated Tartan Ada
compilers handle these situations correctly.
-------
------------------------------------------------------------------------
From umd5!decwrl.dec.com!pyramid!uccba!hal!mandrill!asheem Fri Oct 16 20:42:59 1987
Date: 6 Oct 87 01:49:47 GMT
From: umd5!decwrl.dec.com!pyramid!uccba!hal!mandrill!asheem (Asheem Chandna)
Subject: Passing Procedures Over a Network
To: info-ada@ajpo.sei.cmu.edu
Hi,
After the recent discussions on "passing procedures as parameters," we
were thinking about some of the issues related to "passing procedures as
parameters over multi-processor target systems," and wondered if someone
on the net could perhaps discuss some of the issues, and enlighten us.
Of course (as discussed earlier on the net), Ada doesn't allow for the
passing of procedures as parameters (or at least not yet)!
Consider the case where an Ada program is written such that it contains
several tasks, each directed to a particular processor (by means of say a
pragma statement), and that these tasks use the rendezvous mechanism for
their communication. We want to pass procedures as parameters between the
tasks.
We are assuming, that only procedure names, not entire procedure calls with
parameters specified, would be the objects passed. One would probably prefer to
avoid passing a copy of an entire procedure over the local area network
for several reasons including the fact that processors may also have different
instruction set architectures. ALGOL-60 has the "call by name" parameter
passing mechanism where whole procedure calls could be passed -- one probably
wouldn't want to apply anything like that in this situation.
Now, any task making a procedure call will want a copy of the procedure in its
local environment. If one such task was passed another procedure, surely a copy
of that procedure should be in its local environment. Now, if a rendezvous from
a task residing outside the local environment passes a procedure through an
accept statement into the local environment, could one know the identity of the
set of possible procedures at compile time (from all the procedures available
of that particular type), and arrange to have copies resident in the local
environment? Is this a feasible solution or are we just thinking crazy?
Or, what are some other methods that could be applied towards tackling this
and related issues?
Thanks in advance for your comments.
Asheem Chandna and William Schultz.
VOICE: 216-368-4087
SNAIL: Center for Automation & Intelligent Systems Research,
Case Western Reserve University, Cleveland, Ohio 44106.
UUCP: asheem@mandrill.uucp OR {cbosgd,decvax,sun}!mandrill!asheem
ARPA: asheem@mandrill.cwru.edu OR asheem%mandrill.cwru.edu@berkeley.edu
CSNET: asheem@mandrill.cwru.edu OR asheem@case.csnet
------------------------------------------------------------------------
From umd5!seismo.css.gov!esosun!hyland Fri Oct 16 20:43:02 1987
Date: 7 Oct 87 00:47:09 GMT
From: umd5!seismo.css.gov!esosun!hyland (Steve Hyland)
Subject: Re: Passing Procedures Over a Network
To: info-ada@ajpo.sei.cmu.edu
In article <2268@mandrill.CWRU.Edu> asheem@mandrill.UUCP (Asheem Chandna) writes:
>Now, any task making a procedure call will want a copy of the procedure in its
>local environment. If one such task was passed another procedure, surely a copy
>of that procedure should be in its local environment. Now, if a rendezvous from
>a task residing outside the local environment passes a procedure through an
>accept statement into the local environment, could one know the identity of the
>set of possible procedures at compile time (from all the procedures available
>of that particular type), and arrange to have copies resident in the local
>environment? Is this a feasible solution or are we just thinking crazy?
>
>Or, what are some other methods that could be applied towards tackling this
>and related issues?
>
Asheem:
I was in on this discussion because I've been banging my head up against the
wall trying to design a nice mechanism for associating call_back procedures
and event_handlers for my X Toolkit package.
Here's what I'm now modeling:
I am creating mappings between objects in a domain and objects in a range.
Just as I can iterate through the objects in the domain and the objects
in the range, I can visit one object in the range.
In my mapping package, I supply a generic Visit procedure that allows me
this visitation right. The code looks something like this:
generic
with procedure message ( parameter_list );
procedure Visit ( OBJECT : in range );
the procedure Visit calls this message procedure.
But the part I really like is this - message can be a procedure OR an entry,
so long as it has the same parameter list.
So, for instance, using tasking:
task Dummy is
entry dummy_message ( parameter_list );
end Dummy;
with Dummy;
procedure Dummy_Visit is new Visit ( Message => dummy_message );
and when Dummy_Visit is called, it calls Dummy's entry. You could alternatively
associate that with a procedure call if you preferred.
I like this solution because it allows me to make a widget a more general
case with event_handlers and call_backs that can be associated with these
objects by the user.
I hope this helps. Has anyone else done anything similar ?
Steve Hyland
SAIC
Thanks to Mitchell Garth at Alsys for explaining about matching a formal
subprogram with an entry (LRM 12.3.6).
P.S. Grady, I got this idea from your new book. Any thoughts ?
------------------------------------------------------------------------
From umd5!husc6.harvard.edu!cca!mirror!ishmael!ada-uts!stt Fri Oct 16 20:43:08 1987
Date: 2 Oct 87 20:33:00 GMT
From: umd5!husc6.harvard.edu!cca!mirror!ishmael!ada-uts!stt
Subject: Re: Why one TYPE instead of the other?
To: info-ada@ajpo.sei.cmu.edu
The first form selects an underlying implementation
based on the range, which must be specified via *static*
expressions. This form may fail at compile-time if
the requested range cannot be supported by any predefined
type.
The second form specifies that predefined INTEGER
be used as the underlying implementation type,
and the range may be specified by arbitrary, potentially
run-time, INTEGER expressions.
This form will never fail at compile-time, but
may raise Constraint_Error at run-time if the range you
specify is outside of Integer'FIRST .. Integer'LAST.
Based on the above characteristics, the first form
is preferable when legal, since it is not dependent
on the relative sizes of the various predefined integer types,
and detects out-of-range problems at compile-time.
But as noted, it cannot be used if the desired bounds
are not static (which implies compile-time-known) expressions.
S. Tucker Taft
Intermetrics, Inc.
Cambridge, MASS
------------------------------------------------------------------------
From umd5!seismo.css.gov!sundc!pitstop!texsun!convex!authorplaceholder Fri Oct 16 20:43:12 1987
Date: 2 Oct 87 16:14:00 GMT
From: umd5!seismo.css.gov!sundc!pitstop!texsun!convex!authorplaceholder
Subject: Re: fortran --> ada translators
To: info-ada@ajpo.sei.cmu.edu
You start out talking about "translation," but then you bring up the issue
of "conversion." There is a big difference between the two. Translation
will produce a FORTRAN structured software system with Ada syntax. Conver-
sion will produce an Ada system taking advantage of the features of Ada
such as packages, generics, private types, and tasking. I believe there are
translators on the market, but I have not as yet heard of any successful
conversion product.
Marcia Bernhardt
Convex Computer Corporation
P. O. Box 833851
Richardson, Texas 75083-3851
------------------------------------------------------------------------
From umd5!hplabs.hp.com!gatech!pyr!walt Fri Oct 16 20:43:16 1987
Date: 7 Oct 87 19:19:52 GMT
From: umd5!hplabs.hp.com!gatech!pyr!walt (Robert Viduya)
Subject: Looking for ada error analysis data
To: info-ada@ajpo.sei.cmu.edu
Can anyone on the net assist me?
I am looking for data from any ada error collection studies.
Essentially, I need the results of studies indicating the
types of errors made by experienced ada programmers, and the
frequency of those errors.
If you have any information of this type - or where I might
find such info - contact me via the net
walt@gatech.edu
Thanks,
walt
------------------------------------------------------------------------
From umd5!uunet.uu.net!rosevax!ems!srcsip!jha Fri Oct 16 20:43:19 1987
Date: 6 Oct 87 20:57:53 GMT
From: umd5!uunet.uu.net!rosevax!ems!srcsip!jha (Rakesh Jha)
Subject: Tasking Implementation Strategies
To: info-ada@ajpo.sei.cmu.edu
Does anyone know of a commercial Ada compiler that employs the implementation
strategies proposed in the following papers:
1. Habermann A.N. and Nassi J.R. "Efficient Implementations of Ada
Tasks", TR CMU-CS-80-103, CMU, 1980
2. Hilfinger P. "Implementation Strategies for Ada Tasking Idioms",
Proceedings of the ACM AdaTech Conference on Ada, October 1982
I am particularly interested in the issues listed below:
1. The compiler's ability to determine where the proposed strategies may
be used.
2. If the scheme calls for the programmer to inform the compiler by a
pragma, the compiler's ability to detect programmer error.
3. A quantitative indication of performance gains achieved, if any.
4. In practical applications, the frequency of occurrence of Ada tasks for
which one of the above strategies is applicable.
Rakesh Jha
Honeywell Systems and Research Center
Minneapolis, Minnesota
{ihnp4, philabs, umn-cs, ems}!srcsip!jha
------------------------------------------------------------------------
From umd5!ucbvax.Berkeley.EDU!ihnp4!homxb!mtuxo!mtune!codas!killer!aimania Fri Oct 16 20:43:42 1987
Date: 8 Oct 87 05:03:48 GMT
From: umd5!ucbvax.Berkeley.EDU!ihnp4!homxb!mtuxo!mtune!codas!killer!aimania (Walter Rothe)
Subject: Verdix ADA
To: info-ada@ajpo.sei.cmu.edu
Our group is considering using Verdix ADA for the 386 but have
heard rumors of compiler problems on 68K systems. Does anybody
have experience using the compiler and debugger? The quoted
performance is certainly good at 5300 dhrystones per second
and the functionality of the debugger good but we would really
like to have a personal recommendation before purchasing the
package. Thanks in advance for your help.
--
Walter Rothe at the UNIX(Tm) Connection, Dallas, Tx
UUCP: {rutgers}!smu.killer.aimania
------------------------------------------------------------------------
From umd5!uunet.uu.net!steinmetz!moose!nieh Fri Oct 16 20:43:47 1987
Date: 9 Oct 87 15:22:56 GMT
From: umd5!uunet.uu.net!steinmetz!moose!nieh (nico nieh)
Subject: can not abort allocated tasks
To: info-ada@ajpo.sei.cmu.edu
I am writing a simulation program using Ada task facilities.
What I wanted to do is to be able to abort a task which
is activated by using the allocator.
The program segment looks like,
task type pool is
entry draw(which : out integer); -- contains an infinite loop
end
type t_pool is access pool;
pool_1 : t_pool;
pool_2 : pool;
begin
....
....
pool_1 := new pool;
...
...
abort pool_1;
However, both DEC/ADA and Verdix Ada compiler gave syntax error at the
abort statement.
According to the LRM,
abort_statement ::= ABORT task_name {,task_name};
the abort statement only takes task_names not pointers to task.
Is there any way to abort task pool_1 ?
Ko-Haw Nieh
General Electric Company
Corporate Research and Development
nieh@ge-crd.arpa
518-387-7431
------------------------------------------------------------------------
From umd5!ajpo.sei.cmu.edu!eberard Fri Oct 16 20:43:58 1987
From: umd5!ajpo.sei.cmu.edu!eberard
To: infoada@ajpo.sei.cmu.edu
Subject: Questions
Date: Mon, 12 Oct 87 07:00:40 EDT
Concurrency is a concept that seems simpler than it really is. Most
people can easily envision two or more "processes" executing
simultaneously. However, concepts such as how concurrency behaves on a
single processor system as opposed to a multiple processor system,
deadlock, starvation, race condition, and inter-process communication
are not easily understood.
One of the fundamental characteristics of concurrency that is
difficult for most people to understand is the concept of
indeterminacy. Sequential software is deterministic i.e., one can
predict precisely how the software will behave (even at a microscopic
level of detail) for a given set of conditions. Concurrent software,
on the other hand, is nondeterministic. Specifically, while the
macroscopic behavior of the software may be reasonably predictable,
the microscopic behavior of the software cannot be predicted with a
high degree of precision.
Few programmers have an in-depth understanding of concurrency issues.
For example, there have been any number of complaints that "Ada does
not allow the programmer easy access to the underlying scheduling
algorithm," or that "Ada does not have a specific (published)
scheduling algorithm." Complaints such as these indicate little
knowledge of concurrency in software.
It is important for Ada software engineers to realize that if they
wish their concurrent software to behave in the same general manner
with any given Ada system, it is possible to implement their source
code in such a manner so that this can be accomplished, regardless of
such things as the underlying implementation of the scheduling
algorithm.
Recently, I have become aware of some attempts to get around the
"problem" of nondeterminism in concurrent Ada software. The code word
here is "tailoring." For example, some Department of Defense (DoD)
contractors have required that Ada development system vendors allow
their customers to supply their own scheduling algorithms for tasking.
(Note: All requests for tailoring are not attempts to circumvent good
software engineering. It is entirely reasonable for software engineers
to request some degree of tailoring. Further, there is a certain
degree of flexibility allowed by the standard. Finally, there are
issues which are truly "outside of Ada," and are properly addressed by
tailoring.)
"So what is the big deal," you ask, "if some DoD contractor requires
that the scheduling algorithm for tasking be supplied by the Ada
development system vendor, or that the vendor allow the contractor to
'tailor' the scheduling algorithm?" Suppose that the Ada software is
sold to the government and that it is recompiled in part, or in whole,
using a different Ada compiler. The software may not only behave in an
erroneous manner, but the cause of the erroneous behavior will not be
easily determined from a knowledge of the source code alone.
Further, suppose that all members of the development team are not
informed about the (now deterministic) task scheduling algorithm, or
that maintenance personnel are equally uninformed. Developing,
testing, debugging, and maintaining concurrent software is difficult
enough without attempting a partial removal of indeterminacy.
So we have a number of technical, legal, and ethical questions:
1. If an Ada software engineer just happens to know what the
underlying scheduling algorithm is, should he or she design their
Ada software in a manner which takes direct advantage of this
knowledge?
2. Should an Ada software developer require that an Ada development
system vendor supply the scheduling algorithm for tasking, with
the intention of using this knowledge in the design and
implementation of the Ada software?
3. How much "tailoring" of an Ada development is to be allowed?
Specifically, at what point (or points) do we cross the line
between issues which are truly outside of Ada, and issues which
are best left to "language lawyers"?
4. If certain types of tailoring or knowledge of the underlying
implementation are to be discouraged, what alternatives are
available to the Ada software developers?
5. Are there published lists of questionable practices relating to
the above? Are there any published policies?
On one hand, I am aware that some of the issues I have raised can be
resolved by "language lawyers." On the other hand, some of these
questions (and others) are clearly outside of domain of the Ada
language definition.
-- Ed Berard
(301) 695-6960
eberard@ajpo.sei.cmu.edu
------------------------------------------------------------------------
From umd5!hplabs.hp.com!sdcrdcf!CAM.UNISYS.COM!jonab Fri Oct 16 20:44:06 1987
Date: 12 Oct 87 15:53:12 GMT
From: umd5!hplabs.hp.com!sdcrdcf!CAM.UNISYS.COM!jonab (Jonathan P. Biggar)
Subject: Re: can not abort allocated tasks
To: info-ada@ajpo.sei.cmu.edu
In article <7586@steinmetz.steinmetz.UUCP> nieh@moose.steinmetz (nico nieh) writes:
task type pool is
entry draw(which : out integer); -- contains an infinite loop
end
type t_pool is access pool;
pool_1 : t_pool;
begin
pool_1 := new pool;
abort pool_1;
>Is there any way to abort task pool_1 ?
The statement you need is:
abort pool_1.all;
The '.all' component refers to the entire object accessed by the access
type.
Jon Biggar
jonab@cam.unisys.com
------------------------------------------------------------------------
From umd5!mcnc.org!rti!jb Fri Oct 16 20:44:14 1987
Date: 12 Oct 87 17:37:28 GMT
From: umd5!mcnc.org!rti!jb (Jeff Bartlett)
Subject: Re: can not abort allocated tasks
To: info-ada@ajpo.sei.cmu.edu
How about
abort task_1.all;
since you wanted to stop what the pointer references not stop the pointer.
Jeff Bartlett
Research Triangle Institute jb@rti.rti.org mcnc!rti!jb
------------------------------------------------------------------------
From umd5!lll-tis.arpa!elxsi!beatnix!murphy Fri Oct 16 20:44:19 1987
Date: 12 Oct 87 21:17:05 GMT
From: umd5!lll-tis.arpa!elxsi!beatnix!murphy (Michael Murphy)
Subject: Re: can not abort allocated tasks
To: info-ada@ajpo.sei.cmu.edu
You need to dereference the task access, e.g.
abort pool_1.all;
That way you are aborting the task rather than the access value.
-- Michael P. Murphy
-- UUCP: sun!elxsi!elky!murphy
------------------------------------------------------------------------
From umd5!uunet.uu.net!mcvax!cernvax!ethz!claudio Fri Oct 16 20:45:00 1987
Date: 12 Oct 87 19:54:24 GMT
From: umd5!uunet.uu.net!mcvax!cernvax!ethz!claudio (Claudio Nieder)
Subject: Re: can not abort allocated tasks
To: info-ada@ajpo.sei.cmu.edu
In article <7586@steinmetz.steinmetz.UUCP> nieh@moose.steinmetz
(nico nieh) writes:
>What I wanted to do is to be able to abort a task which
>is activated by using the allocator.
>
>... the abort statement only takes task_names not pointers to task.
So you have to dereference the pointer ...
procedure TASK_REFERENCE is
task type TASK_TYPE;
type TASK_POINTER is access TASK_TYPE;
TASK_INSTANCE : TASK_POINTER;
task body TASK_TYPE is
begin
null; -- may be a never ending story ...
end TASK_TYPE;
begin
TASK_INSTANCE := new TASK_TYPE;
abort TASK_INSTANCE.all;
end TASK_REFERENCE;
... and your program will be accepted by the compiler.
Harry
------------------------------------------------------------------------
From umd5!husc6.harvard.edu!cca!mirror!ishmael!ada-uts!fitch Fri Oct 16 20:46:19 1987
Date: 12 Oct 87 13:27:00 GMT
From: umd5!husc6.harvard.edu!cca!mirror!ishmael!ada-uts!fitch
Subject: Re: can not abort allocated tasks
To: info-ada@ajpo.sei.cmu.edu
By using ".all" you can refer to a task object via a pointer.
So you want to specify
abort POOL_1.all;
If, however, this task does have an infinite loop, your abort
may not help you, since an "aborted" task may not become
completed until it hits a syncronization point, e.g. an accept
statement. Better to remove the loop and using a less severe
method to stop the task.
Geoff Fitch
Intermetrics, Inc.
733 Concord Ave.
Cambridge, MA 02138
------------------------------------------------------------------------
Date: 16 Oct 87 14:57:57 GMT
From: umd5!ucbvax.Berkeley.EDU!cbosgd!clyde!wayback!arny (Arny B. Engelson)
Subject: SIGAda/Ada Expo fees (question)
To: info-ada@ajpo.sei.cmu.edu
I was just going through the paperwork to register to the Dec. SIGAda/
Ada Expo meeting, and I noticed that (for the first time, if I'm not
mistaken) ther is a registration charge for SIGAda. A HEFTY $200 fee.
What it didn't indicate is if this included admission to the Expo. I
would think so, but it didn't say. Not only that, but an advertisement
for the Expo in Defense Science and Electronics asked for $250 for
attendance, with a $150 discount for SIGAda attendees. What gives?
Does anybody know what the actual charges are? And, why the $200 fee
all of a sudden? Is this necessary according to some ACM rule for SIGs,
or are the meetings becoming too expensive for local corporate sponsorship?
- Arny (see you in Boston) Engelson
------------------------------------------------------------------------