🚀 go-pugleaf

In article <2638@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu (Julian Vrieslander) writes:
>In article <21246@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
>>Why bother? Just crank up the RAM Cache on the control panel and you get
>>better than the same effect: the include files that are getting used a lot
>>right now, stay in the cache, and you don't have to worry about explicitly
>>moving files around.
>
>This certainly does give a nice speed increase, especially if you have
>2 Meg or more to run around in.  But I am hesitant to use RAM cache when
>I am debugging tricky code that is crashing a lot; I worry about losing
>source changes that have not been written from the cache out to disk.  
>
>I asked one of the folks at Think whether LSC was smart enough to
>flush the cache before a project is started up from the "Run" command.  He
>claimed that this was not the case, and that there was no way that LSC
>could tell whether the cache was enabled.  He said that he did not trust
>the RAM cache well enough to use it for his own development work.

Two funny things about this: first, it is certainly possible
for LSC to determine if the cache is enabled.  How does the
Control Panel do it? Divine intervention?  I wrote an FKEY to
toggle the cache setting it is trivial to check for the cache.

Second, I have used LSC plenty with the cache on and I have
crashed it just as often and I have yet to lose a single
character of source this way.  

Ever since Apple came up with the cache it has been given a
constant bad rap, in my opinion. I think it's a safe, great
idea.

David Fry				fry@huma1.harvard.EDU
Department of Mathematics		fry@harvma1.bitnet
Harvard University			...!harvard!huma1!fry
Cambridge, MA  02138