Rules governing stack purging

Mark Smith mark at
Mon Oct 30 13:38:27 EST 2006

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  



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
>  ___________________________________________________________
>  Ambassador at
> _______________________________________________
> use-revolution mailing list
> use-revolution at
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:

More information about the use-livecode mailing list