HDTenEightyP/NetNews huggingface dataset:
From: GBODSO1@NUSVM.BITNET (Jerry Seah)
Newsgroups: comp.lang.ada
Subject: FAX NUMBER FOR MERIDIAN
Date: 29 Sep 92 08:02:49 GMT
Distribution: world
Organization: The Internet

Hello world,
   Can somebody pass me the fax number of Meridian - the company that
sells a compiler for PCs.  Thanks.
Acknowledge-To: <GBODSO1@NUSVM>
Newsgroups: comp.lang.ada
From: larry@tsd.arlut.utexas.edu (Larry Maturo)
Subject: Re: Ada's (in)visibility
Organization: Applied Research Labs, The University of Texas at Austin
Date: Wed, 30 Sep 1992 13:54:44 GMT

In article <1992Sep29.152124.8143@brt.deakin.edu.au> dougcc@brt.deakin.edu.au (Douglas Miller) writes:
>In article <244.237.uupcb@nitelog.com>, michael.hagerty@nitelog.com
>(Michael Hagerty) writes:
>
>> The most coneheaded response I've heard to the question, "Why didn't you
>> do it in Ada, the mandated language?" was, "We had to be compatible with
>> X-windows, 
>
>I suppose their documentation for Xlib calls used C syntax, so they think
>this means they have to use C?  Coneheaded indeed.
>
>> It seems that all the excuses are like a**holes; everyone has one and
>> they all stink...
>
>How true...


To be fair Xlib is not suitable to mulitasking and most large Ada systems use
tasking.  There is no good solution to this probelem yet.  There are kludgy
workarounds however.  C++ will face this same problem if it ever gets tasking
added to it.  Modula-3 is the only language I know of that has a good multitasking
X-Windows compatible solution.  By the way, we use Ada and an X-Windows kludge
here so I'm not knocking Ada.

+-----------------------------------+----------------------------------------+
|                                   |                                        |
| Larry Maturo                      | Opinions expressed herein must be      |
| Tactical Simulation Division      | yours, neither I nor my employer have  |
| Applied Research Laboratories     | any.                                   |
| University of Texas at Austin     |                                        |
| P.O. Box 8029                     +----------------------------------------+
| Austin, Texas 78713-8029          |                                        |
|                                   | When you're as great as I am it's hard |
| larry@titan.tsd.arlut.utexas.edu  | to be modest, but I succeed where      |
|                                   | others fail.                           |
+-----------------------------------+----------------------------------------+
From: jbg@sei.cmu.edu (John Goodenough)
Newsgroups: comp.lang.ada
Subject: Re: Online source for CMU/SEI Ada tech reports?
Date: 5 Oct 92 15:13:17 GMT
Organization: The Software Engineering Institute


Many SEI reports are available via ftp as postscript files.  To see what is
available and to get complete instructions for accessing the reports, connect
to ftp.sei.cmu.edu (the internet address is 128.237.2.179), login as
anonymous, change directories to /pub/documents and get the READ.ME file for
complete information about what is available, things to keep in mind, etc.

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391
Newsgroups: comp.lang.ada
From: dag@control.lth.se (Dag Bruck)
Subject: Re: Ada's (in)visibility
Organization: Department of Automatic Control, Lund, Sweden
Date: Thu, 1 Oct 1992 07:17:57 GMT

In <comp.lang.ada> emery@Dr_No.mitre.org (David Emery) writes:
>
>The real solution for Ada and X Windows will occur when X Windows is
>multi-threaded in a way that meshes with Ada tasks.  

My _guess_ is that X will be compatible with POSIX threads, if X ever
gets threaded.  The question then is how compatible POSIX threads and
Ada tasks are...
From: MLB6@psuvm.psu.edu
Newsgroups: comp.lang.ada
Subject: Student Papers
Date: 5 Oct 92 15:24:08 GMT
Article-I.D.: psuvm.92279.112408MLB6
Organization: Penn State University


                        REMINDER
       Student papers are being accepted for the 11th Annual
       National Conference on Ada Technology until October 23.


  *********************************************************
  *             CALL FOR STUDENT PAPERS                   *
  *                                                       *
  *   11th Annual National Conference on Ada Technology   *
  *********************************************************

Submissions of student papers for  the 11th Annual National Conference
on Ada Technology are now being accepted.   As Ada has become an
integral part of many computer science programs, opportunities have
grown for valuable student experiences with Ada in the classroom and
beyond.  In concert with the conference theme, "Ada: Building Block of
Software Engineering", we are seeking student perspectives on projects
within the software engineering framework and from all areas of
the computer science curriculum, including applications in data
structures, database management, operating systems, real time systems,
and computer graphics.

Support for lodging for student presenters may be available.

Submit papers to:
    Ms. Kay Trezza, HQ CECOM, Center for Software Engineering
    Bldg. 1210, ATTN:
    AEL-RD-SE-CRM
    Ft. Monmouth, NJ  07703-5000

    or contact Marty Barrett, mlb6@psuvm.psu.edu for more information.

Submission Deadline: Oct. 23, 1992
Final Copy: Nov. 13, 1992
Conference Dates: March 15-18, 1993
Williamsburg Hilton and National Conference Center
Williamsburg, VA.
Newsgroups: comp.lang.ada
From: young@gdfwc3 (Mark Young)
Newsgroups: comp.lang.ada
Subject: Generic Package Visibility Problems! (help)
Date: 2 Oct 92 18:35:52 GMT
Distribution: comp
Organization: General Dynamics, Fort Worth Division


I am having visibility problems with generic packages.

Here's an example:

file #1
-----------------------------------------------
generic 

  Generic_Parameter : Generic_Parameter_Type;

package Color is

  type RGB_Type is (RED,GREEN,BLUE);

  function Get_Color return RGB_Type;

end Color;
----------------------------------------------
file #2
----------------------------------------------
with Color;

package Caller is

  package C_1 is new Caller( Generic_Argument );

  procedure Test_Color;

end Caller;

package body Caller is 

  procedure Test_Color is separate;

end Caller;
---------------------------------------------
file #3
---------------------------------------------
separate( Caller )

procedure Test_Color is

begin

  if ( C_1.Get_Color = C_1.RED ) then
	               -------
	null;

  end if;

end Test_Color;
----------------------------------------------

This will not work.  For some reason the compiler cannot
resolve C_1.RED.  It tells me that = is not a legal 
operation, that C_1.Get_Color returns type RGB_Type but, 
that it does not understand C_1.RED and that perhaps I 
needed a "use" clause in the body of Caller.  I don't
understand this.  My understanding of Ada scoping would
lead me to believe that this is correct.  Am I missing 
something?  

BTW: this is not a complete example, it is only to illustrate
a point.

Thanks,

Mark Young
From: dmarshal@Stars.Reston.Unisys.COM (Dave Marshall)
Newsgroups: comp.lang.ada
Subject: Re: converting (limited) private types?
Date: 26 Sep 92 21:08:29 GMT
Organization: Unisys Corporation, Reston, VA

In article <1a0ijeINNfei@huon.itd.adelaide.edu.au>, andrewd@cs.adelaide.edu.au (Andrew Dunstan) writes:

[some stuff deleted]
> Trouble is, file types in Ada are limited private. So you can't assign
> to objects of the type. So you can't make a stack of them.
> 
> While pondering this, an evil thought came into my head. Before succumbing
> to my better feelings, I quickly dialled up the university and tried the
> following:
> 
>   with text_io; use text_io;
>   with unchecked_conversion;
>   procedure file_conv is
> 
Ack! A totally UNJUSTIFIED use of UNCHECKED_CONVERSION!  Flagellate yourself
thrice daily for a week.

[remainder of evil program deleted]
> 
> What I want to know is:
> 
> (1) APART from any righteous feelings about breaking the language's
> privacy mechanism, are there any good reasons for not doing something
> like this?

Yes.  Don't used UNCHECKED_CONVERSION if you don't have to.

> 
> (2) Is there a better way to do it, one which does not rely on this
> sort of hack?

Yes. Access types.  A simple example follows at the end of this response.

> 
> (3) How can I close the damned file? (I've thought of a really disgusting
> way, which oddly enough should be reasonably portable, but I certainly won't
> publish it on the net.)

Maybe that's for the best. :)  [No chops-busting intended.]

What follows is my trivial example of using access types to keep track of
limited private types.  In it, I keep an array of FILE_TYPE while I create
files, write to them, and close them.  Creating a stack package, or even
using some other generic stack package, ought to be equally trivial.

Here it is:


with TEXT_IO;

procedure FILE_TEST is

  type FILE_POINTER is access TEXT_IO.FILE_TYPE;

  type POINTERS is array ( INTEGER range <>) of FILE_POINTER;

  MY_ARRAY   : POINTERS(1..5);

  SOME_NAMES : constant array (INTEGER range 1..5) of STRING(1..8) :=
    ( "myfile.1",
      "myfile.2",
      "myfile.3",
      "myfile.4",
      "myfile.5");

begin

  for I in MY_ARRAY'RANGE loop

    MY_ARRAY(I) := new TEXT_IO.FILE_TYPE;

    TEXT_IO.PUT_LINE( "Creating file" & INTEGER'IMAGE(I));

    TEXT_IO.CREATE ( MY_ARRAY(I).all, NAME => SOME_NAMES(I));

  end loop;

  for J in MY_ARRAY'RANGE loop

    TEXT_IO.PUT_LINE ( "Writing to file" & INTEGER'IMAGE(J));

    TEXT_IO.PUT_LINE ( MY_ARRAY(J).all, "I am file" & INTEGER'IMAGE(J));

  end loop;

  for K in MY_ARRAY'RANGE loop

    TEXT_IO.PUT_LINE ( "Closing file" & INTEGER'IMAGE(K));

    TEXT_IO.CLOSE ( MY_ARRAY(K).all);

  end loop;

end FILE_TEST;

Apologies to purists everywhere who take offense at my sloppiness in the
declarative section.  Have a nice day.
-- 
                                           Dave Marshall
                                           dmarshal@stars.reston.unisys.com
From: dougcc@brt.deakin.edu.au (Douglas Miller)
Newsgroups: comp.lang.ada
Subject: Re: INFO-ADA Digest V92 #299
Date: 1 Oct 92 15:51:59 GMT
Organization: C&CS, Deakin University

In article <2AAE10C8@ncgate.ccscnet.af.mil>,
BUSHMAN@MITECMAIL.CCSCNET.AF.MIL writes:

> As I stated
> in the last paragraph, Ada is a very large language.  For someone wanting to
> get some programming experience, as your first language to tackle, Ada would
> be much harder to learn than others, such as COBOL.  

This sounds like nonsense to me.  You are surely better off starting with
a modern language first, rather than unlearning the skills of an obsolete
one later.

This kind of objection to Ada was criticised by Jean Ichbiah who compared
it to examining the engineering blueprints for a new auditorium, and then
saying "this building is much too complex, people will never be able to
find their way into the foyer".

> When learning how to
> swim, do you start by jumping in the middle of the lake and hope you survive
> to the shore?  Probably not.  And the same holds true for programming.  Start
> with the basics and then move on to bigger and better things

This seems to be sound advice.

>  (like Ada, if you find you like programming).

If the end objective is to learn Ada, then start with Ada --- just start with
the basic features, then move on to more advanced ones later.  Learning
COBOL as an introduction to Ada would be a futile exercise.
Newsgroups: comp.lang.ada
From: wallace@bonmot (Richard Wallace)
Subject: Generic Package Visibility Problems! (help)
Organization: Digital Equipment Corporation
X-Newsreader: Tin 1.1 PL3
Distribution: comp
Date: Fri, 2 Oct 1992 23:25:01 GMT

young@gdfwc3 (Mark Young) writes:
: I am having visibility problems with generic packages.
: Here's an example:
: file #1
: -----------------------------------------------
: generic 
:   Generic_Parameter : Generic_Parameter_Type;
: package Color is
:   type RGB_Type is (RED,GREEN,BLUE);
:   function Get_Color return RGB_Type;
: end Color;
: ----------------------------------------------
: file #2
: ----------------------------------------------
: with Color;
: package Caller is
:   package C_1 is new Caller( Generic_Argument );
:   procedure Test_Color;
: end Caller;
: package body Caller is 
:   procedure Test_Color is separate;
: end Caller;
: ---------------------------------------------
: file #3
: ---------------------------------------------
: separate( Caller )
: procedure Test_Color is
: begin
:   if ( C_1.Get_Color = C_1.RED ) then
: 	               -------
: 	null;
:   end if;
: end Test_Color;
: ----------------------------------------------
: This will not work.  For some reason the compiler cannot
: resolve C_1.RED.  It tells me that = is not a legal 
: operation, that C_1.Get_Color returns type RGB_Type but, 
: that it does not understand C_1.RED and that perhaps I 
: needed a "use" clause in the body of Caller.  I don't
: understand this.  My understanding of Ada scoping would
: lead me to believe that this is correct.  Am I missing 
: something?  
: 
: BTW: this is not a complete example, it is only to illustrate
: a point.
: 
: Thanks,
: 
: Mark Young


Well Mark,

	This won't work for the following reasons:

	1) You haven't used the generic formal in your generic package.
	2) You have passed to the generic formal a very odd data type.
	3) You are using a function in the body of TEST_COLOR wrong.

	The following corrected program does what you want to do.

-- ++
-- file #1
-- -- 
generic 
   type GENERIC_PARAMETER_TYPE is (<>);
package COLOR is
   RGB_TYPE : GENERIC_PARAMETER_TYPE;
   function GET_COLOR return GENERIC_PARAMETER_TYPE;
end COLOR;
-- ++
-- file #2
-- --
with COLOR;
package CALLER is
   type ZIPPY is ( RED, GREEN, BLUE );
   package C_1 is new COLOR( ZIPPY );
   procedure Test_Color;
end CALLER;

package body CALLER is 
  procedure TEST_COLOR is separate;
end CALLER;
---------------------------------------------
--file #3
---------------------------------------------
separate( CALLER )
procedure TEST_COLOR is
begin
  if ( RED = C_1.GET_COLOR ) THEN
      null;
  end if;
end TEST_COLOR;

============================
Hope this helps!

Richard Wallace
Digital Equipment Corporation
301 Rockrimmon Blvd. South
CXO2-1/7A
Colorado Springs, CO 80919-2398
(719)548-2792
<wallace@cookie.enet.dec.com>

	"The opinions expressed are my own, Uncle Ken or Uncle Bob
	 may, or may not, agree with me."

Newsgroups: comp.lang.ada
From: rlk@VisiCom.COM (Bob Kitzberger)
Newsgroups: comp.lang.ada
Subject: Re: Ada's (in)visibility in the engineering community
Date: 6 Oct 92 18:32:30 GMT

val@news.ccutah.edu (Val Kartchner) writes:

>To answer this question, we must first understand what is meant by "real-time"
>as used in the English language.

No, we don't need to know what common English usage is.  Go ask the folks in
comp.realtime for their definition; you'll find that "fast enough" is
usually the speed requirement, not "real fast".  

One of the major components of real-time systems is support for concurrency.
Ada does have language support for concurrency, to be improved upon in Ada9x.
C/C++ do not have _language_ for it.  While you may validly argue that 
concurrency doesn't belong in the language but belongs in the OS, (and
I'd be very sympathetic to that point of view) you can't argue that 
C/C++ have _language_  support for concurrency.

>Also, more likely than not, you are reading this message because it was
>delivered to you by some networking protocol that was written in C.  You
>may even be reading it on an X-windows terminal (whose protocol was
>written in C) or some terminal emulation program (also most likely written
>in C).

You may be flying to your next conference on a plane whose flight-control 
software was written in Ada.

Which is the more real-time application?

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888
Newsgroups: comp.lang.ada
From: psm@nosc.mil (Scot Mcintosh)
Subject: Online source for CMU/SEI Ada tech reports?
Organization: Naval Ocean Systems Center, San Diego
Date: Wed, 30 Sep 1992 00:39:57 GMT

I've been given some technical reports prepared by the Carnegie
Mellon University SEI Join Program Office. They have titles
such as "Real-Time SOftware Engineering in Ada: Observations
and Guidelines". The person who gave them to me said he got
them via the internet, but couldn't remember where.

I'd like to get others in the series. Can anyone tell me
where they might be archived? If it's any help, the report
I cited earlier has a number, CMU/SEI-89-TR-22 associated
with it.

Thanks for any help.

----
Scot McIntosh
Internet: psm%helios.nosc.mil@nosc.mil
UUCP:     {ihnp4,akgua,decvax,decwest,ucbvax}!sdscvax!nosc!psm
"It's not a bug, it's a limitation" - Microsoft Tech Assistant

-- 
----
Scot McIntosh
Internet: psm%helios.nosc.mil@nosc.mil
UUCP:     {ihnp4,akgua,decvax,decwest,ucbvax}!sdscvax!nosc!psm
Newsgroups: comp.lang.ada
From: emery@Dr_No.mitre.org (David Emery)
Subject: Re: Ada's (in)visibility in the engineering community
Organization: The Mitre Corp., Bedford, MA.
Date: Mon, 5 Oct 1992 21:49:07 GMT

>Now that that has been addressed, my original point is that C and (by
>inheritance) C++ are commercial real-time successes.  If you doubt this
>statement, then tell me, why are you not reading this message on a computer
>whose operating system was written in Ada.  While I am not a great fan of
>U*X itself, you are more likely than not, reading this message on a U*X
>system.

The "conventional" meaning of real-time is a system that must respond
to external events within (usually restrictive) timing constraints.
My workstation and text editor are not real-time in this sense,
because the only thing that happens when I don't get an adequate
response is that I get mad.  Nothing goes boom or falls out of the
sky. 

This is not true of things like flight simulators and airplanes,
themselves.  Although most of the commercial real-time operating
systems (e.g. Lynx) are written in C or assembler, there is a large
body of real-time embedded code that is written in Ada, operating
system and all.  Boeing has many commercial examples that fly now.

Furthermore, the BiiN operating system (which provided a System V
interface) was itself written in Ada, with a C binding!  (It is fair
to note that BiiN was not sucessful, but my observation was that Ada
was not the cause of the problem.  The problem with BiiN was lack of
marketing.  Now, 5 years after its death, I'd still like to have a
system with the functionality of the BiiN system, particularly its
network object orientation.)

				dave
From: tne@world.std.com (Thomas N Erickson)
Newsgroups: comp.lang.ada
Subject: Re: Ada's (in)visibility
Date: 4 Oct 92 13:08:05 GMT
Organization: The World Public Access UNIX, Brookline, MA




>To be fair Xlib is not suitable to mulitasking and most large Ada systems use
>tasking.  There is no good solution to this probelem yet.  There are kludgy
>workarounds however.  C++ will face this same problem if it ever gets tasking
>added to it.  Modula-3 is the only language I know of that has a good multitasking
>X-Windows compatible solution.  By the way, we use Ada and an X-Windows kludge
>here so I'm not knocking Ada.


We at Alsys have just released a product call AdaXlib, which is an Ada
implementation of the X library, including support for multi-tasking. 
This should address much of the needs for Ada support for X-Windows.

Tom Erickson
Alsys
tne@world.std.com

(617)270-0030
Newsgroups: comp.lang.ada
From: emery@Dr_No.mitre.org (David Emery)
Subject: Re: Derived types and portability
Organization: The Mitre Corp., Bedford, MA.
Date: Mon, 28 Sep 1992 02:17:33 GMT

>I have always achieved portability by using user-defined types such as:
>
>     type MY_INTEGER is range 0 .. 2**32-1;
>
>However, I recently came across a document that suggested using derived types
>in combination with length representation clauses to achieve portability:
>
>    type MY_INTEGER is new INTEGER;
>    for MY_INTEGER'SIZE use 32;

The author of that document is "not helpful".  One of three cases occur:
(assuming that INTEGER'LAST = 2**INTEGER'SIZE -1)
	1.  INTEGER'SIZE = 32;  -- in this case, the rep. clause is
redundant and has no effect on portability.
	2.  INTEGER'SIZE < 32;  -- some compilers will reject the rep.
clause, while others will probably generalte abysmal code, as they
'backfill' 16-bit (or whatever) valuse into a 32-bit MY_INTEGER
object.  I don't see how this helps portability.
	3.  INTEGER'SIZE > 32;  -- in this case, the rep. clause will
always fail, as it is not big enough.

There are two approaches for portability.  One is to specify the exact
range you want.  Note that the declaration
	type MY_INTEGER is range 0..2**32-1;
is quite likely to fail on most compilers with 32-bit integers, due to
the requirement for symmetry around integers.  

The other way is to set up a "test" for INTEGER'SIZE, that will act as
an assertion on the size of integer:
    declare
	subtype ASSERTION is BOOLEAN range TRUE..TRUE;

	INT_IS_32_BITS : ASSERTION := INTEGER'SIZE = 32;
		-- most compilers will generate a warning here
		-- this will certainly fail at runtime.
    begin
	null;	
    exception;
	when CONSTRAINT_ERROR => TEXT_IO.PUT_LINE ("INTEGER'SIZE not 32 bits");
    end;


				dave
Newsgroups: comp.lang.ada
From: nreich@seas.gwu.edu (Norman Reich)
Subject: Ada question: access types
Originator: nreich@seas.gwu.edu
Organization: George Washington University
Distribution: usa
Date: Sun, 4 Oct 1992 21:17:34 GMT

Hi!  I am a new user to Ada (about 2 weeks), and new to
this newsgroup as well (about 2 minutes).  It was suggested
that I try out this newsgroup to seek help with a problem
that I was having.  I hope that I'm not misuing the group.
Anyway, here is my question:

I am using an IBM PS/2 with Meridian Ada, although I don't
think what I'm doing should be compiler dependent.

NOTE: Everything below is simplified to get my point across.

I have the following definitions:

     TYPE ptr IS ACCESS node;
     TYPE node IS
       RECORD
         name ...
         ...
         nextn :ptr;
       END RECORD;

     nl :ptr;

Within the program, I am doing a comparison, to see if the
list is empty or not:

     if (nl = NULL) then          --error at this line
     ...

The compiler is then giving me the following error at the
line above:

     type clash in parameter to "="

I have no idea why it would be doing this, and in examples
I have seen similar things done.  If anybody has any suggestions
that would be helpful, I would really appreciate it.

Thanks.

- Norman Reich
  nreich@seas.gwu.edu
  (301) 937-4858
From: rlk@VisiCom.COM (Bob Kitzberger)
Newsgroups: comp.lang.ada
Subject: Re: Declaring Arrays of Bits (how)?
Date: 29 Sep 92 18:33:24 GMT
Distribution: comp


>I am trying to declare arrays of bits in Ada.  Here's my attempt:
>
>type Array_Range_Type is range 1..128;
>
>type Bit_Type is (OFF, ON);
>for  Bit_Type use (OFF => 0, ON => 1);
>for  Bit_Type'size use 1;
>
>type Bit_Array_Type is array (Array_Range_Type) of Bit_Type;

Try slapping a rep spec on the array type:

   for Bit_Array_Type'size use 128;


	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888
Newsgroups: comp.lang.ada