[comp.unix.questions] Problems with S statistical package

jpc@iesd.uucp (Jens P. Christensen) (12/06/87)

Could anyone please shed light on a problem I have in compiling the S
statistical package from AT&T on our Sun-3 system:

System specifics: Sun 3/260 under SunOS 3.4 using the m4 macro
processor supplied with the S system. S version date: Fri Feb 28 1986

Using the hints on compiling with BSD4.2 systems I only get apparently
harmless warnings under the compilation. This could for example be:

Warning on line 84 of hcp.f: local variable i never used
Warning on line 96 of stems.f: statement cannot be reached
f77: Warning: File with unknown suffix (/usr/local/src/s/S/newfun/lib/grz)
     passed to ld
or
"dprint.c", line 20: warning: illegal combination of pointer and integer, op =

Furthermore there are problems with the utility routine scandata.C, which
fails with error: too many local variables. This is fixed by making the
declaration of "table" global. Not pretty, but it works.

These are all the kinds of problems that appear during the
compilation, and it *will* result in an executable, except....
The f...ing system doesn't even know how to add two numbers, as seen in
the following:

One-time initialization for new S user in /usr.MC68020/iesd/tap/jpc ...
Directories swork and sdata created
> 1 + 2
Bad operator: +
Error in +
> 

Running the tests supplied with the system ($A/DOTEST ALL) will not
give better results. This is an excerpt from $TEST/current/apply:

> prefix("apply.")    # test of apply and multivariate stuff, some time-series
> $Random.seed_c(57,0,3,0,0,0,49,16,0,0,0,0)	# to initialize at same spot
> matr_matrix(rnorm(100),20,5)
Invalid distribution: rnorm
Error in rnorm
Dumped
> print(cm_apply(matr,2,"mean")); apply(matr,2,"var")
apply.matr not found
Dumped
 .
 .
and more depressing errors...
Why does the prefix command work, while the matr_matrix(rnorm... stuff don't?

So, have *anybody* made this run on a Sun system, and how did you do it?
All suggestions or pointers to which direction I should go, are welcome.

regards,
-- 
Jens Peter Christensen                               jpc@iesd.uucp
Department of Math. and Computer Science             {...}!mcvax!diku!iesd!jpc
Aalborg University Centre
Denmark

rab@alice.UUCP (12/16/87)

In article <162@iesd.uucp>, jpc@iesd.UUCP writes:
> Could anyone please shed light on a problem I have in compiling the S
> statistical package from AT&T on our Sun-3 system:
> 
> System specifics: Sun 3/260 under SunOS 3.4 using the m4 macro
> processor supplied with the S system. S version date: Fri Feb 28 1986
> 
> > 1 + 2
> Bad operator: +
> Error in +
> 
> So, have *anybody* made this run on a Sun system, and how did you do it?

You have stumbled across a bug in the f77 compiler in Sun's 3.4 release.
Others have gotten around the problem by re-installing f77 from the 3.2
release.  Sun says they will fix the problem soon -- you might want
to check with them.

Here is the bug report that I sent to Sun:
__________________________________________________
On pg 89 of Release 3.4 Manual for the Sun Workstation, Part 800-1614-10,
Revision A of 14 May, 1987, listed under "incorrect handling of Backslash
characters" is the following:

  Previously, f77 did not correctly handle the backslash character (\).
  It converted a double backslash (\\) to a single backslash, requiring
  you to type four backslashes (\\\\) for a double backslash.  The compiler
  converted \0 to the ASCII character 0, which is the string terminator
  for C, rather than FORTRAN.  THis has been fixed in Release 3.4.

Whoever "fixed" this bug should read page 89 of the Fortran Programmer's
Guide, Part 800-1371-02, Revision E of 17 February, 1986.  It states:

  For compatibility with C usage, the following backslash escapes are
  recognized:

and then has Table 6-1 that shows backslash escape sequences including
\\ and \0.  These escapes are extremely important to Fortran programmers
that are communicating with C.  For example, they are the only way
to get null-bytes into character strings that are initialized by
data statements.  Here's a simple example:

      character *100 foo
      data foo/"this is a test string\0"/
      call bar(foo)
      stop
      end

Here is the C function bar:

bar_(s,l)
char *s; long l;
{
	printf("The string is: %s\n",s);
	printf("its actual length is %ld but its declared length is %ld\n",
		strlen(s),l);
}

Here's the result on a Sun OS 3.2 system.

$ f77 foo.f bar.c
foo.f:
foo.f:
 MAIN:
bar.c:
Linking:
$ a.out
The string is: this is a test string
its actual length is 21 but its declared length is 100


Here's the result on a Sun OS 3.4 system.

$ f77 foo.f bar.c
foo.f:
foo.f:
 MAIN:
bar.c:
Linking:
$ a.out
The string is: this is a test string                                                                              The string is: %s

its actual length is 118 but its declared length is 100
-- 

    Rick Becker  alice!rab  research!rab

smiller@umn-cs.cs.umn.edu (Steven M. Miller) (12/16/87)

In article <162@iesd.uucp>, jpc@iesd.uucp (Jens P. Christensen) writes:
> Could anyone please shed light on a problem I have in compiling the S
> statistical package from AT&T on our Sun-3 system:
> 

There is a known problem that you could be running into.  in 

~Ssourcedir/src/main/main.C  you need to add a call to f_init()

I may have the above line slightly incorrect, as I no longer am working
at a site with S and the above is from memory.

Also in Sun 3.2 there was an Optimizer bug that came up, but Sun probably
has it fixed in 3.4.

The guru's at AT&T (rick@alice.uucp) can probably help out too.




-- 



			-Steve Miller, U of MN