mmt@client1.DRETOR.UUCP (Martin Taylor) (11/16/89)
General question: under what circumstances should a stack be expected
to change its size (i.e. produce free memory in stack) when it is being
browsed at userlevel 1? It seems to me this should never happen, but it
does, and to an alarming degree.
Particular example: I have a stack that consists mainly of a whole lot
of popup fields on a painted background (card fields, not background
fields). The fields contain between 4 and perhaps 40 words, and their
programming is identical (except for the name of the field being popped up).
After compacting the stack (free memory = 0) the userlevel is set to 1.
A button is clicked that pops up one of the fields. Set the userlevel
to 5 and look at the stack info--free memory 22K! (Lots of disk action
accompanying the popup event). But do this with another button (and
on one occasion out of perhaps 20 with the same one) and zero free memory
is added to the stack. Other buttons give different amounts of added
free memory, and the loss seems to be cumulative. If the same 22K-losing
button is re-used, it does not lose any more space, but other space-losing
buttons do lose extra space. After a bit of browsing, my stack had lost
almost 100K.
This is not nice. Is its cause known? Is a work-around known?
--
Martin Taylor (mmt@zorac.dciem.dnd.ca ...!uunet!dciem!mmt) (416) 635-2048
If the universe transcends formal methods, it might be interesting.
(Steven Ryan).mmt@client1.DRETOR.UUCP (Martin Taylor) (11/16/89)
I forgot to include the system parameters in my query about the growth of
stack size during browsing: Hypercard 1.2.2 System 6.0.2 on MacPlus or SE
with a variety of init sets, sometimes under Suitcase II (in other words
replicable including the amount of stack growth for a given popup field
in the stack on different machines but with the same HyperCard and System).
--
Martin Taylor (mmt@zorac.dciem.dnd.ca ...!uunet!dciem!mmt) (416) 635-2048
If the universe transcends formal methods, it might be interesting.
(Steven Ryan).stadler@Apple.COM (Andy Stadler) (11/17/89)
In article <2663@client1.DRETOR.UUCP> mmt@client1.DRETOR.UUCP (Martin Taylor) writes: > >General question: under what circumstances should a stack be expected >to change its size (i.e. produce free memory in stack) when it is being >browsed at userlevel 1? It seems to me this should never happen, but it >does, and to an alarming degree. > I would guess that the scripts involved in browsing this card are putting data into (possibly hidden) fields. If a field is empty, the card will compact down, but to put text into the field, HyperCard must move the card within the stack file to allow more space (so it can put the text somewhere). Typically, the card will be moved to the end of the stack, so it can grow outward; this leaves a hole of (old card size) where it used to be. If you are _designing_ a stack, and you don't want this happening, the easiest way to fix this is to set "cant modify" in the stack info box. This should prevent HyperCard from ever writing to the disk file. It can, however, slightly slow operation. The rule is, if you've set cantModify, that a script can make all the changes it wants but when you leave the card and come back, it will "snap back" to its original state. That means that even if the card is still in RAM, it must be thrown out and reloaded from disk. --Andy stadler@apple.com
psych@watserv1.waterloo.edu (R.Crispin - Psychology) (11/17/89)
I get the same thing with a stack I am working on. It is a map of the building my office is in. Each office has a button on the floor plan. If I access anyone of the 4 floor plans I end up with having around 52K of free space. When my stack closes it checks to see if their is 8K of free space and if so it compacts the stack. I have experimented with a few things to try and narrow things down. I discovered that by putting the button scripts in the background script and just calling the handler from the button I was able to reduce the free space from around 170K to the current 52K (there is about 450 buttons over 4 cards). It seems that card buttons generate at least a 100 bytes of working space that is not really needed in the stack. Unless I can find a solution I will change my close stack script to look for 55K instead of 8K. Richard Crispin Dept. of Psychology Bitnet: psych@watdcs University of Waterloo Unix : psych@watdcsu.UWaterloo.ca Waterloo, Ont. Canada N2L 3G1 (519)885-1211 ext 2879
MXC117@PSUVM.BITNET (mary carpenter) (11/19/89)
I'm not sure of the technical reasons for a hypercard stack gaining memory
space (i.e. losing free disk space), but the easiest way to think of it is to
imagine a physical deck of cards and what they look like before and after a
shuffle. The extra space in the stack is like the air in a regular deck.
If you're writing your own stack (or have authoring/scripting access) you can
insert, either at the end (on closeStack) or at places in between if the loss
of free space is really a problem, a doMenu "compact stack" (I'm not sure if
the quotes are needed). This will take a little time, but it's most likely
worth it.
mary carpenter (mxc117@psuvm.bitnet)tom@wcc.oz (Tom Evans) (11/21/89)
In article <159@watserv1.waterloo.edu>, psych@watserv1.waterloo.edu (R.Crispin - Psychology) writes: > I get the same thing with a stack I am working on. It is a map of the (People are having trouble with stacks growing when they're browsed) Does it help if you Lock the stack? --------- Tom Evans tom@wcc.oz.au | Webster Computer Corp P/L | "The concept of my 1270 Ferntree Gully Rd | existence is an Scoresby VIC 3179 Australia | approximation" Australia | 61-3-764-1100 FAX ...764-1179 | D. Conway