[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

8.0.1 complaints on SLUG



    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.  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.

    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.

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)?