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 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbvax!grebyn.COM!karl From: karl@grebyn.COM (Karl A. Nyberg) Newsgroups: comp.lang.ada Subject: Past info-ada mail Message-ID: <8710200612.AA01239@grebyn.com> Date: Tue, 20-Oct-87 02:12:08 EDT Article-I.D.: grebyn.8710200612.AA01239 Posted: Tue Oct 20 02:12:08 1987 Date-Received: Wed, 21-Oct-87 20:22:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: 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 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 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 ------------------------------------------------------------------------