Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!orion.cf.uci.edu!uci-ics!zardoz!dhw68k!felix!tgate!ka3ovk!drilex!axiom!linus!mbunix!keough
From: keough@mbunix.mitre.org (Jerry E. Keough)
Newsgroups: comp.sys.mac.programmer
Subject: Re: LSP bugs
Message-ID: <57509@linus.UUCP>
Date: 23 Jun 89 12:15:06 GMT
References: <2589@daimi.dk>
Sender: news@linus.UUCP
Reply-To: keough@mbunix (Keough)
Organization: The MITRE Corporation, Bedford, Mass.
Lines: 55

In article <2589@daimi.dk> rask@daimi.dk (Jorgen Rask) writes:

>I have been working on a project in LSP for some months now 
>and suddenly a lot of strange behaviour is occuring.
>    (... describes behaviour ... )
>  Fortunately this mysterious error disappeared after a complete
>rebuild of the project.

One project I have is about 10,000 lines of code
and it's heavily object-oriented (keeping all those
method tables quite full I'd guess). I once added one method to an
object, and the linker told me, essentially, that just about everything
I'd ever defined was 'undefined'. As you say, rebuilding after deleting
the object code cleared everything up.

I'd recommend doing this rebuild from scratch every so often as
standard procedure, no matter how large a project you put together.
Although you'd think that it might be related to the complexity of the
code (like: lots of objects and methods to resolve) or its volume, it's not.
I saw a friend's project recently (<1000 lines) where a call to 'concat' was
incorrectly compiled - it seemed as if all the references to
library routines were "off just a few bytes". Rebuilding did the trick.

>Today the editor begins to garble in a most disquieting way:
>when scrolling a file pagewise, big chunks of code gets 
>displaced and after sufficiently long (short) time of scrolling
>around LSP bombs. 

I had this one just the other day, without the bomb. Quitting and restarting
seemed to clear things up, so I'd guess that memory was a little low
(although it was an 1800K partition under multifinder on an SE/30 
- with 5 megs).

>  Similiar behaviour was observed two months ago, and after a
>few days tracking I then found that compound statements in a
>case-statement (i.e. with "begin"s in some of the cases) was the
>culprit. .......

There are cases where the formatter can get faked out - as can one
of the nicest features of getting quickly to any procedure in a unit.
For example, define a procedure like X(y:integer;external:boolean).
'external' is not reserved, the formatter seems OK about it, but if
you do an option-click on the title bar to list procedures, the
list will be pretty much out of whack after the declaration of X.
(I'm pretty sure that's the exact sequence, anyway; I could be more
specific if necessary)

In general, I'm impressed by LSP and I recommend it highly to all. The
problems described above are, generally, rare and infrequent; but
of course I'd like to see them fixed too. (Keep up the good work, Rich!)

Jerry Keough
Lead Scientist
The MITRE Corporation
keough@mbunix.mitre.org