My experience is that having accessed a stack on disk, it remains in
memory until you explicitly close it ie. < close stack "/Users/
blah...." >
For some reason, when you've accessed the stack, but not yet closed
it, it doesn't show up in the openStacks, but does show up in the
application browser - once you've closed it, however, it seems to be
really gone from memory.
Perhaps not showing up in the openStacks is a bug?
This is on Mac OS X, 2.7.4 (though I encountered this in 2.6xx, as
well).
Best,
Mark
On 30 Oct 2006, at 17:48, Richard Gaskin wrote:
I'm working with a client on a system that makes extensive use of
data stored in custom properties.
I had been under the impression that as long as the stack
containing the data has its destroyStack set to true, and as long
as we don't open the stack, everytime we access its properties
we're getting it fresh from disk rather than from cached memory.
Is that correct?
We're in the process of pinning down some anomalies in our system
which would seem to suggest that accessing properties can cause a
stack to remain in memory such that subsequent accesses are
obtained from memory rather than from disk.
I would love to be wrong, as it would complicate our system to have
to manually purge each stack before accessing it.
And as for that purging, in the absence of a purge command there is
the workaround of using the delete command, but at the moment my
memory's flakey: does using "delete stack" merely purge the stack
but not delete the actual stack if it's a mainStack, or if it's a
substack?
And once we confirm which type of stack we can safely purge without
deleting it using the "delete stack" command, what method do we use
to purge stacks of the other kind?
--
Richard Gaskin
Fourth World Media Corporation
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution