Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!olivea!apple!jkc
From: jkc@Apple.COM (John Kevin Calhoun)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: COMPACT STACK BUG? with HC 2.0 & Superclock v3.9
Message-ID: <48081@apple.Apple.COM>
Date: 14 Jan 91 23:56:21 GMT
References: <1991Jan12.201544.2758@fennel.cc.uwa.oz.au>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 61


In article <1991Jan12.201544.2758@fennel.cc.uwa.oz.au> ciru@fennel.cc.uwa.oz.au
(Mike Schon-Hegrad) writes:
>Here is one of the most obscure bugs/phenomenon/whatever that I've seen for a
>while!
>
>I'm presently working on a large project using Hypercard 2.0 which requires me
>to compact my stacks on a regular basis as I'm developing.  Today I found my
>disk space becoming more and more depleted as the morning went on and I
>quickly tracked the problem down to the resource fork of my stack which
>Disktop showed as being over 1mb in size.  I did another "Compact stack" and
>the resource fork increase nearly double again!
> [...]
>I then discovered that the problem only occured because the font I was using
>to display my clock (Athens 18) was also a resource in the stack.  Taking
>Athens out of the stack stopped the increase in size of the resource fork
>after compacting as did changing the clock font to something else other than
>the fonts that were in my stack.

Did you ever try to count from 1 to 100 when someone else in the room was
shouting numbers out of sequence?  I've just seen a television advertisement
for a coffee machine that depicts a similar situation -- a man loses count of
the scoops of coffee he has to put into his (presumably inferior) machine
while he listens to a radio announcer.

Here's what was happening:  HyperCard was losing track of where it was in
the resource fork, because the Macintosh toolbox stepped in and read from
a different part of the same file.

1.  HyperCard reads bytes 1 to gadzillion of the old resource fork and
    copies them into the resource fork of the newly compacted stack.  The
    file marker is now at (gadzillion + 1).
2.  Unlike HyperCard 1.2.5, HyperCard 2.0 will allow your clock to update
    itself during the compaction process.  So, before continuing with the
    transfer of bytes (gadzillion + 1) to (2 x gadzillion), your clock gets
    a chance to do its thing.  The clock calls QuickDraw to draw the current
    time.  QuickDraw calls the Font Manager.  The Font Manager calls the
    Resource Manager, which finds the proper font resources in your stack.
    The Resource Manager calls the File Manager to read the data for the font
    into memory, and when the File Manager is done, the file marker is set
    to the byte at which it stopped reading.
3.  HyperCard continues copying the resource fork, but not from where it
    left off.  Instead, it copies from wherever the file marker happens to
    be.  Oops.

>I'm not sure whether this is a bug in Hypercard version 2.0 or whether it is a
>problem with SuperClock 3.9

Well, instead of trying to figure out whose bug it is, we decided just to fix
it.  It's fixed in HyperCard 2.0v2.

>                                                            ...what is the
>phone no for Claris in the States [NOT the toll free no], could I ring them
>and get them to send me a copy here in Oz.  Claris Australia is not handling
>HC as yet!)

You can call Claris Customer Relations in the U.S. at (408) 727-8227.

Kevin Calhoun
HyperCard Team
Apple Computer, Inc.