Re: [S] Splus 5.0

Ed Kademan (kademan@phz.com)
02 Nov 1998 17:49:19 -0500


"Richard T. Whitney" <pp000171@mindspring.com> writes:

> A question for the accumulated knowledge and experience of this list!
>
> My group uses Splus 3.4 under Solaris, and we just received
> the Splus 5.0 upgrade from Mathsoft. I've read the release notes
> and understand the issues with the transition as documented.
>
> The question -- for those who have upgraded, are there any unexpected=20
> side effects?
>

I too would be interested in hearing about other people's experiences
in porting their applications from Splus3.4 to Splus5 under Solaris.
While our site hasn't officially "upgraded," I have been trying to get
our functions running under version 5 release 2 for a couple of weeks
now and so far have run in to a host of problems. As much as I like
some of the ideas in the new S I can't help feeling that this release
was premature and the testing half-baked, and while it's possible that
I've already found all or most of the bugs I really doubt it. In
short, there appear to be many more incompatibilities than the
documentation from Mathsoft implies.

I will try to summarize the glitches:

* The installation guide claims that it's possible to simultaneously
run Splus3.4 and Splus5 sessions under the same license server. This
is true, but the explanation of how to make this work is incomplete.
You have to shut down the Splus3.4 license server, copy the file
$SHOME34/adm/lic/keys/00.lic
to
$SHOME5/adm/lic/keys/00.lic
and then start the Splus5 version of the license server.

* When I tried to get Splus5 to open a graphics window---by typing
"motif()" at the command line---it complained about not finding
certain shared libraries and refused. I had to ftp in to the Mathsoft
site and download libsunmath.so.1 and libF77.so.3 and put them into
the $SHOME5/newfun/lib directory. (Mathsoft promised that future
distributions would include these libraries.)

* Our applications use object code that we currently dyn.load in with
the S executive. Splus5 has a new way of building and organizing
linkable modules from such code. But the makefile that gets generated
when you follow the instructions invokes shell scripts that presuppose
the existence of libraries that we---for one---don't have. Those
shell scripts are very simple and it's not really that hard to
hand-edit the makefile to get it to work. But it's irritating to have
to tinker with a procedure that looks as though it was designed to
work for only one particular installation.

* The "convertOldLibrary" function converts the Splus3.4 objects in a
directory to new Splus5 objects. When I tried to run it it bombed out
if the old directory contained a numeric vector with NA's in it.
According to Mathsoft this bug will be fixed in Splus5 release 3 due
out in a couple of months. In the meantime they told me that the
following redefinition would fix things (I haven't tried it yet).

"all.names" <-
function(expr, functions = T, max.names = 200., unique = T)
.Internal(all.names(expr), "s_c_names", T, if(functions) 0 else 1)

* If you add a numeric vector (of length greater than 1) to a date
object Splus complains about expressions being nested beyond limit.
Mathsoft has promised to fix this bug in the next release.

* I had been using the function

sync <- function() {synchronize(1:length(search()))}

to automatically synchronize all my databases. This function no
longer works. Apparently certain components of the search
list---those that are "standard" and write-only---will not allow
themselves to be synchronized. (This makes sense and is easy to
accommodate, but it was unexpected and---as far as I can
tell---undocumented.)

* Under some circumstances logical objects do not seem to behave
correctly. For example the following function generates an error when
I run it:

l.prob <- function() {
logical <- T
while(logical) {logical <- any(is.na(1:5))}
}

Well that's what I have found so far. As you can see some of the
problems are pretty trivial and easy to work around. But even the
simplest hang up can completely stop an important application. And
some of the bugs are surprisingly obvious for a second release---not
being able to run motif() for example. The technical support staff at
Mathsoft has been responsive and helpful for the most part but it
seems to me they shouldn't have to deal with problems like this in the
first place. I hope I'm wrong but the impression I'm getting is that
there are a million little things in Splus5 waiting to trip us up.

One other thing that I would be interested in hearing about is how
other people are dealing with the actual job of converting their
function definitions to Splus5. At our site we have a very sizable
body of "source code." That is, we do not simply rely on the internal
representations of S functions as stored in the .Data directories, but
we keep those function definitions in external files under a revision
control system. When we change a function we check out the
appropriate file, edit it, source it into Splus, and then check the
file back in. It would be very neat if there were a tool like
convertOldLibrary that would work on these files rather than on the
corresponding Splus objects themselves. (I'd really be surprised if
there were such a tool. Based on what I've discovered so far it looks
as though nobody knows what you have to do in general to make an
Splus3.4 function compatible with Splus5 much less do it
automatically.)

-- 
Ed Kademan              508.651.3700
PHZ Capital Partners    508.653.1745 (fax)
321 Commonwealth Road   <kademan@phz.com>
Wayland, MA 01778
-----------------------------------------------------------------------
This message was distributed by s-news@wubios.wustl.edu.  To unsubscribe
send e-mail to s-news-request@wubios.wustl.edu with the BODY of the
message:  unsubscribe s-news