Where is the Ada software repository?

Where is the Ada software repository?

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!cs.utexa]

How I get into an Ada software repository?
If Ada is all about using pre-written s/w, then let me at it!

Re: Where is the Ada software repository?

[Michael Feldman]

In article <1993Jun9.141849.1008@batman.bmd.trw.com> nickgill@batman.bmd.trw.co
m writes:
>How I get into an Ada software repository?
>If Ada is all about using pre-written s/w, then let me at it!

Right now the best way to get into it is through wuarchive.wustl.edu.
Do an anonymous ftp to that machine, which will take 250 concurrent logins.
Move to languages/ada and look around.

As Rick Conn posted yesterday, the original Simtel20 machine where ASR 
resided is going away, but wuarchive is a MUCH bigger and better host,
and supported much better.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  co-chair, SIGAda Education Committee
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5253 (voice) - 202-994-5296 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------

Re: Where is the Ada software repository?

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!wupost!w]

nickgill@batman.bmd.trw.com writes:

>How I get into an Ada software repository?
>If Ada is all about using pre-written s/w, then let me at it!
A FAQ on the ASR was posted to this newsgroup a week or two ago.  A new
FAQ is inpreparation and will be posted in 2-3 weeks.

-- 
====================================================================
Richard Conn, ASR and PAL Manager  |  conn@wuarchive.wustl.edu

Re: Where is the Ada software repository?

[David Helken]

A word about s/w from repositories... (My opinions based upon experience in
locating, getting and using such s/w.)

1) Be ready to try many names for s/w or s/w topic. That is, editors may be a
good topic, but be ready to try line-oriented-editors, word processors, etc.
You may have to really stretch your mind and break your standard paradeign to
get a string that will snag a match when searching.

2) Be ready to look in more than place. S/W you need may not be in the
repository to which you have access, so be flexible and try other sites.

3) If you're expecting the code to work, think again. Usually some work will be
needed to get the code to compile on your platform. You will almost certainly
*not* be told on what platforms the code is supposed to compile. For example,
many programs I got, (Mc Cabe, a requirements tracer, and others) require
package Starlet, a DEC VMS interface package. I have no substitute for the pc
under DOS, so ... (where can I get the POSIX 1003.5?). The abstracts made no
mention of the dependency on VAX VMS, so it was get and look.

4) Do not expect your s/w so obtained to necessarily complete. I have gotten
s/w that had missing components or missing bodies.

5) Expect most of the sources to be in "early Ada". I mean Ada that was written
within five years of Ada83's adoption. This code is usually tightly coupled and
contaminated with code and objects that would probably be partitioned into
their own components nowadays. This is *no* indictment against anyone,
*everyone* must go through a learning curve. It just means that much of this
early Ada code will have stacks embedded in a string handling package, the
definition and code for handling, binary trees embedded in the same package as
a text line reading routine; or, Ada scanners embedded in ... I think you get
the idea.

6) Many s/w components come packed in some way (zip, tar, etc.). Be prepared to
unpack the stuff. If you do not have the software to do it, check with the
repository managers. You may be able to get the correct (complementry) unpacker
to the one used to pack the code. *BEWARE!* In many cases, code is developed on
a system that  uses very different file naming conventions. The biggest
nightmare is unpacking source files from UNIX to MS-DOS. Often the file names
are much longer than the maximum of 8 allowed under DOS. Many times only a
trailing '_' is used to distinguish the Ada spec from its body contained in the
file without the '_'. Of course if you're unpacking on a DOS machine and the
files are named for a UNIX or VAX, then you *will* loose the specs or the
bodies depeding upon which was unpacked first. The one to be unpacked later
that has the same first 8 characters is the one you will wind up with.

7) Expect little (being kind here) documentation. I've found that most of the
time, source code comes with some comentary in the file, but usually there is
nothing on what parameters to subprograms do, what do some of the subprograms
themselves do, what is assummed etc. Take a look at the Ada style guidelines
for much of what is missing. The guidelines were written after the early Ada
you'll find, so I think of the source code as hacked together. *PLEASE* no
flames on 'hacked', I mean many people, myself included, who started using Ada
and who were developing into engineers desiring to write Ada according to sound
software engineering principles (being articulated about the same time frame)
will find a documentation style quite foreign and limited.

8) Expect package specs and body to be in the same file.

In sum, the software I've gotten was *not* that easy to port, examine for
documentation, compile etc. I did save some time and, on the whole I've found
the exercise kind of cheaper, but you will earn your Ada wings using code from
a repository. It takes time and money to find what you need, some hoops to jump
through to get it (including special accounts, "correct" contracts or programs
that you must be connected with, etc.), sometimes special experteese to get the
code ready for compilation, and special knowledge/experience to make the port
work. One *cannot* expect to get source code from an Ada repository, compile it
while at lunch and expect all to be well upon return from lunch. No way,
Jose...

                           David Helkenn
e-mail: helkenn@dale.cts.com