karl@grebyn.com (Karl Nyberg) (12/18/88)
In article <206@imspw6.UUCP> bob@imspw6.UUCP (Bob Burch) writes (among other stuff): >The tale concerning Ada/UNIX comes back the same way and sounds the same >no matter which way you turn your ear. There was the article in the Aug. >1 issue of Government Computer News, there are the comments from the Nov. >RICIS symposium ("Ada on UNIX doesn't work"), and, to me at least, aside >from and in addition to my own experiences with UNIX/Ada, it sounds >about the same no matter who I talk to. (1) I guess you haven't read the article in GCN to which you refer. Either that, or you weren't interested enough to check the facts. (2) Or perhaps you haven't talked to enough people. The GCN article (a widely respected professional computer journal, you will note*) mentioned (if I remember correctly) that the requirements for Ada, UNIX, and REAL TIME software FOR A PARTICULAR APPLICATION were such that all the requirements could not be fully met in their current environment. Ada and UNIX were chosen (and used) for the MIS portions of the application as best I can recall. Many of the Ada compiler vendors, some of whose products are even written in Ada and run on UNIX, are developing and marketing their products quite successfully. They wouldn't be doing so if their customers weren't using their products profitably. The list of companies developing commercial applications in Ada, and on UNIX, continues to grow. These include database management systems, editors, and the like. For more information on the widespread use of Ada, call the Ada Information Clearinghouse (703)685-1477 and ask for their Ada in Use Database. For more information on particularly commercial applications, contact Dave Dikel, ddikel@ajpo.sei.cmu.edu, (703)847-6741, Chairman of the SIGAda Commercial Applications Users Group. Or (3) perhaps you're afraid that Ada WILL succeed, and that you are already so far behind the competitive power curve that the only way you can salvage your situation is to try to drag Ada down and hope that it will go away. Well, it won't. As you quote Stroustrup, Ada is here to stay. But enough proseletyzing. If you don't want to hear it, you won't. Ten years ago, you might have been one of those completely uninterested in UNIX, and now you claim the ability to look into the future where it is concerned. Far be it from me to try breaking through the brick wall. I've got Ada code to complete for my VAX/ULTRIX and PC/DOS machines to get my products to market and continue to make money. It's a better way to spend my time... -- Karl -- * As an aside, I have had a number of articles published by GCN (and BYTE, and Ada Letters), so I don't intend this as a slur on the paper. However, PLEASE consider their purpose. It's not like their articles have been reviewed for technical details and indepth understanding. Such publications "sell" by grabbing their readers attention with bold headlines.
rracine@AJPO.SEI.CMU.EDU (12/20/88)
A reference was made to a study of Ada running on top of UNIX, which was written up in GCN. The reference made it seem that the language was the problem. Being one of the participants in the study, I can state that the Operating System was the problem. The context of the study was as follows. The Space Station Freedom Project (that is really its correct name) decided many years ago to use Ada for all new software. The project is also trying to use commercial software when possible. So they had a number of folks (including us) look at the feasibility of having a System V Interface Definition (SVID) conforming operating system be the ON-BOARD operating system for the Space Station Freedom. Without going into too much detail, the results we came up with are: 1) For real-time software, current implementations of SVID do not give the application program (in any language) enough of the processor. There is too much overhead taken in Signaling, for example. 2) There are Ada implementations which are sufficient for the program, either with real-time operating systems under the run-time environment, or with their own run-time environments. 3) Since the Ada applications need the speed, and non-real-time software (comercial systems) need the SVID interface, why not procure a SVID (or POSIX) implementation ON TOP of an Ada run-time environment? NASA (and the on-board computer contractor) are still stating a long term SVID requirment, but I think we at least are making them look a little closer at the implementations. As far as Ada interfacing to UNIX, the additional overhead of converting differing types of data is the only problem one should compare with C++, and that can be negligible. One could look at tasking, but C++ doesn't have tasking. If one really stretches one's imagination, you could call UNIX a multitasking system, but then the comparison is unfair -- Ada is much, much faster in all measurements. Try to do synchronous communication in C++. Current Ada implementations have a one-way communication time on the order of 50 microseconds. The best we could do in C was a couple of orders of magnitude longer (some number of milliseconds). Roger Racine C.S. Draper Laboratory, Inc.
dee@linus.UUCP (David E. Emery) (12/20/88)
A bit more on this... I read the Air Force report, and later spoke to one of the authors. The specific problem that they encountered concerned the following: For a multitasking program running as a single Unix process, Unix does NOT guarantee that I/O invoked by one task does not block the entire process (i.e. all tasks). In fact, in the specific implementation, when one task did I/O, the process (all tasks) did block. It is well known in the Unix community that the basic Unix I/O model calls for blocking. There are some facilities for non-blocking I/O in Unix, but they are mostly dependent on the whims of the device driver writer. Now many people have said, based on reading this report, that Ada and Unix don't mix. They are entitled to their opinions. However, blocking I/O is strictly a Unix limitation, Ada's tasking only makes this limitation obvious to the user. In the specific application cited in the article, I understand that the Unix compiler vendor developed a non-blocking I/O package that would work on the specific hardware used by the Air Force. This solution was not general enough (because of Unix limitations, not Ada limitations) to be turned into a product. Incidently, I've been doing systems programming on Unix using Ada for 4 years now. There are some issues/problems/shortcomings that you have to address, but this is true of any language on any operating system. There are some things that aren't easy to do (try doing multi-taskin in C on Unix, or in C on VMS...) So, now you know "The rest of the story". dave emery emery@mitre.org (new style) emery@mitre-bedford.arpa (old style) linus!dee
jws@hpcljws.HP.COM (John Stafford) (12/21/88)
Ada I/O has a function NAME which
"Returns a string which uniquely identifies the external file
currently associated with the given file (and may thus be used in an
open operation). If an environment allows alternative specifications
of the name (for example, abbreviations), the string returned by the
function should correspond to a full specification of the name."
So the question is, what should NAME do on a UNIX (tm) system?
The first interpretation that comes to mind is that NAME should
return "a" fully rooted path to the given file. The term "a" is used
because with hard links there is no "the" fully rooted path to the
given file. Futher, on systems which support "alternative
specifications" like symbolic links or hidden files or alternative
file system universes, such should be "resolved" and made "explicit"
in the result. Things like references to . and .. (in the file
name given to the Ada I/O system by the user) are "alternative
specifications" as well and should be "resolved" and made "explicit"
in the result as well.
The problems with that interpretation are:
1. The name must be determined when the file is opened/created,
since the user may have specified a relative file name and may change
working directory after opening the file and before using NAME. I
recognize that changing working directory isn't directly supported by
Ada, but NAME should work even if the user does change working
directory since it is to return the "full specification of the name".
2. Even if the user gives a rooted path, the work still needs to be
done to resolve any "alternative specifications".
3. The Ada I/O system ends up basically having to implement /bin/pwd
to walk up the directory tree to compute the fully rooted path. And
if it uses chdir(2) during the walk, it also needs to first determine
the current working directory so that it can "get back there" when it
is done resolving the path to the specified file. This potentially
has severe impact on the performance of all Ada open/create
operations.
4. Lack of read or execute permission anywhere in "a" path to the
file in question (or to the current working directory in the chdir(2)
case) will cause this process to fail. Due to problem 1, it would
seem that the open/create must therefore fail (probably by raising
NAME_ERROR), even though the user may have permission to access the
file and will never need the NAME.
5. The error cannot be deferred to the actual use of NAME because
NAME is not defined as being able to raise any exception except
STATUS_ERROR and it may only do that if the file is not open.
I am interested in alternative interpretations and/or comments on my
interpretation and comments. I am also interested in information as to
what current compilers do if anyone cares to share it. I don't claim to
even know what "Ada should do", but if Ada and UNIX are to get along,
somebody probably will need to take the monkey of defining the behavior
of NAME in a UNIX environment (I am not volunteering, I was referring to
some "official" standards type group, like the Ada/POSIX folks).
--
John Stafford
{biggies}!hplabs!hpda!jwsfirth@sei.cmu.edu (Robert Firth) (12/22/88)
In article <GARY.88Dec15142623@milo.mcs.clarkson.edu> gary@milo.mcs.clarkson.edu (Gary Levin) writes: >In article <8008@aw.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: > ... > The best, in my opinion, is to have the semicolon optional: a newline > will terminate the statement if possible. So you can write > > x := x+1 > y := y+1 > > and it works, but > > x := a0+a1+a2+ > a3+a4+a5 > > also works. One hardly ever gets this wrong. > >However, if you are in an expression oriented language, it is possible >to get really strange effects here. I would write the above statement >as: > > x := a0+a1+a2 > +a3+a4+a5; > >Having submitted this to Icon, I found that the program didn't work as >expected. It took me quite a bit of debugging to find that this was >being treated as two statements, and so x was only assigned a0+a1+a2. >Further, I then tried to write this as > > x := (a0+a1+a2 > +a3+a4+a5); > >and I was informed that I was missing a right parenthesis after a2 >(and before the inserted semicolon). Note that Icon would correctly >handle the case of the trailing + as Firth wrote his example. > >Generally, I prefer systems that have me say what I mean, rather than >guess. And if they must guess, they should have the grace to indicate >their guesses. > >It is certainly possible that Icon no longer suffers from this >particular lexical/syntactic quirk; I haven't used it in quite a while. >-- > >----- >Gary Levin/Dept of Math & CS/Clarkson Univ/Potsdam, NY 13676/(315) 268-2384 >BitNet: gary@clutx Internet: gary@clutx.clarkson.edu Newsgroups: comp.arch,comp.lang.fortran Subject: Re: Quadruple-Precision Floating Point ? Summary: Expires: References: <8561@alice.UUCP> Sender: Reply-To: firth@bd.sei.cmu.edu (Robert Firth) Followup-To: Distribution: Organization: Carnegie-Mellon University, SEI, Pgh, Pa Keywords: REAL*16 hardware? obscure In article <8561@alice.UUCP> wcs@alice.UUCP (Bill Stewart, usually) writes: >Are there any machines that implement quad-precision (128-bit) floating >point numbers in hardware? Are there any commercial Fortran compilers >that support it? Yes to both. The DEC VAX-11 supports what they call 'H' floating point, which is 128 bits wide (16 bit exponent and 112 bit mantissa counting the hidden bit). The DEC Fortran compiler I believe supports all the VAX floating-point formats. Newsgroups: comp.lang.ada Subject: Re: Ada/UNIX(tm) and the NAME function Summary: Expires: References: <920005@hpcljws.HP.COM> Sender: Reply-To: firth@bd.sei.cmu.edu (Robert Firth) Followup-To: Distribution: Organization: Carnegie-Mellon University, SEI, Pgh, Pa Keywords: In article <920005@hpcljws.HP.COM> jws@hpcljws.HP.COM (John Stafford) writes: >Ada I/O has a function NAME which > > "Returns a string which uniquely identifies the external file > currently associated with the given file (and may thus be used in an > open operation). If an environment allows alternative specifications > of the name (for example, abbreviations), the string returned by the > function should correspond to a full specification of the name." > >So the question is, what should NAME do on a UNIX (tm) system? > > The first interpretation that comes to mind is that NAME should > return "a" fully rooted path to the given file. The term "a" is used > because with hard links there is no "the" fully rooted path to the > given file. Futher, on systems which support "alternative > specifications" like symbolic links or hidden files or alternative > file system universes, such should be "resolved" and made "explicit" > in the result. Things like references to . and .. (in the file > name given to the Ada I/O system by the user) are "alternative > specifications" as well and should be "resolved" and made "explicit" > in the result as well. The above seems a reasonable interpretation. Note that the Ada RM does not imply that there is only ONE string that uniquely identifies the file; it reqires only that the string be a "full" specification, ie one that does not depend on any hidden variables in the execution environment of the program (such as the current directory). >The problems with that interpretation are: > > 1. The name must be determined when the file is opened/created, > since the user may have specified a relative file name and may change > working directory after opening the file and before using NAME. I > recognize that changing working directory isn't directly supported by > Ada, but NAME should work even if the user does change working > directory since it is to return the "full specification of the name". I don't see this at all. It is necessary merely to "freeze" (by copy, presumably) any values in the environment on which the interpretation of the file might depend (eg the current working directory). It is not necessary actually to compute the name; that can be done later from the copied information. > 2. Even if the user gives a rooted path, the work still needs to be > done to resolve any "alternative specifications". > 3. The Ada I/O system ends up basically having to implement /bin/pwd > to walk up the directory tree to compute the fully rooted path. And > if it uses chdir(2) during the walk, it also needs to first determine > the current working directory so that it can "get back there" when it > is done resolving the path to the specified file. This potentially > has severe impact on the performance of all Ada open/create > operations. Surely the right answer is not to replicate this functionality in "Ada" (presumably the package body INPUT_OUTPUT is intended), but rather to add to your Unix system a routine that, when called with a "partial" file name and an environment, will return some appropriate "full" name. I fail to see why this process should be inefficient (though of course on Unix the most surprising things ARE inefficient). > 4. Lack of read or execute permission anywhere in "a" path to the > file in question (or to the current working directory in the chdir(2) > case) will cause this process to fail. Due to problem 1, it would > seem that the open/create must therefore fail (probably by raising > NAME_ERROR), even though the user may have permission to access the > file and will never need the NAME. An implementation that fails in this way is clearly erroneous. The appropriate course of action would be to look at alternatives. > 5. The error cannot be deferred to the actual use of NAME because > NAME is not defined as being able to raise any exception except > STATUS_ERROR and it may only do that if the file is not open. No: the fact that it is required to raise an exception does not imply (here or elsewhere) that it is forbidden to raise any otehr exception. Hope that helps a little. [idiot fodder - ignore] programs should do what they are told not what some bloody moron thinks would be a good idea and imposes on everyone else
emery@ARIES.MITRE.ORG (David Emery) (12/29/88)
This is not a significant problem on Unix. First, you should get an absolute pathname to the file. This should be interpreted according to Unix semantics. My understanding of this is that, for a relative pathname, the effect is as if current value of the process' working directory is prepended to the relative pathname, converting it to an absolute pathname. This is then used to get the file. (note that there are plenty of optimizations here, particularly those that "cache" the path traversal to get to the working directory). There is no requirement for Ada to determine the "best" path to a file, only the absolute pathname used to open the file. So, the Ada implementation of Text_IO.OPEN (or whatever) does the same thing. If the pathname isn't absolute, call Unix.getcwd, append the pathname to this string, and associate it with the FILE_TYPE object. (More specifically, store it inside the private FILE_TYPE object.) Note that there is NO requirement to walk the directory chain. If Unix can open the file, then this is a good filename; if Unix cannot open the file, then of course there is no reasonable name associated with the FILE_TYPE object. (So call Unix.open before 'calculating' the file name.) TEXT_IO.NAME then looks like return FILE.FILE_NAME; and NAME_ERROR is raised if file_type.file_name has no 'legal' value. Of course, you have the potential problem of losing access to the file during the execution of the process. (For instance, someone clobbers /usr). This will always be true with Unix, so Ada shouldn't attempt to fix Unix. Naturally, Robert Firth's comment about exceptions is right on the money. One of the things on our "agenda" for the Ada Binding to POSIX is to provide a reasonable POSIX "binding" interpretation of Ada's TEXT_IO in a POSIX environment (things like the meaning of FORM string, etc.) We will discuss this issue at our next meeting but I would be very surprised we came up with any other interpretation. We will have to think a bit about what is returned by TEXT_IO.NAME(TEXT_IO.STANDARD_INPUT). Furthermore, I suspect that we will in general try to better define and possibly restrict the exceptions that a conforming POSIX implementation can raise for TEXT_IO operations (e.g. restrict TEXT_IO.NAME to raising STATUS_ERROR, and then only when the given file hasn't been opened.) dave emery (Technical Co-Editor, IEEE POSIX Ada Binding) mitre emery@mitre.org (new style) emery@mitre-bedford.arpa (old style) "Advertisment": for more information on the POSIX Ada binding, contact me. To get on the Email list discussing the binding, send mail to posix-ada-request@grebyn.com
barmar@think.COM (Barry Margolin) (12/31/88)
In article <8812281638.AA00722@aries> emery@mitre.org writes: >... If the pathname isn't absolute, call Unix.getcwd, ... >Note that there is NO requirement to walk the directory chain. How do you think Unix.getcwd works? Most Unix implementations don't remember the character string used to set the working directory. Getcwd() walks the directory tree. Does the specification of the NAME function say how it should interact with asynchronous renamings? Must it always return the current name, or can it just return the name used to open the file? This goes beyond Unix, since most OSes allow files that are open to be renamed. However, if the current name must always be returned, it would be difficult for Unix to support this. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
dik@cwi.nl (Dik T. Winter) (12/31/88)
In article <34974@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: > In article <8812281638.AA00722@aries> emery@mitre.org writes: > >... If the pathname isn't absolute, call Unix.getcwd, ... > >Note that there is NO requirement to walk the directory chain. > > How do you think Unix.getcwd works? Most Unix implementations don't > remember the character string used to set the working directory. > Getcwd() walks the directory tree. > And note also that getwd (in C terms, getcwd is Fortran I believe) may fail. It will do so if the parent directory of one of the directories has execute permission only, no read permission. In that case a file may be opened, but it is not possible to get an absolute path name. -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
sommar@enea.se (Erland Sommarskog) (01/01/89)
Dik T. Winter (dik@cwi.nl) writes: >And note also that getwd (in C terms, getcwd is Fortran I believe) may fail. >It will do so if the parent directory of one of the directories has >execute permission only, no read permission. In that case a file may >be opened, but it is not possible to get an absolute path name. I guess this is what happens when you type "pwd" and get something like "...can't open". This is the occassion when you as VMS-raised person get very confused and wonder where you are. Such things just doesn't happen on that system... -- Erland Sommarskog ENEA Data, Stockholm This signature is not to be quoted. sommar@enea.se
leake@cme.nbs.gov (Stephe Leake) (01/03/89)
In article <8069@aw.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
No: the fact that it is required to raise an exception does not imply
(here or elsewhere) that it is forbidden to raise any otehr exception.
This sounds dangerous to me; I have always assumed that the
pre-defined packages behaved _precisely_ as specified in the LRM,
_including_ which exceptions may be raised. Thus, if the LRM does not
state that a particular routine may raise an exception, it should not
do so. This is critical in writting exception handlers; we have to
know which exceptions a routine may raise in order to handle them all.
Stephe Leake (301) 975-3431 leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD 20899jws@hpcljws.HP.COM (John Stafford) (01/04/89)
Relative names:
My interpretation of NAME is that simply attaching the output of
getcwd to a relative name does not meet the specification that "If an
environment allows alternative specification of the name ... , the
string returned by the function should correspond to the full
specification of the name". As noted, on systems with "symbolic
links" and "hidden directories" and the like, it really feels like
such should be "removed" in order to return "the full specification".
Perhaps I am over-reading the RM, I had thought that the spirit of an
RM specification was to be as precise as possible. It is at least
clear that precision is currently not present when using NAME on
UNIX.
I can't imagine any sane program comparing the NAMEs of files,
although certainly an Ada product should document what its version of
NAME does lest somebody think they can reliably do such a thing.
I would like to see NAME return the same thing for a given file no
matter what path I used to open the file (except if such is not
possible, as in the case of hard links). But I suspect I am asking
for more than what is required.
If I open
foo
./foo
./././././././foo
is it reasonable that the result returned by NAME should be different
in each case?
Other issues:
I still don't know what one should do if the file can be opened but
the name cannot be determined (e.g. due to lack of parent directory
access permission).
I also am not "Ada knowledgeable" enough to know that it is OK for
routines which the RM defines as able to raise some exceptions to
raise others as well. I would genuinely appreciate references to why
this is OK (at first glance it would seem to me to make an
implementation of Ada non-conformant if use of NAME could raise
NAME_ERROR).bgolden@infmx.UUCP (Bernard Golden) (09/28/89)
We have gotten a question from one of our customers regarding ada. They
are fairly experienced with ada on the alsys compiler, but this will be
their first experience with the telesoft compiler on UNIX. (And I should
point out that I'm completely unacquainted with ada).
Anyway, their question has to do with using the multiple capabilities (threads,
or somesuch) of ada on UNIX. They're afraid they'll have to sacrifice
some of the capabilities of ada to run on UNIX.
Is there a good reference book to describe how this facility might work on
UNIX, or even better, is there someone from telesoft who follows this
newsgroup that might be willing to spend a few minutes talking to me on
this topic?
Please email me, since I probably won't be able to scan this group thoroughly.
Thanks very much.
Bernard Golden
{pyramid,uunet}!infmx!bgolden
415-926-6416keith@telesoft.UUCP (Keith Shillington @lizard) (09/30/89)
> ... their question has to do with using the multiple capabilities (threads, > or somesuch) of ada on UNIX. They're afraid they'll have to sacrifice > some of the capabilities of ada to run on UNIX. > Is there a good reference book to describe how this facility might work on > UNIX, or even better, is there someone from telesoft who follows this > newsgroup that might be willing to spend a few minutes talking to me on > this topic? > Bernard Golden {pyramid,uunet}!infmx!bgolden 415-926-6416 Bernard: I left a message on your voice mail. Ada (regardless of OS) has full multitasking capabilities. I would love to talk to you about them. I can also recommend several texts: (in order of my preference) "System Design with Ada", R.J.A. Buhr, Prentice-Hall "Understanding Concurrency with Ada", Ken Shumate, McGraw-Hill "Concurrent programming in Ada", Alan Burns, Cambridge University Press Keith Allan Shillington telesoft!keith@UCSD.ARPA 619/457-2700x388.ATT TeleSoft Customer Support ucsd!keith@telesoft.com
bgolden@infmx.UUCP (Bernard Golden) (09/30/89)
In article <2437@infmx.UUCP> bgolden@infmx.UUCP (Bernard Golden) writes: >We have gotten a question from one of our customers regarding ada. Keith Shillington (I think that's the right last name) from Telesoft called me and we had a very good discussion regarding ADA and its capabilities on UNIX. It appears that no capabilities of ADA are sacrificed by running on UNIX, although UNIX itself provides some facilities (e.g., message queues) that might make some language features not so important. It also appears that the 'task' facility could work with our product, IF the programmer was careful. So, I got my question answered. I really appreciate Keith's efforts. In addition, I got calls from a couple of other people, but didn't have a chance to talk to them. Thanks to everyone. -b