8.0.1 complaints on SLUG

[Qobi@ZERMATT.LCS.MIT.EDU (Jeffrey Mark Siskind)]

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

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

        With all the recent talk about m-sh-C, has anybody noticed that it is
        *BROKEN* in Genera 8.0.1! Now, it is not totally broken, it is just unreliable.
        The algorithm seems to have changed and that change has introduced bugs.

    There are no patches after 8.0 and before 8.0.1 that look like they could have
    affected this.

Actually, I was comparing 8.0.1 to 7.2, not 8.0. At MIT we skipped over 8.0 and
went straight to 8.0.1.

    I suspect these bugs either are not new, or are not system bugs
    but were caused by something you or someone else at your site did.  Another
    thing to look for when you install new software and things stop working is
    whether your copy of the software is bad, either because there was an undetected
    tape error or the software somehow got clobbered while you were installing it.
    It completely baffles me that Symbolics is unable to provide a simple checksum
    on world loads that could be used to verify installation.  Lacking that, you
    should get a known good world tape and compare against the world on your disk.

        Sometimes, it compiles code it shouldn't. Thats alright, just annoying. But
        worse, sometimes it doesn't compile code that it should. About one out of every
        10 times I've used it since I've switched to 8.0.1 it fails to compile some
        function that it should. Often, I've wasted a lot of time, trying to figure out
        why a bug I just fixed still reappears in code only to find out the out of the
        dozens of functions I've just editted and did a m-sh-C on, one didn't get
        recompiled and that was the cause of the bug not being fixed.

    I think there has been a bug like this since forever.  It may happen when you
    create a new definition or kill and yank entire definitions and something gets
    confused about where the boundaries between definitions are.  I've never heard
    of it happening anything like this often though (or it would have been fixed
    long ago).

        Also, if you have unbalanced parenthesis in a function that you just edited
        and do a m-sh-C, it used to complain which was good. Now it doesn't anymore.
        It just reads up to the matching closing parenthesis and ignores the rest of the
        definition that has changed. This is a bug.

    It doesn't do that when I try it.  It reads all of what used to be the definition
    of the function, stopping before the next open parenthesis in the first column,
    thus picking up two forms to be compiled (the second one was malformed and caused
    an error, as you'd expect).  I don't think anything has been changed here in years.

        There is even some more random flakiness in Genera 8.0.1. Sometimes Zmacs gets
        wedged in such a way that typing self-inserting characters takes many SECONDS
        for it to process. This seems to happen when you edit a function and are in
        a temporary state where parenthesis are unbalanced. It can take Zmacs several
        MINUTES to echo a few dozen characters that I type. No paging, No GC, no other
        processes, the run light is solidly off before I type the characters, goes
        solidly on for a few mintues while it processes the typed input and then goes
        solidly off again.

    This doesn't happen to anyone else, as far as I know.  To find out what is
    happening while the machine is not responding, use c-m-Suspend.  If that doesn't
    respond, use h-c-Function and the FEP's Debug command.  Either way, you can get
    a backtrace.  The FEP debugger works about a million times better on Ivory
    machines than on 3600s, I hope you're using an Ivory-based machine as that will
    make your life easier.

Thanks for the suggestion. I hadn't thought of it when the situation occurred. As
I mentioned, this behvavior is difficult to repeat so I will not try. But I will
keep you suggestion in my bag of trick to try next time it comes up.

        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.

        Also, for years, my lispm-init file has had the following lines:

        (setf zwei:*lisp-defun-indentation* '(2 0))
        (setf zwei:*lisp-indent-lone-function-offset* 0)

        I have long since forgotten in detail what they do but I know that they used
        to specify that code was indented as:

        (defun foo (x y)
         (+ x y))

        instead of:

        (defun foo (x y)
          (+ x y))

        (One space indentation under defun rather than two.)

        This too has broken in Genera 8.0.1 and I can't find any documentation in the
        release notes warning me about that. Can any body tell me how to fix this?

    This was not changed from 8.0 to 8.0.1.

Ditto above. I am pretty sure that this (or something similar) has changed between
7.2 and 8.0.1 since the indenting behavior of c-m-Q has definitely changed.

    zwei:*lisp-defun-indentation* is for things that start with DEF and don't have
    declared indentation (determined in two minutes by List Callers).  DEFUN has
    declared indentation, so that variable has no effect on it.  I suppose it's
    possible that in some older release that you vaguely remember, DEFUN used not to
    have declared indentation.  Subtle details like this that don't affect program
    compatibility would be unlikely to be in the release notes anyway (do you really
    want a thousand pages of release notes)?

While strictly they don't affect executable compatability but they sure make my life
uncomfortable. I like to fit the maximum amount of code on a line so that the maximum
amount of code fits on a screen full. Thats why I changed the indentation from 2 to
1. I also, regularly use the indentation commands to reindent functions and buffers
automatically. Now, I have a file that used to have line breaks such that when it
was indented, all lines fit on one line. When, I changed releases, this ws no longer
the case. And I had to manually go and rebreak many of the lines in my file. That
took a lot of time and in my mind defintely is an issue of programming environment
compatability.
        Jeff