mtchris@PacBell.COM (Mitchell T. Christensen) (01/29/91)
Why hasn't Apple provided a means to grow application memory
requirements dynamically. For instance. I have a large (full
page) stack I use about twice a month. When using this stack I
must set application memory size to 2meg. The rest of the time
1meg is fine. This leads to...
twice a month,
Quit HyperCard.
Set application memory size to 2meg.
Restart hypercard.
Make changes.
Quit HyperCard.
Reset application memory size to 1meg.
Restart HyperCard.
Does this make sense to everyone? Is it just me?
Nuff Said!
--
/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-
Mitch Christensen - {att,bellcore,sun,ames,pyramid}!pacbell!pbhyf!mtc
Internet: mtc@pacbell.com
/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-bc@Apple.COM (bill coderre) (01/30/91)
Mitchell Christensen: | Why hasn't Apple provided a means to grow application memory | requirements dynamically. For instance. I have a large (full | page) stack I use about twice a month. When using this stack I | must set application memory size to 2meg. The rest of the time | 1meg is fine. This leads to... Well, it ain't Hypercard's fault, but rather that of the Mac OS, which wasn't really intended to do multi-whatever-ing. Multifinder is a really great hack, but it cannot work miracles. If one app opened up, and was given (say) 1 meg, then another opened up, then the first needed more memory, well, it would be out of luck because there is no way to move the other app out of the way without crashing it. Last I looked, there was a big "discussion" about this in comp.sys.mac.programmer. bill coderre not apple's spokesdroid
clarson@ux.acs.umn.edu (Chaz Larson) (01/30/91)
In article <8540@pbhyf.PacBell.COM> mtchris@PacBell.COM (Mitchell T. Christensen) writes: | Why hasn't Apple provided a means to grow application memory | requirements dynamically. For instance. I have a large (full | page) stack I use about twice a month. When using this stack I | must set application memory size to 2meg. The rest of the time | 1meg is fine. This leads to... | | twice a month, | | Quit HyperCard. | Set application memory size to 2meg. | Restart hypercard. | Make changes. | Quit HyperCard. | Reset application memory size to 1meg. | Restart HyperCard. | | Does this make sense to everyone? Is it just me? Well, this doesn't cure the problem, but it does eliminate a lot of the hassle. on sumex, get the cdev: /cdev/app-sizer-20.hqx which will allow you to set application partitions on the fly. If you hold the control key down when you launch the app, you will get a dialog which lets you make this change. I believe the change can be noted as temporary. nifty and small. chaz. -- Someone please release me from this trance. clarson@ux.acs.umn.edu AOL:Crowbone
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (01/30/91)
In article <8540@pbhyf.PacBell.COM>, mtchris@PacBell.COM
(Mitchell T. Christensen) hits a refrain familiar to all us long-time
MultiFinder users: why should we have to keep reconfiguring our
application partition sizes?
The solution is simple: when running under MultiFinder, HyperCard
should allocate the widely-variable parts of its memory usage in
the system heap.
Lawrence D'Oliveiro fone: +64-71-562-889
Computer Services Dept fax: +64-71-384-066
University of Waikato electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00gandalf@apple.com (Martin Gannholm) (01/30/91)
In article <1991Jan30.095551.2855@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > In article <8540@pbhyf.PacBell.COM>, mtchris@PacBell.COM > (Mitchell T. Christensen) hits a refrain familiar to all us long-time > MultiFinder users: why should we have to keep reconfiguring our > application partition sizes? > > The solution is simple: when running under MultiFinder, HyperCard > should allocate the widely-variable parts of its memory usage in > the system heap. Aaaargh! Sorry, no can do. There are enough things that use the system heap but shouldn't. The solution under System 7.0 is to use MultiFinder temp memory to hold document-specific information. HyperCard 2.0 even uses temp memory if it is available, but before 7.0 the support for temp memory isn't flexible enough to use it for a wider range of things. In 6.0.x systems you should only use MF temp memory (that's temp as in "temporary") for a very short time. Soon enough, this cold winter will be over, system 7 will ship, companies will rev their apps & everything will be, as we say in Swedish, "en dans p} rosor" (like dancing on roses). Martin Gannholm Apple Computer Exclaimer!!! I never said it...Nobody heard me say it...You can't prove anything!
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (01/30/91)
In article <11910@goofy.Apple.COM>, gandalf@apple.com (Martin Gannholm)
responds to my suggestion about using the system heap for dynamically-
varying storage requirements under MultiFinder:
"Aaaargh! Sorry, no can do. There are enough things that use the system
heap but shouldn't. The solution under System 7.0 is to use MultiFinder
temp memory to hold document-specific information. HyperCard 2.0 even uses
temp memory if it is available, but before 7.0 the support for temp memory
isn't flexible enough to use it for a wider range of things. In 6.0.x
systems you should only use MF temp memory (that's temp as in "temporary")
for a very short time."
^^^^ ^^^^^ ^^^^
In that case, it's not a heckuva lot of use, is it? What do you suggest an
application do if it has ongoing (i e not transitory) memory requirements
that can vary *extremely* widely, depending on the data that it is called
on to handle?
Sorry, but I can only see two alternatives:
a) have the user keep reconfiguring the memory partition and
relaunching the program, or
b) start putting things in the system heap.
By the way, under 7.0, is MultiFinder temporary memory automatically
deallocated for the application when it quits? If it isn't, then I
can't see much difference between the MultiFinder temporary heap
and the system heap.
Lawrence D'Oliveiro fone: +64-71-562-889
Computer Services Dept fax: +64-71-384-066
University of Waikato electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00gandalf@apple.com (Martin Gannholm) (01/31/91)
In article <1991Jan30.192213.2863@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > What do you suggest an application do if it has ongoing > (i e not transitory) memory requirements that can > vary *extremely* widely, depending on the data that it is called > on to handle? Well, firstly if the system software were perfect and fit every need, they wouldn't be working on a System 7.0, would they? There are applications out there that do caching of data onto disk when there isn't enough memory available. I believe that some of the color image manipulation programs do this. HyperCard also does this for objects such as cards and backgrounds of a stack. You don't ask it to, it just does it automatically. When it comes to the buffers that HyperCard uses you couldn't really be paging those onto the disk all the time (manual VM), since you want real-time response when the user clicks and drags on the card. QuickDraw also can't use disk memory as the buffer for a grafport. D'Oliveiro continues: > By the way, under 7.0, is MultiFinder temporary memory automatically > deallocated for the application when it quits? If it isn't, then I > can't see much difference between the MultiFinder temporary heap > and the system heap. I believe so, but I may be wrong. Also, multifinder has the option to put the memory you ask for in any place it pleases, thereby minimizing some of the effects of application fragmentation (you know, largest unused block in "About the Finder"). As programs and the use of them changes over time we'll see need for changes in the operating system to provide a better model. One of the amazing things is that a lot of changes have been made to the Mac over the years, but with relatively few incompatibilities. Those of us that are programmers need to be ready to change some of the ways we do things every now and then. Programming the Mac is always going to be a moving target, and nobody ever said that it was easy. Martin Gannholm Apple Computer Exclaimer!!! I never said it...Nobody heard me say it...You can't prove anything!