Re: 8.0.1 complaints on SLUG

[TYSON@Warbucks.AI.SRI.COM (Mabry Tyson)]

    Date: Mon, 27 Aug 90 13:31 EDT
    From: Moon@STONY-BROOK.SCRC.Symbolics.COM (David A. Moon)

	Date: Sun, 26 Aug 90 11:31 EDT
	From: Qobi@zermatt.lcs.mit.edu (Jeffrey Mark Siskind)

	... 

	Now, I would send these bug to Customer Reports except that I can't repeat
	them predictably. I can't isolate them down to a small example. The same exact
	file will cause the problems one time and then not another. I can't determine
	the circumstances which cause the anomalous behavior to report them. Its just
	that code which has been rock solid for at least eight or ten years is now
	flakey.

    Things like this can't be fixed unless you or someone else provides a
    reproducible test case, or unless your description is recognized as an
    already known bug.  Otherwise there is simply no place to start
    investigations.

    I guess sending to SLUG is a useful way to find out if anyone else is experiencing
    the same thing, but I'm also a little concerned that it makes Genera look bad when
    people send mail to SLUG complaining that it's flakey or broken when there is no
    proof that Genera is at fault.

	...

(Does that mean I can't say how frustrating it is to use Unix(TM) unless I
first prove Unix is at fault??  :-)

I guess I have several things to say about this conversation:

Personally, I don't have a problem with someone saying (on the SLUG
mailing list) something doesn't work right for them on the Symbolics.  I
would prefer if they try to convince themselves that it isn't something
wrong they are doing and maybe spend some time trying to track down the
cause of the problem.  (Qobi passes both those tests apparently.)  It is
certainly better to air the questions here rather than to people who
don't know the Symbolics.

It would be best if they could pinpoint the exact cause of the problem
or show how to replicate it (which is necessary for Customer-reports as
Qobi recognized).  This would constitute proof.  [I don't have much
faith that Customer-Reports will be of much help unless you can show
them how to duplicate the problem.  A couple of months ago, I ran into a
problem that I couldn't duplicate but I found the system code that would
cause the downward recursive loop that I ran into.  The response to my
bug report made me realize nothing would be done unless I could cause
the buggy code to be triggered in the right conditions.  I finally
caused it again 3 weeks ago and reported the bug again.]

However, to collect proof is often a several hour job.  Do you reboot
your system just to make sure it wasn't a corrupted world?  Did you
bring in another copy of your world just to make sure it wasn't
corrupted?  Did you look through the sources to try to find the problem?
Did you make the program that triggers it small enough to be
reproducible at SCRC without having your whole environment?  [3 out of 4
times when I was trying to build an 8.0 world on the MacIvory (from
Genera-8-0 to our site configured world with all our software loaded),
the GC in Optimize World ran for at least 36 hours before I killed it.
The other time it only ran for 20 minutes (as it does on the several
times I've run it on 3600s).  How much proof do I need to collect for
that sort of problem?  By the way, I eventually gave up and changed the
world building script not to do an Optimize World on an Ivory.]

Then, once evidence is collected, you send it off to Customer Reports and
usually get a reply back.  It gets rather frustrating if the reply is
"This was already fixed in the development system.  It will be fixed in an
upcoming ECO."  All that effort was wasted because the problem was known
but you didn't know about it.  


As for the "bug" in the system not noticing all the modified defns
you've made in a buffer...  I gave up on M-Sh-C many years ago because I
couldn't trust it.  Sometimes I have to use it but I never trust it.
Ditto with Add Patch Changed Definitions...   It is a good idea but the
sectionization paradigm isn't quite strong enough to support it
properly.

As for the problem with the lispm going away for a while at random
times, I have noticed such a problem in 8.0.  The clock stops ticking and
I just wait for maybe a minute or two (usually just a few seconds).
What is it?  Well, I have my guesses but it hasn't been so debilitating
that I've felt like spending the hour or so that it would take to track
it down.  Even then, I bet Symbolics already knows about it and it might
even be fixed in 8.0.1.


Just so there are no misunderstandings, I like the Symbolics.  The XL1200 is
surely the best thing since the refrigerator (:-).  The complexity and the
friendliness of the system code is truly remarkable.  Symbolics, Inc. is doing
the best it can with what it has.  Customer Support personnel are not the
developers (last I looked any way) and can only do so much.  And of course,
the developers, with David Moon being the foremost example, are responsible
for the code we run and the environment (software and otherwise) in which
the users operate.  I hope they can keep it going for many years to come.