ciru@fennel.cc.uwa.oz.au (01/12/91)
Here is one of the most obscure bugs/phenomenon/whatever that I've seen for a
while! It is not a serious problem, just a curious one but may be a bug in HC
2.0
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 tried to open the stack with ResEdit v 2.0, however, on opening, ResEdit
reported that the stack needed minor repairs and repaired it automatically
bringing the resource fork down to its correct size of 40k.
I restarted my Mac (an SE/30 running a RasterOps 264 SE/30 video card with RGB
monitor 5mb RAM System 6.07) and went back to my stack and compacted it again
and found that the resouce fork remained at 40k. The only difference from the
previous times was that I was running my monitor in 8 bit mode this time
instead of 1 bit previously so I hit the Switch-a-roo F Key back to 1 bit
mode, compacted the stack and the resource fork of my stack went from 40k to
63k!
(With each compaction it increased as follows: 40k, 63k, 108k, 198k, 379k,
610k, 842k etc.)
Well, having tried switching back to 8 bit mode either using Switch-a-roo or
the monitors cdev, I found that this increase in size of the Stack resource
fork only happened in 1 bit mode.
The next step was to turn all the inits etc off to see if it was one of those
causing a problem. With all my inits/cdevs turned off, the problem went away.
I tested the inits/cdevs that I was suspicious of without finding the culprit
and of course the LAST init I loaded (out of 7) to test, Superclock (version
3.9), turned out to be causing the problem.
Superclock alone (all other inits etc turned off) caused the problem, and
again only in 1 bit mode and not when 256 colours were running.
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.
I put Chicago 12 into my stack using Font/DA mover, however, this did not have
the same effect when the clock was displayed in Chicago. In other words the
resource fork stayed the same size after compaction so it didn't occur with
all fonts.
Puting Athens into the System file had no effect, the resource fork still
increaed.
SO.........In summary
1. Superclock v 3.9 running a font that is in a stack may cause an
increase in size of the resource fork of that stack during compaction.
2. This phenomenon only occurs 1 bit mode and not 8 bit mode.
3. This phenomenon does not occur with all fonts.
4. Opening the stack with Resedit 2.0 'cures' the increase bringing the
resource automatically back to it's correct size.
5. Opening the stack with Resedit 1.3 doesn't provide any clues as to
where the extra increase size is occuring.
I'm not sure whether this is a bug in Hypercard version 2.0 or whether it is a
problem with SuperClock 3.9
The stack that I'm running has the following resources installed:
1. Athens 18 Font
2. Sydney 12 Font
3. Fullsort (Rinaldi)
4. ShowDialog
5. Mousoid (Rinaldi)
6. ShlSort
7. FullFind (Rinaldi)
8. HPopUpMenu
I've provided all this info so that someone out there (maybe Kevin Calhoun or
Steve Maller) may be able to tell me what is happening here as well as perhaps
informing you/them of a possible bug.
Do I get a copy of Hypercard 2.02 shipped to me pronto for describing one of
the more unusual phenomenon found with Hypercard 2.0?????
(Sorry, the last statement was added in jest..........well, half jest! Here
in Oz you can't even get you hands on the FULL version of HC 2.0 [unless you
know someone in the one Usergroup in Australia with it] let alone v 2.02!!!!
Is there anything preventing someone that has a copy in the States from
sending me a copy?? I'm desparate! This is the second bug I've discovered in
a week, [Kevin, thanks for your note on the last one!] even though this second
one is a bit obscure with an easy work around. Alternatively, 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!)
Thanks in advance for any responses.
***********************************************************
* Mike Schon-Hegrad *
* Research Officer *
* Western Australian Research Institute for Child Health *
* Princess Margaret Hospital *
* Thomas Street, Subiaco *
* West Australia 6008 *
* *
* CIRU@FENNEL.CC.UWA.OZ.AU *
***********************************************************jkc@Apple.COM (John Kevin Calhoun) (01/15/91)
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.