🚀 go-pugleaf

This message sent to the info-gnu-fortran mailing list is of wider
interest to the GNU community.

If you wish to get announcements about the progress of GNU Fortran ask
	info-gnu-fortran-request@prep.ai.mit.edu
to join the list.

enjoy -len


Date: Mon, 17 Aug 92 16:15:08 -0400
From: burley@gnu.ai.mit.edu (Craig Burley)
To: info-gnu-fortran@prep.ai.mit.edu
Subject: GNU Fortran Alpha Test Planned; Testers Needed

It's time to start alpha-testing GNU Fortran!  I need about five
highly motivated experts in Fortran, GNU compiler internals, and UNIX,
who also have reliable net access (must be able to ftp from FSF
machines) and are willing to commit significant time (perhaps 6-10
hours per week) to alpha-testing GNU Fortran.  Since GNU Fortran is
not yet free software (and won't be until it goes into beta), these
individuals must be willing to treat the GNU Fortran code as my
unpublished, personal property and therefore as something they won't
release to others or permit others to access.

The primary focus of the alpha test is to test the front end.  (If you don't
know what this means, you're probably not qualified to be an alpha tester!)
Some crucial parts of the front end currently are implemented so that they
run slowly but perform special self-checking and abort (via assert errors,
typically) when they detect internal problems.  Alpha testers must do a good
job putting the compiler through its paces, including submitting errant
programs (ones with syntactic, semantic, and other kinds of errors) and
making sure they are handled reasonably by the front end.  Once this phase is
accomplished, some of this checking will be removed for the sake of speed
(although I hope to leave it in the source, for later regression testing).

The secondary focus of the alpha test is to test the integration between
the front end and the back end.  Much of the front end knows nothing about
the GNU back end or any other back end.  Currently, there is little or no
debugger support and the run-time library design is essentially the same as
AT&T's f2c program, so there probably will be fairly extensive changes
needed to support Fortran properly on a variety of different systems.  As a
result, I'm not as concerned whether certain I/O constructs or intrinsics work
on every system as I am whether the front end parsing and analysis works
well, since the former is likely to be changed anyway.  On the other hand,
outright bugs that prevent proper execution of compiled code should be fixed
during this phase.

The tertiary focus is the quality of code generated by the GNU back end.
Because of the volume of bug reports and changes I expect to be generated
for the Fortran-specific portions of the compiler, I'd rather keep other
changes to a minimum.  Also, we (the Fortran alpha testers and author) cannot
easily integrate back-end changes as we can with the (unpublished) Fortran-
specific code.

One of the difficulties of releasing GNU Fortran to alpha right now is that
COMPLEX stuff probably doesn't work in the GNU back end just yet, so it
can't be fully tested in the front end.  (It is possible the back end has
recently been enhanced in this direction -- I haven't checked into this.)
There are a few other things I wanted to do before alpha test.

I might be able to get to one or more of these things before I actually
release the compiler, but the alpha testers must be prepared to deal
effectively with what must be assumed (until proven otherwise) to be a broken
compiler.  I haven't done any significant testing (aside from the statement-
by-statement testing typical when implementing language features), so I have
no idea whether it'll run just fine or crash in flames when given various
programs to compile.

Note that I am hoping to take a contract programming position soon.
However, doing so will prevent me working on GNU Fortran full-time for 3-6
months, and I think it is better to get a few people alpha-testing the
compiler as it stands than to delay testing while I try to get it into
better shape.

Since I won't be available to centralize bug reports and patches rapidly
while contracting, I'd like one of the five or so testers to volunteer as
"auxiliary author" during my period of limited availability.  That individual
will have to be good at collecting bug reports, checking them out when
possible, writing (or rewriting) clear descriptions of bugs and proposed
enhancements, maintaining a central copy of the "one true GNU Fortran" so the
other alpha testers can obtain each others' patches easily, and so on.  I
will make myself available, as necessary, to answer questions and offer
guidance to this assistant, who will probably do all the "real work" for a
while and, hopefully, be at least as good at this sort of thing as I would if
I could take the time.  (In fact, if everyone turned out to be better at this
than I, then I'd be happy to take a long vacation after my contract! :-)

I hope that when I finish the contract, GNU Fortran will be in much
better shape and ready for me to put the finishing touches on it and
do a beta release, or at least a much wider alpha release.

If you'd like to be an alpha tester, first _carefully read and answer_ the
questions in this list.  Then, if you can honestly answer YES to all of them,
send me e-mail at burley@gnu.ai.mit.edu.  I'm not sure how I'll choose between
the applicants, but I'm hoping the following questions will whittle the number
of applicants down to a value ranging between 3 and 10.  (FYI, you don't have
to send me the answers, and please don't send me challenges regarding the
questions unless you really want to annoy me.  This test is done on the
"honor system".)

1.   Is your system UNIX-based?  (Alpha testing for other OSes such as
     VAX/VMS is likely to be done separately, if at all.)

2.   Can you obtain a full release of GNU C (such as version 2.2.2) via
     ftp, build it (all three stages) on your system, and do a quick check
     to make sure it works, in 8 hours or less?

3.   After doing the procedure outlined in Question 1, would you have at
     least 20MB of disk space available on your system?

4.   Can you obtain the latest version of f2c from research.att.com, build
     it, and test it with some Fortran programs in 4 hours or less?

5.   If told to obtain GNU Fortran this way: "ftp to fubar.gnu.ai.mit.edu,
     login as fortran-luser, password XXX, get file F920728.tar.Z and extract
     the sources as usual", would you understand _exactly_ what that means?

6.   If you had GNU Fortran sources on your system, would you avoid letting
     others copy them?  (They will be free once alpha test is completed.)

7.   If you read the GNU Fortran sources and they violated every rule you
     believed in regarding coding design, implementation, indentation style,
     variable-name choice, and so on, would you nevertheless communicate with
     its author in a calm, reasoned fashion not involving expletives?

8.   If you ran the compiler on your favorite suite of Fortran programs to see
     if they'd compile and run, and instead the compiler somehow deleted
     every file on your system, would you remain calm, report the bug to the
     other alpha testers, and maybe even try and find the bug yourself?

9.   Do you have a copy of the ANSI FORTRAN 77 standard?  Do you understand it
     perfectly or at least know that you don't understand it perfectly?

10.  Given the following Fortran program:

      PROGRAM WHINE
      COMMON /X/ I
      CALL SUB1(I)
      PRINT *,I
      END

      SUBROUTINE SUB1(J)
      J=5
      CALL SUB2
      END

      SUBROUTINE SUB2
      COMMON /X/ K
      K=6
      END

     If you tested this program on 20 compilers other than GNU Fortran
     (including f2c) and they all produced programs that printed the value
     6, but GNU Fortran produced one that printed the value 942 or that
     crashed, would you understand why this is not a bug?  (If you need to
     reference the standard, you may do so before answering the question! :-)

11.  Given the following program:

      PROGRAM MOAN
      DOUBLE PRECISION PI
      DATA PI/3.1415926535989325/
      PRINT *,PI
      END

     If the 20 other compilers' output printed 3.1415926535989325 but GNU
     Fortran's output printed 3.14157432311023, would you understand why this
     is not a bug?  (Note: I don't think I have the correct value of PI here,
     at least not past the first 11 digits, but you get the idea.)

12.  Given that GNU Fortran might well behave differently than people expect
     but that is permitted by the standard, and that by answering YES to the
     above two questions you implicitly allow that such differences are not
     bugs per se, would you still be willing to keep track of such differences
     and report them to the author/assistant-author so they can be addressed
     via documentation and/or modifications to the compiler?

13.  Will you sign an assignment giving any changes you make to the compiler
     to the owner of the copyright of the compiler and get your employer, if
     any, to disclaim ownership of any such changes?

14.  Will you indicate whether you want to be given credit as an alpha tester
     in the credits for the compiler and accept such credit, if you choose to
     receive it, as sufficient reward for your efforts?

15.  Do you _still_ want to be an alpha tester?  :-)

16.  What is your favorite rock band of all time?

(Ok, you don't really have to get #16 right.  :-)
---

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)