HDTenEightyP/NetNews huggingface dataset:
From: schonber@acf3.NYU.EDU (Ed Schonberg)
Newsgroups: comp.lang.ada
Subject: Re: Ada's (in)visibility in the engineering community
Date: 28 Sep 92 21:23:00 GMT
Organization: New York University


Relay-Version: version nyu B notes v1.6.1 1/11/90; site acf3.NYU.EDU
From: schonberg@cs.nyu.edu (Edmond Schonberg)
Date: 28 Sep 92 16:52 EDT
Subject: Ada's (in)visibility in the engineering community

Val Kartchner (cal@news.ccutah.edu) say:
>  My opinion: "Although the Ada community would never state it so baldly, it
>     appears clear to us that Ada 9X, is to some extent, a reaction to C++
>     By extending Ada with SOME of the best ideas of C++, Ada did, in some
>     measure, catch up to C++."

I fully agree, language designers certainly learn from each other,
and it is perfectly clear to everyone associated with the Ada9X project
that C++ is the most direct contender in use today. Of course, the final
sentence should not be in the past tense: Ada9X is not a completed
design yet. Furthermore, the borrowings from Ada into C++ are (at this
point) more apparent that the borrowings from C++ to Ada9X. Some
aspects of Ada9X are indeed a reaction to C++, but most of Ada9X
consists of extensions and generalizations of Ada facilities, and remain
very much within the spirit of the original language. 

> Well, it would seem that Mr. Schonberg was incorrect, since Bjarne
> Stroustrup has stated publicly numerous times that Ada was the
> inspiration for some of the features that he put in C++.  
 
> The C++ Programming Language: Second Edition," (Introduces templates and
> exception handling to the C++ language) p. 4:

>    The template facility was partly designed to formalize macro usage, partly
>    inspired by the Ada generics 

My apologies for having missed this reference; the first edition of the
book had no mention of Ada, and in  the public presentations I have
attended Ada was NEVER mentioned. It stands to reason that Ada would
have to be mentioned in connection with generics and exceptions. Even
though some prefiguration of these features appeared in older languages,
it is fair to say that Ada was the first reasonably widespread language
to develop these features fully. When I mentioned "the C++ community" I
did not mean Bjarne Stroustrup, whose erudition does not need my praise,
but the great majority of C++ programmers, who might have an instinctive
reaction against Ada, even when some features of their favorite language
owes something to it. We might as well aknowledge the extent to which
we influence each other. How else will we learn to write better
software?

Ed Schonberg

New York University
schonberg@cs.nyu.edu
From: hep@eurocontrol.de (Guenter Hepke)
Newsgroups: comp.lang.ada
Subject: Q: C3Ada R02-04
Date: 29 Sep 92 13:16:18 GMT
Distribution: world
Organization: The Internet

Our Concurrent machines (3280) are part of a interconnected computer system.
Each computer has its own system time which makes  the correlation of the
different log files not easy.
Solution: Dispachting of the system time from a 'master' to the others in
reasonable intervals, e.g. once in 24 hours.
Problem and question: What will be the effect on the C3Ada runtime system 
concerning times (CALENDAR) if the 3280 system time is updated.

Thanks, if anyone knows,
Guenter Hepke, hep@eurocontrol.de
From: alex@cs.umd.edu (Alex Blakemore)
Newsgroups: comp.lang.ada
Subject: Re: Ada question: access types
Date: 5 Oct 92 02:33:12 GMT
Distribution: usa
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742

In article <1992Oct4.211734.9047@seas.gwu.edu> nreich@seas.gwu.edu (Norman Reich) writes:

Assume
package my_types is

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

and in another library unit 
>      if (nl = NULL) then          --error at this line
>      type clash in parameter to "="

type ptr is probably in a different package than the if statement.
you probably made type ptr visible via a with clause and did not
make it _directly_ visible via a use clause.  this is probably the
most common "error" new users hit and Ada9X is more forgiving here.
The error message could be better though.

Remember the function "=" (left, right : ptr) is implicitly
defined just after the definition of type ptr.

Your choices are:
a. invoke "=" using dotted infix notation.
   if my_types."=" (nl, null) then
b. make my_types."=" directly visible by adding a use clause.
   use my_types;
c. rename my_types."=" to make it directly visible
   function "=" (left, right : my_types.ptr) renames my_types."=";
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted
Newsgroups: comp.lang.ada
From: paul@ecpdstea.cern.ch (Paul Burkimsher)
Subject: Who uses Ada in New Zealand?
Organization: CERN European Lab for Particle Physics
Date: Thu, 1 Oct 1992 08:25:18 GMT

... because I'd like to join 'em!

Paul

---------------

Paul Burkimsher
European Laboratory for Particle Physics,
CERN
CH-1211 Geneva 23
Switzerland

Tel: +41-22-767-4915
Fax: +41-22-767-3900

paul@dxcern.cern.ch
paul@vxcern.cern.ch
paul AT dxcern (BITNET)
...!uunet!dxcern!paul (UUCP)
vxcern::paul (HEPNET) (22.190=22718)
From: simonson@cs.washington.edu (Kevin Simonson)
Newsgroups: comp.lang.ada
Subject: Re: Ada question: access types
Summary: "Type clash" might be symptom of a previous semantic error.
Keywords: type clash visibility
Date: 5 Oct 92 15:38:17 GMT
Article-I.D.: beaver.1992Oct5.153817.29108
Distribution: usa
Organization: Computer Science & Engineering, U. of Washington, Seattle


     In article <60887@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:

=In article <1992Oct4.211734.9047@seas.gwu.edu> nreich@seas.gwu.edu (Norman
=Reich) writes:
=
=Assume
=package my_types is
=
=>      TYPE ptr IS ACCESS node;
=>      TYPE node IS
=>        RECORD
=>          name ...
=>          ...
=>          nextn :ptr;
=>        END RECORD;
=>      nl :ptr;
=
=and in another library unit 
=>      if (nl = NULL) then          --error at this line
=>      type clash in parameter to "="
=
=type ptr is probably in a different package than the if statement.
=you probably made type ptr visible via a with clause and did not
=make it _directly_ visible via a use clause.

     This is probably the problem, but let me also note that after copying
exactly what Norman had written into a _single_ file, I got nearly the
same error message he was talking about.

     My compiler (Verdix) told me:

   if (nl = NULL) then
---------#^#
-- error: RM 4.5: does not conform to any visible operator              #^#

which sounded similar to the error message Norman got.

     However, earlier in my code I also got the message:

   TYPE ptr IS ACCESS node;
---------------------#^#
-- error: RM 8.3: identifier undefined                                  #^#

     Apparently if "nl" is defined as a type that the compiler doesn't un-
derstand, then it concludes that the type of "nl" doesn't match with
"NULL".  I added

   type node;

earlier in the program and it compiled just fine.  Norman, you might check
your code to make sure you referred to type "node" before the line that de-
fined "ptr".

                                     ---Kevin
Newsgroups: comp.lang.ada
From: boubaker@cenatls.cena.dgac.fr (Heddy Boubaker)
Newsgroups: comp.lang.ada,comp.emacs,gnu.emacs.help
Subject: Ada mode for lemacs
Keywords: Ada,emacs,ada-mode,dired,elisp,lucid emacs
Date: 30 Sep 92 13:06:43 GMT
Organization: Centre d'Etudes de la Navigation Aerienne
Originator: boubaker@bendy



  Hi emacs hackers

 We use now the lemacs (lucid emacs v 19.3.1) editor and the problem is
 we can no more use the GNU Ada-mode (v 1.05 for emacs 18.*) because of 
 compatibility problems with the new version of dired. 
 What i want to know is:

  has someone allready adapted the gnu-ada mode to this version of dired 
  or does it exists somewhere a good ada mode , with feature similar to 
  gnu-ada (specialy compilation with review of errors), wich could be used
  with lucid emacs or is there a simple solution (i don't know enougth 
  elisp for an advanced solution) to adapt the ada-mode with new dired.

 thanks in advance


 /----------------------------------------------------------------------\
 |         B O U B A K E R    H e d d y             | ())()((())))()(() |
 |                  [  C.E.N.A  ]                   | ) ~~~ | ~~~~~  )) |
 | Centre  d ' Etudes  de  la  Navigation  Aerienne | (--O--|---O----() |
 | 7 , av Edouard BELIN                             | #     L_       #  |
 |                         31 055 TOULOUSE (FRANCE) |  #  ######    #   |
 | Phone: (+33) 62-25-95-22  Fax: (+33) 62-25-95-99 |   ##(----)#  #    |
 | InTerNet:    BOUBAKER@dgac.fr                    |    ## ### ##      |
 \----------------------------------------------------------------------/
Newsgroups: comp.lang.ada
From: jjs@sei.cmu.edu (Jeffrey Stewart)
Subject: Re: Using Global Variables
Organization: Software Engineering Institute
Date: Mon, 28 Sep 1992 14:51:48 GMT

We are currently working with a design simulator project which will be running as either real-time or non real-time, depending on the site where it is 
installed.  One of the engineering goals for this simulator was to be as
run-time configurable as possible, given certain limitations of Ada.

Our approach has been to incorporate some of the concepts of OODBs, where there
is a central allocator of memory to which the objects subscribe, the objects
then receive a pointer to their instance data.  Objects are the only ones that
know about their instance data.  Other access to the instance data is done 
through the OODB services, which can provide pointer access to objects (for the
record/play capability, with the items to be recorded being configurable at 
run-time), or through direct requests for getting or setting the state of a 
given object.  Direct pointer access for record/play is required since some 
kind of look-up mechanism is needed to first find the objects, which is 
certainly not a "real-time" operation.

The only run-time overhead during the actual simulation run involves
pointer access, which we've found to be acceptable.   

Newsgroups: comp.lang.ada
From: srctran@world.std.com (Gregory Aharonian)
Subject: Interesting C++ market statistic
Organization: The World Public Access UNIX, Brookline, MA
Date: Mon, 5 Oct 1992 17:47:30 GMT

   Here's an interesting C++ market statistic.  From an article in the
October 5 issue of InformationWeek (the article is about Computer Automation
buying the Glockenspiel C++ compiler company):
	"Most corporate users develop in traditional languages such
         as Cobol on large computers, but compilers such as C and C++
         dominate PC development.  "More than 80% of corporate developers
         are seriously looking at C++ and 20% are already actively
         using it", claims Livleen Singh, editor of the 'C++ Journal'
         in Port Washington, NY.
         Sales of C++ are expected to more than double this year to
         $219 million, according to researcher InfoCorp in Santa Clara".

Admittedly newsletters exaggerate the size of such markets, and success rates,
(like the billion dollar forecasts for the neural network markets), but even
discounted, these comments reflect C/C++ growing dominance of the commercial
software development marketplace.

Any forecasts of the impact on Ada's ability to lower defense software
development costs will have to be lowered as the free markets of supply and
demand for software tools and programmers focuses on C/C++.

Greg Aharonian
Source Translation & Optimization
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178
Newsgroups: comp.lang.ada
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Ada's (in)visibility in the engineering community
Organization: Texas Instruments Inc
Date: Tue, 29 Sep 1992 14:41:29 GMT

In <61990005@acf3.NYU.EDU> schonber@acf3.NYU.EDU (Ed Schonberg) writes:


>Relay-Version: version nyu B notes v1.6.1 1/11/90; site acf3.NYU.EDU
>From: schonberg@cs.nyu.edu (Edmond Schonberg)
>Date: 28 Sep 92 16:52 EDT
>Subject: Ada's (in)visibility in the engineering community

>Val Kartchner (cal@news.ccutah.edu) say:
>> Well, it would seem that Mr. Schonberg was incorrect, since Bjarne
>> Stroustrup has stated publicly numerous times that Ada was the
>> inspiration for some of the features that he put in C++.  

I think you may have misattributed this bit, since I think it was mine
and not Val's.  I say 'think' because I'm not positive, since Val and
I posted notes on this subject that were quite similar in several
places. 

>My apologies for having missed this reference; the first edition of the
>book had no mention of Ada, and in  the public presentations I have
>attended Ada was NEVER mentioned. It stands to reason that Ada would
>have to be mentioned in connection with generics and exceptions. Even
>though some prefiguration of these features appeared in older languages,
>it is fair to say that Ada was the first reasonably widespread language
>to develop these features fully. When I mentioned "the C++ community" I
>did not mean Bjarne Stroustrup, whose erudition does not need my praise,
>but the great majority of C++ programmers, who might have an instinctive
>reaction against Ada, even when some features of their favorite language
>owes something to it. We might as well aknowledge the extent to which
>we influence each other. How else will we learn to write better
>software?

Actually, so far as I know, Bjarne has always been quite forthcoming
about which parts of C++ were inspired by what languages (including
Ada).  He has made repeated public statements about this, and just
recently posted about it again in comp.lang.c++.  I'm curious; have
you had large numbers of people from "the C++ community" denying that
any parts of C++ were inspired by Ada?  I ask this because, frankly,
the only time I've ever seen anyone claim that nothing in C++ came
from Ada is when Ada people attribute it to C++ people.  I've never
seen anyone from "the C++ community" say this.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.lang.ada
From: mfeldman@seas.gwu.edu (Michael Feldman)
Subject: Re: Ada's (in)visibility in the engineering community
Organization: George Washington University
Date: Thu, 1 Oct 1992 04:11:12 GMT

In article <1992Sep30.131146.2225@lth.se> dag@control.lth.se (Dag Bruck) writes:
[stuff deleted]
>
>In my experience, the C++ community is not very interested in Ada,
>which probably is a pity.  I don't really understand why some people
>in the Ada community spend so much time comparing with C++; isn't Ada
>good enough in itself?  Does it really matter much who's influenced
>who?  I think it smells of envy because C++ is a greater commercial
>success.
>
Amen to that! Let's quit the quibbling, get back to business,
recognize Ada for what it is, and work hard to make it a commercial
success. (Vendors: are you listening out there?)

Mike Feldman

Newsgroups: comp.lang.ada
From: goodsenj@ajpo.sei.cmu.edu (John Goodsen)
Subject: Re: Ada's (in)visibility
Organization: Ada Joint Program Office
Date: Fri, 2 Oct 1992 06:34:09 GMT

emery@Dr_No.mitre.org (David Emery) writes:
>
>>To be fair Xlib is not suitable to mulitasking and most large Ada systems use
>>tasking.  There is no good solution to this problem yet.
>
>There is a very good solution to this.  Don't use tasks.  Write
>sequential Ada.  This provides EXACTLY the same kind of program you
>would get if you wrote the application in C.  
>

This is a poor solution.  It is quite feasible to use Ada
tasking with Xlib applications, however, you must design
the application up front to ensure that only a single thread
is making Xlib calls up front.  The problem gets harder if
you attempt to address the potential for deadlock within a task
caused by a callback into the application.  In this case, you
need access to the task id to ensure you don't lock out the same
thread more than once.  See the Xhibition 91 conference proceedings
for a paper on this subject.

>Just because Ada has
>tasking, there is no obligation to use it in any specific application.
>I'm always bothered by people who use lack of support for Ada's
>advanced featuers to write a program in C that can be done in
>equivalent Ada (without tasking, for instance).
>


>
>An true Ada binding to Xlib should handle the tasking issue (perhaps
>by abstracting a kludge).  This is one of the things that makes doing
>good Ada bindings non-trivial.  If someone tries to sell a "binding"
>to Xlib that does not handle tasks, he's not selling a binding.
>Instead, he's selling PRAGMA INTERFACE(C), without doing any of the
>real work.
>

There do exist commercial bindings which are thread safe for the
Verdix Ada compiler in Xlib applications.

>
>The real solution for Ada and X Windows will occur when X Windows is
>multi-threaded in a way that meshes with Ada tasks.

Xlib will never be multi-threaded, however, there is a high
probability that R6 will support multiple threads (unix threads), by
using extending the null locking macros to be a complete
implementation.  This will only make Xlib thread safe, not
multi-threaded in it's own right.  In addition, this doesn't
necessarily mean that it will be *safe* to use with Ada tasks, unless
an Ada task maps directly to a unix thread.

Because of this, you must rely on tasking safe bindings which perform
the locking or use an Ada toolkit, like GRAMMI which directly
addresses and solves the multi-tasking problem.

John Goodsen
goodsenj@ajpo.sei.cmu.edu


Newsgroups: comp.lang.ada
From: sampson@nosc.mil (Charles H. Sampson)
Subject: Re: Using Global Variables
Organization: Computer Sciences Corporation
Date: Tue, 29 Sep 1992 15:05:27 GMT

In article <92269.56792.LJ10891@LMSC5.IS.LMSC.LOCKHEED.COM> LJ10891@LMSC5.IS.LMSC.LOCKHEED.COM writes:
>------------------------- Original Article -------------------------
>>    With the result that anybody who needs to access anything in shared
>>memory now has full access to everything in shared memory.  Ah, informa-
>>tion hiding, what has happened to you?
>                                                          >             Charlie
>
>   True, but the problem domain under discussion seemed centered around
>large memory areas with common access requirements.  For a more discriminating,
>less refined (yes, I do believe that parameter passing is more refined and
>controllable), method one could open the pandora's box of:
>
>package GLOBAL_1 is ...   -- regionals associated with some functionality
>package GLOBAL_2 is ...   -- regionals associated with another functionality
>..  -- etc.
>

     Try the following:

   PACKAGE BODY Hider IS

      Shared_datum : ...
      FOR Shared_datum USE AT A_shared_memory address;

      ...
      
   END Hider;

     It's possible to engineer the layout of shared memory to some degree
when using this approach, but it requires a compiler that has implemented
some modest sort of address arithmetic.  If speed of access to this datum
is a requirement, it can be obtained in most compilers by inlining the
access routines.

>   Synchronization is left as an exercise for the masochist.  :-)

     Synchronization becomes a lot easier because it's all hidden inside
this package.

				Charlie
From: bortz@CNAM.CNAM.FR
Newsgroups: comp.lang.ada
Subject: Any RPC for Ada?
Date: 28 Sep 92 19:09:34 GMT

Hello, Ada friends and lovers,

I'm looking for any information/pointers about implementations of RPC
(Remote Procedure Call) in/for Ada. I'm specially interested in Unix solutions.

I can see two different problems:

- interconnection with existing RPC packages like Sun'S RPC or OSF/NCS
RPC. Is it possible to write an Ada RPC server for C clients or the
opposite? Did anybody make it?

- RPC only for Ada: even in this case, it's probably not trivial
specially considering the differences between Ada's type system and C's
one. The mechanisms used by C to translate data (XDR, NDR, etc) are
probably not directly useful in Ada.

Yes, I know there is something in Ada 9x about that. But it doesn't
address my first point and, from the Ada 9x documents I've read, it's
really inferior to existing RPC: heterogeneous machines are not taking
into account, dynamic binding seems absent, ...

Thanks in advance,
-------------

Stephane Bortzmeyer           Conservatoire National des Arts et Metiers	
bortzmeyer@cnam.cnam.fr       Laboratoire d'Informatique
                              292, rue Saint-Martin			
tel: +33 (1) 40 27 27 31      75141 Paris Cedex 03
fax: +33 (1) 40 27 27 72      France	

"C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand

					
	
Newsgroups: comp.lang.ada
From: emery@Dr_No.mitre.org (David Emery)
Subject: Re: Ada's (in)visibility
Organization: The Mitre Corp., Bedford, MA.
	<1992Sep30.135444.10417@titan.tsd.arlut.utexas.edu>
Date: Wed, 30 Sep 1992 16:31:04 GMT

>To be fair Xlib is not suitable to mulitasking and most large Ada systems use
>tasking.  There is no good solution to this problem yet.  

There is a very good solution to this.  Don't use tasks.  Write
sequential Ada.  This provides EXACTLY the same kind of program you
would get if you wrote the application in C.  Just because Ada has
tasking, there is no obligation to use it in any specific application.
I'm always bothered by people who use lack of support for Ada's
advanced featuers to write a program in C that can be done in
equivalent Ada (without tasking, for instance).

An true Ada binding to Xlib should handle the tasking issue (perhaps
by abstracting a kludge).  This is one of the things that makes doing
good Ada bindings non-trivial.  If someone tries to sell a "binding"
to Xlib that does not handle tasks, he's not selling a binding.
Instead, he's selling PRAGMA INTERFACE(C), without doing any of the
real work.  

The real solution for Ada and X Windows will occur when X Windows is
multi-threaded in a way that meshes with Ada tasks.  

				dave
From: Randy.Baer@f310.n3603.z1.FIDONET.ORG (Randy Baer)
Newsgroups: comp.lang.ada
Subject: open-ada
Date: Sun, 20 Sep 92 20:42:16 EDT
Organization: FidoNet node 1:3603/310 - Tetragrammatton, St Petersburg FL

It arrived Fri.  Wrote my 3rd program for my ada class on it and uploaded
to the schools..it ran perfectly on it.  Thanks for recommending it here
in the nrewgroup. 

--  
Internet: Randy.Baer@f310.n3603.z1.FIDONET.ORG
UUCP: ...!myrddin!tct!psycho!310!Randy.Baer
Note:psycho is a free gateway between Usenet & Fidonet. For info write to
     root@psycho.fidonet.org.
From: dougcc@brt.deakin.edu.au (Douglas Miller)
Newsgroups: comp.lang.ada
Subject: Re: Ada's (in)visibility
Date: 29 Sep 92 20:21:24 GMT
Organization: C&CS, Deakin University

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...