Rules governing stack purging

[Dave]

Hi,

For what it's worth, I think that all that needs to be changed is to  
rename or alias the delete stack command to purge, in the meantime  
I'd create a function/handler called "PurgeStack" that does it.

One thing that struck me is that if you were to want to grab a lot of  
cp's from a stack, as in:

put the cp1 of stack_long_name into x1
put the cp2 of stack_long_name into x2
put the cp3 of stack_long_name into x3
put the cp4 of stack_long_name into x4
put the cp5 of stack_long_name into x5

etc.

Then surely if you purged it from memory after each access then it  
would take a very long time to grab all the data, especially if the  
stack were large in size and their were a lot of data.

IMO tho, the better way around it would be to introduce a concept of  
a read-only stack, it could be handled in many ways, this would be  
one of them:

set the stackStatus of stack_long_name to "readonly"

(now read the values as above)

When the cp is set, it would cause the stack to be read into memory  
and it's status to be set to "readonly". An error would occur if the  
stack were already open (e.g. status of "readwrite"). If in read only  
mode and an attempt to write to the stack is made, then an error  
would occur (maybe controlled by another (global) cp). If the stack  
were opened then it's status would become "read-write" and since it's  
already in memory, it would be quicker.

Having said all that, I do it a different way, since I fell foul of  
the problems you are experiencing.

My approach it to do this:

set the visible of stack_long_name to false
set the cpFlagGetData of stack_long_name to true
open stack stack_long_name
--Call a function (using value()) in the stack that causes it to send  
it's data back to the calling stack
--by calling a predefined "AcceptData" function in the calling stack
set the cpFlagGetData of stack_long_name to false
save stack stack_long_name
close stack stack_long_name

(I just put all this in a function)

Then if the stack is opened with the cpFlagGetData set to false, I  
just make it visible in the preOpenStack handler.

Now I have combined all this into my ISM module so it all happens  
automatically, but that's how I did it before I wrote ISM.

All the Best
Dave


On 1 Nov 2006, at 07:18, Chipp Walters wrote:

> I'm going to have to agree with Dave and Trevor. I've always thought
> destroyStack comes into play only when closing stacks. If set to  
> true, the
> stack is purged from memory (usually). I pretty much always use an  
> explicit
> 'delete stack "xyz"' when I want to make sure a mainstack is closed.
>
> And like Dave, I, too, use stacks as repositories for data.  
> Richard, I'm not
> sure I understand your comment about parsing the stack file format.  
> I'm
> pretty sure Dave is just talking about using stacks to store data in--
> separate from the business logic of the application. I typically use:
>
> go inv stack "xyz" when I want to access data from a stack. Though  
> I also
> frequently check a custom prop for versioning, too. In both cases, I'm
> careful to 'delete' the stack when done.
>
> I think Dave's point regarding reading customProps from a stack, doing
> something with them, then saving them to the stack and finally  
> closing it,
> is common among many of us who use customProps to hold data. Finally,
> Richard, I know you use the fine MC IDE and have a whole sweet(sp)  
> of tools
> you use. But, in the Rev IDE, I'm with Jacque and one of the first  
> things I
> do is set the default pref for destroyStack to true. It just works  
> better. I
> think it should be the default.
>
> I guess it's one of choice. Mine is to leave it like it is, but I  
> do agree
> some naming nomenclature may be necessary. I particularly like the  
> notion of
> a 'purge stack' command.
>
> -Chipp
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution