Re: Rules governing stack purging
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@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
Re: Rules governing stack purging
Richard, et al., Any reference to any object in a stack (or the stack itself) that includes its file path name (the long name, the long id) will place it in memory. You might consider that. We had that bite us several times with Constellation and Galaxy in managing our tabs for objects. Best, Jerry Daniels Makers of Galaxy 1.5 http://www.daniels-mara.com/new_in_galaxy_1_5.htm On Oct 30, 2006, at 10:48 AM, 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
Re: Rules governing stack purging
On Oct 31, 2006, at 7:59 AM, Richard Gaskin wrote: That this would be the case with stacks whose destroyStack property is FALSE makes sense, but when a stack's destroyStack is TRUE this is inconsistent with other behaviors we've come to expect from the engine. Given that this has caused confusion for yourself, Jacque, Ken, myself, and other experienced Rev programmers, it seems reasonable to request that the destroyStack property be honored consistently, which I've done in BZ#3937: Richard, I'm not sure I understand why a stack should not be brought into memory and stay in memory until told otherwise when accessing it using the complete filenmae. destroyStack docs state that it applies when a stack is closed. Since the stack is never officially opened (no go stack, no msg sent) it is not closed so in my mind it should remain in memory. -- Trevor DeVore Blue Mango Learning Systems - www.bluemangolearning.com [EMAIL PROTECTED] ___ 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
Re: Rules governing stack purging
Jerry Daniels wrote: Any reference to any object in a stack (or the stack itself) that includes its file path name (the long name, the long id) will place it in memory. You might consider that. We had that bite us several times with Constellation and Galaxy in managing our tabs for objects. That this would be the case with stacks whose destroyStack property is FALSE makes sense, but when a stack's destroyStack is TRUE this is inconsistent with other behaviors we've come to expect from the engine. Given that this has caused confusion for yourself, Jacque, Ken, myself, and other experienced Rev programmers, it seems reasonable to request that the destroyStack property be honored consistently, which I've done in BZ#3937: http://support.runrev.com/bugdatabase/show_bug.cgi?id=3937 -- 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
Re: Rules governing stack purging
On 30 Oct 2006, at 22:43, Richard Gaskin wrote: Consider your subsequent post: I just remembered something (third time this week, must be the new pills). Aren't unused stacks purged from memory by the engine when it needs to reclaim memory? I think I'm referring to stacks without the destryStack set, but which have been closed. I seem to recall reading this somewhere, either in the old Metacard docs, or the MC mailing list from long ago. If it's true, I wonder if it applies to unopened stacks in memory too. This implies the engine introduces a sometimes rule (sometime it does one thing, sometimes something else), which is generally bad news. If this purging actually happens, which I don't know for sure, I don't think it's such a bad thing. It would only affect stacks that have been specifically closed, or that have been put in memory as a result of a direct reference to the stack file. Any subsequent reference just requires the engine to load the stack again. Nothing lost. I'm still don't see how your suggestion will produce something more consistent than the current behavior. Going back to my set and save example: set the cProp of stack C:/myStack.rev to tData save stack C:/myStack.rev Under your proposal, if the stack's destroyStack property is true, nothing will have changed in the stack. I don't see how this can be considered consistent with anything. You say you were caught by this, but I'm still not clear what problems it causes. The only situation I can think of is if a second app changed the stack on disk while the first app had it in memory, and the first app expected subsequent references to load the stack from disk again. If this is the case, I don't think it is a normal situation, and we know we have to take care when two apps are mucking around with files. But under your suggestion, if I want to use a stack as a data file, I have to be sure to set it's destroyStack to false. I suspect more people will be caught by that. Cheers Dave ___ 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
Re: Rules governing stack purging
I certainly wouldn't cry if that happened, although now i use the same device to put a stack into memory. I admit it is a back handed way to do things, tho. Best, Jerry Daniels Makers of Galaxy 1.5 http://www.daniels-mara.com/new_in_galaxy_1_5.htm On Oct 31, 2006, at 9:59 AM, Richard Gaskin wrote: Jerry Daniels wrote: Any reference to any object in a stack (or the stack itself) that includes its file path name (the long name, the long id) will place it in memory. You might consider that. We had that bite us several times with Constellation and Galaxy in managing our tabs for objects. That this would be the case with stacks whose destroyStack property is FALSE makes sense, but when a stack's destroyStack is TRUE this is inconsistent with other behaviors we've come to expect from the engine. Given that this has caused confusion for yourself, Jacque, Ken, myself, and other experienced Rev programmers, it seems reasonable to request that the destroyStack property be honored consistently, which I've done in BZ#3937: http://support.runrev.com/bugdatabase/show_bug.cgi?id=3937 -- 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
Re: Rules governing stack purging
Richard, Jerry, Chipp, Jacque, Ken, Jeanne, Dave, Phil, et. al., Should bug #3937 be combined with bug #1081? It has been so long, I'd forgotten about it. Paul Looney ___ 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
Re: Rules governing stack purging
Trevor DeVore wrote: On Oct 31, 2006, at 7:59 AM, Richard Gaskin wrote: That this would be the case with stacks whose destroyStack property is FALSE makes sense, but when a stack's destroyStack is TRUE this is inconsistent with other behaviors we've come to expect from the engine. ... I'm not sure I understand why a stack should not be brought into memory and stay in memory until told otherwise when accessing it using the complete filenmae. destroyStack docs state that it applies when a stack is closed. Since the stack is never officially opened (no go stack, no msg sent) it is not closed so in my mind it should remain in memory. By default it would work exactly as it does now. By default, the engine creates stacks with their destroyStack property set to false. The destroyStack property is used to govern whether a stack remains in memory when using go or open, but it not honored when a property within a stack is accessed. By honoring the destroyStack property consistently, accessing properties of stacks which have this set to true would cause the engine to read the file, obtain the data, dispose of the copy of the stack in memory, and return the value requested. -- 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
Re: Rules governing stack purging
Jerry Daniels wrote: I certainly wouldn't cry if that happened, although now i use the same device to put a stack into memory. I admit it is a back handed way to do things, tho. And with the proposed consistency in honoring the destroyStack property, you could still do that effortlessly by just leaving that property in its default setting of false. -- 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
Re: Rules governing stack purging
Dave Cragg wrote: On 30 Oct 2006, at 22:43, Richard Gaskin wrote: Consider your subsequent post: I just remembered something (third time this week, must be the new pills). Aren't unused stacks purged from memory by the engine when it needs to reclaim memory? I think I'm referring to stacks without the destryStack set, but which have been closed. I seem to recall reading this somewhere, either in the old Metacard docs, or the MC mailing list from long ago. If it's true, I wonder if it applies to unopened stacks in memory too. This implies the engine introduces a sometimes rule (sometime it does one thing, sometimes something else), which is generally bad news. If this purging actually happens, which I don't know for sure, I don't think it's such a bad thing. It would only affect stacks that have been specifically closed, or that have been put in memory as a result of a direct reference to the stack file. Any subsequent reference just requires the engine to load the stack again. Nothing lost. But it's still ambiguous; you never really know whether the stack is coming fresh from disk or whether its the copy that was last in memory. By honoring the destroyStack property consistently with its behavior for go and open, we would gain greater certainty about what's in memory. I'm still don't see how your suggestion will produce something more consistent than the current behavior. Going back to my set and save example: set the cProp of stack C:/myStack.rev to tData save stack C:/myStack.rev Under your proposal, if the stack's destroyStack property is true, nothing will have changed in the stack. I don't see how this can be considered consistent with anything. Under what circumstances do you want to save changes to a stack that you neither open nor have its destroyStack left in its default setting? You say you were caught by this, but I'm still not clear what problems it causes. The only situation I can think of is if a second app changed the stack on disk while the first app had it in memory, and the first app expected subsequent references to load the stack from disk again. If this is the case, I don't think it is a normal situation, and we know we have to take care when two apps are mucking around with files. Ever make multi-user apps? I make quite a few. I'm not sure what normal means in this context. I think a lot of single-user apps are abnormal. :) But under your suggestion, if I want to use a stack as a data file, I have to be sure to set it's destroyStack to false. I suspect more people will be caught by that. Whether we honor destroyStack for property access or not, either circumstance will require the addition of a line of code to cover all bases. If we leave the current situation where destroyStack is ignored for property accesses, we can work around this by adding a line using the delete stack command. If we honor destroyStack for property accesses, you can work around this by adding a line to open the stack invisibly first, or solve it with no code at all by just leaving the destroyStack property in its default setting. It may also be worth noting that while we have the delete stack workaround, it only applies to mainStacks. Using the same command on the other type of stack, substacks, will cause the stack to be deleted from the file. So not only do we have a dangerous ambiguity in the language (addressed in BZ#1081), we also have no way of purging substacks from memory directly. Here's a circumstance in which I don't know what the result would be: You have a stack file with mainstack A and substack B, both with their destroyStack set to true. You open substack B, which causes the whole stackfile to be read into memory, but do not open stack A. When you close stack B, does the stackfile remain in memory? -- 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
Re: Rules governing stack purging
On Oct 31, 2006, at 11:08 AM, Richard Gaskin wrote: The destroyStack property is used to govern whether a stack remains in memory when using go or open, but it not honored when a property within a stack is accessed. By honoring the destroyStack property consistently, accessing properties of stacks which have this set to true would cause the engine to read the file, obtain the data, dispose of the copy of the stack in memory, and return the value requested. I guess in my mind the current behavior makes sense. I see a read of a property as something that reads a property, bringing it into memory if need be to complete the operation. You approach it as the reading of the property being an open/read/close operation so destroyStack should come into play. Is that correct? -- Trevor DeVore Blue Mango Learning Systems - www.bluemangolearning.com [EMAIL PROTECTED] ___ 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
Re: Rules governing stack purging
Hi All, If all that is required is to read a property from a stack, couldn't there be some way of loading is read-only? e.g. load stack (read only) long_name put the cp of stack long_name into x Just a thought. Dave On 31 Oct 2006, at 17:48, Dave Cragg wrote: On 30 Oct 2006, at 22:43, Richard Gaskin wrote: Consider your subsequent post: I just remembered something (third time this week, must be the new pills). Aren't unused stacks purged from memory by the engine when it needs to reclaim memory? I think I'm referring to stacks without the destryStack set, but which have been closed. I seem to recall reading this somewhere, either in the old Metacard docs, or the MC mailing list from long ago. If it's true, I wonder if it applies to unopened stacks in memory too. This implies the engine introduces a sometimes rule (sometime it does one thing, sometimes something else), which is generally bad news. If this purging actually happens, which I don't know for sure, I don't think it's such a bad thing. It would only affect stacks that have been specifically closed, or that have been put in memory as a result of a direct reference to the stack file. Any subsequent reference just requires the engine to load the stack again. Nothing lost. I'm still don't see how your suggestion will produce something more consistent than the current behavior. Going back to my set and save example: set the cProp of stack C:/myStack.rev to tData save stack C:/myStack.rev Under your proposal, if the stack's destroyStack property is true, nothing will have changed in the stack. I don't see how this can be considered consistent with anything. You say you were caught by this, but I'm still not clear what problems it causes. The only situation I can think of is if a second app changed the stack on disk while the first app had it in memory, and the first app expected subsequent references to load the stack from disk again. If this is the case, I don't think it is a normal situation, and we know we have to take care when two apps are mucking around with files. But under your suggestion, if I want to use a stack as a data file, I have to be sure to set it's destroyStack to false. I suspect more people will be caught by that. Cheers Dave ___ 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
Re: Rules governing stack purging
Richard Gaskin wrote: Here's a circumstance in which I don't know what the result would be: You have a stack file with mainstack A and substack B, both with their destroyStack set to true. You open substack B, which causes the whole stackfile to be read into memory, but do not open stack A. When you close stack B, does the stackfile remain in memory? Yes, because destroystack is ignored for substacks. It is impossible to remove a substack from RAM until the whole stackfile is removed. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.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
Re: Rules governing stack purging
Trevor DeVore wrote: On Oct 31, 2006, at 11:08 AM, Richard Gaskin wrote: The destroyStack property is used to govern whether a stack remains in memory when using go or open, but it not honored when a property within a stack is accessed. By honoring the destroyStack property consistently, accessing properties of stacks which have this set to true would cause the engine to read the file, obtain the data, dispose of the copy of the stack in memory, and return the value requested. I guess in my mind the current behavior makes sense. I see a read of a property as something that reads a property, bringing it into memory if need be to complete the operation. You approach it as the reading of the property being an open/read/close operation so destroyStack should come into play. Is that correct? Yes. By its nature, the act of reading any part of a stack causes the stack file to be read into memory, where it's parsed to obtain the requested value. So in essence it's another form of opening a file, and that the engine currently leaves the file in memory reinforces this. Accessing properties in stacks is roughly equivalent to locking messages and opening the stack invisibly, in almost all respects except that the stack does not appear in windows(). Given the nature of the behavior, it seems to me that anything which causes a stackfile to be read into memory should follow the same memory management rules. -- 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
Re: Rules governing stack purging
J. Landman Gay wrote: Richard Gaskin wrote: Here's a circumstance in which I don't know what the result would be: You have a stack file with mainstack A and substack B, both with their destroyStack set to true. You open substack B, which causes the whole stackfile to be read into memory, but do not open stack A. When you close stack B, does the stackfile remain in memory? Yes, because destroystack is ignored for substacks. It is impossible to remove a substack from RAM until the whole stackfile is removed. That seems understandable, if snytactically murky. It means that even though we've never done anything in our script with stack A, we still need to run a delete stack on it to purge stack B. Hence Jeanne and my request for a purge stack command. :) -- 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
Re: Rules governing stack purging
Trevor DeVore wrote: On Oct 31, 2006, at 11:08 AM, Richard Gaskin wrote: The destroyStack property is used to govern whether a stack remains in memory when using go or open, but it not honored when a property within a stack is accessed. By honoring the destroyStack property consistently, accessing properties of stacks which have this set to true would cause the engine to read the file, obtain the data, dispose of the copy of the stack in memory, and return the value requested. I guess in my mind the current behavior makes sense. I see a read of a property as something that reads a property, bringing it into memory if need be to complete the operation. You approach it as the reading of the property being an open/read/close operation so destroyStack should come into play. Is that correct? I have to admit I'm with you here, Trevor. The current behavior has never bothered me, and like Jerry, I use it to implement some things in my apps. It seems trivial to add a single line that closes the stack, which is what I do. In my situation, the stacks I am accessing are very large. There would be a delay if they had to be constantly opened and closed. I could live with it if I had to set the destroystack to false, but it is convenient to have them go away completely when I do open them visibly for editing. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.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
Re: Rules governing stack purging
J. Landman Gay wrote: In my situation, the stacks I am accessing are very large. There would be a delay if they had to be constantly opened and closed. I could live with it if I had to set the destroystack to false, but it is convenient to have them go away completely when I do open them visibly for editing. Just leaving the stack properties in their default state gives you exactly what you're looking for effortlessly. -- 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
Re: Rules governing stack purging
Richard Gaskin wrote: J. Landman Gay wrote: In my situation, the stacks I am accessing are very large. There would be a delay if they had to be constantly opened and closed. I could live with it if I had to set the destroystack to false, but it is convenient to have them go away completely when I do open them visibly for editing. Just leaving the stack properties in their default state gives you exactly what you're looking for effortlessly. Well, my particular default state is to always create stacks with destroystack set to true, but I get your drift. Remember, this is a setting you can choose in Rev Preferences. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.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
Re: Rules governing stack purging
On 31 Oct 2006, at 19:27, Richard Gaskin wrote: By honoring the destroyStack property consistently with its behavior for go and open, we would gain greater certainty about what's in memory. Perhaps we see destroyStack differently. Like Trevor, I see it as something that comes into effect when you close a stack. In the cases we're discussing, no specific close stack is performed. So why should the destroyStack property come into play? I don't think destroyStack has lost its honor (if it ever had any :-)). Under what circumstances do you want to save changes to a stack that you neither open nor have its destroyStack left in its default setting? As I said, I don't think destroyStack is relevant. But if I use a stack as a data file, I want to read data, write data, and save the file. Am I missing something? Ever make multi-user apps? I make quite a few. Come on, Richard! Stack files weren't made for multi-user access. That's what databases are for. Of course we can use them, but we must expect to do a bit of work. In this case, either delete stack or close stack when you're finished with it, and whatever you do to indicate a file lock. I'm not sure what normal means in this context. I think a lot of single-user apps are abnormal. :) You've been looking at my work again. :-) Cheers Dave ___ 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
Re: Rules governing stack purging
Dave Cragg wrote: On 31 Oct 2006, at 19:27, Richard Gaskin wrote: By honoring the destroyStack property consistently with its behavior for go and open, we would gain greater certainty about what's in memory. Perhaps we see destroyStack differently. Like Trevor, I see it as something that comes into effect when you close a stack. In the cases we're discussing, no specific close stack is performed. So why should the destroyStack property come into play? What can be in memory that wasn't opened? Closing is the compliment to opening. If something is in memory it got there somehow; the stackfile was opened and read into memory. Accessing a property is of course not the same as issuing an open or go command, leaving one to surmise that the property is accessed, the data returned, and the stack data from which it was parsed is safely disposed of. But that's not the case: it turns out that the engine treats property accesses as another form of open or go, in almost all respects except that the stack is not listed in windows(). As long as the engine is leaving around data we didn't ask for, all I'm suggesting is that we might have a more consistent means of managing it. I think it's safe to say that we have near unanimity on the suggestion to clean up the nomenclature surrounding memory management of stacks (delete stack being dangerously ambiguous and destroyStack being unnecessarily frightening). If we consider introducing some more descriptive synonym for what is currently destroyStack and depricate the latter in the docs while still supporting it, and adding a purge stack command as Jeanne requested some time ago, we might at that time also consider the broader implications of how such things fit together conceptually. While it's true that some seasoned Transcripters have long ago grasped how merely accessing a property will cause a stack to be left in memory, is it the case that new users expect this as well? Under what circumstances do you want to save changes to a stack that you neither open nor have its destroyStack left in its default setting? As I said, I don't think destroyStack is relevant. But if I use a stack as a data file, I want to read data, write data, and save the file. Am I missing something? If you can read the stack file format you're a better programmer than I. Raney advised against my early attempts at exploring it, for fear I'd lose my sanity among the hashes. :) As for custom formats, when you read a file do you expect it to remain in memory by itself? Ever make multi-user apps? I make quite a few. Come on, Richard! Stack files weren't made for multi-user access. No file is made for multi-user accesses. But it happens that the stack file format is enormously well suited for small data repositories, given the ease with which we can get and set hierarchical data in custom property sets. Using stack files for data storage is a common approach. Given the with-the-grain ease of doing so, I pity the productivity of anyone storing small amounts of multi-part data in any other proprietary format. That's what databases are for. Databases are for applications where the database becomes the governing factor of most design decisions. Once you commit to using a database you're stuck with the vendor's format, must make all gets and puts through their APIs, and often this means multiple data files (I'm still mystified why so many DB vendors can't put their metadata in a header of the data file). For small data sets you might be quite pleasantly surprised by how well stack files can accomplish what you need in a simpler form. Of course we can use them, but we must expect to do a bit of work. In this case, either delete stack or close stack when you're finished with it, and whatever you do to indicate a file lock. Of course. Or with my proposed change, no code is needed at all for either desired circumstance: Just leave things alone to get what you're looking for, or I can set a property to get what I'm looking for. I'm not sure what normal means in this context. I think a lot of single-user apps are abnormal. :) You've been looking at my work again. :-) I wish I've seen more. Whenever I prowl around in libURL my jaw drops with the outstanding competency of what's written there, and when I use it my appreciation grows even more for its ease and robustness. -- 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
Re: Rules governing stack purging
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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Rules governing stack purging
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
Re: Rules governing stack purging
Richard, The documentation states that delete stack will actually delete the stack if applied to a sub stack - but does not actually delete the stack if applied to a main stack - this seems to be true. I'm not sure if the delete stack file command is doing anything. PL ___ 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
Re: Rules governing stack purging
On 30 Oct 2006, at 16: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? Perhaps not entirely, but I may have misunderstood your question. If you access a stack without using open/go/toplevel/etc., for example by doing this: get the cMyProperty of stack /Users/dave/myStack.rev then my understanding is that the stack will remain in memory until you delete it from memory, even it has the destroyStack set to true. Subsequents gets on the same stack will come from the memory version. Although I guess that would only make a difference if another app was saving the stack to disk while you had the stack in memory. 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 think that's the case. 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? You can safely use delete stack with mainstacks. I typically use something like this when saving data to a data only stack. set the cMyData of stack /Users/dave/myStack.rev to tData save stack /Users/dave/myStack.rev delete stack /Users/dave/myStack.rev 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? By other kind, do you mean substack. If so, I'm not sure as I've never used a substack as a data stack. However, I'd try deleting the substack's mainstack, and see if that works. But I'd *never* delete the substack. Any help?? Cheers Dave ___ 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
Re: Rules governing stack purging
Hi Richard, It seems to be correct to assume that getting a property from a stack whose destroystack property has been set to true does not cause that stack to stay in memory. I tried the following in the message box: answer file ; get the bla of stack it; put the openstacks and the selected stack file is not among the lines of the openstacks. (Dave, I think your reply in this matter is not correct, unless I overlook something). If you delete a stack, you completely remove it from memory. If the stack happens to be a substack of a mainstack, that substack is also deleted. This means that you can only safely delete mainstacks. As far as I know, you cannot purge a substack without either purging the mainstack or actually deleting the substack. Best, Mark -- Economy-x-Talk Consultancy and Software Engineering http://economy-x-talk.com http://www.salery.biz Get your store on-line within minutes with Salery Web Store software. Download at http://www.salery.biz Op 30-okt-2006, om 17:48 heeft Richard Gaskin het volgende geschreven: 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 ___ 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
Re: Rules governing stack purging
Mark Schonewille wrote: Hi Richard, It seems to be correct to assume that getting a property from a stack whose destroystack property has been set to true does not cause that stack to stay in memory. I tried the following in the message box: answer file ; get the bla of stack it; put the openstacks and the selected stack file is not among the lines of the openstacks. (Dave, I think your reply in this matter is not correct, unless I overlook something). The stack will not be in the openstacks, because technically it isn't open. It isn't listed in the the mainstacks either. The engine opens it silently and doesn't pass any messages to it when you are just accessing a property. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.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
Re: Rules governing stack purging
On 30 Oct 2006, at 16:48, Richard Gaskin wrote: 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. To foil the possible caching, you could open another stack that has the same stack name but different filename, which would replace the first stack. This would allow you to test for the actual removal of the old data. Example: /users/me/documents/dataStorage.rev [stack name 'cacheData'] /users/me/documents/dataStorageNull.rev [stack name 'cacheData'] put the cpInventor of stack /users/me/documents/dataStorage.rev is REAL put the cpInventor of stack /users/me/documents/dataStorageNull.rev is NULL Hope this helps get you to your final solution. Jim Ault Las Vegas ___ 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
Re: Rules governing stack purging
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
Re: Rules governing stack purging
On 30 Oct 2006, at 17:26, Mark Schonewille wrote: It seems to be correct to assume that getting a property from a stack whose destroystack property has been set to true does not cause that stack to stay in memory. I tried the following in the message box: answer file ; get the bla of stack it; put the openstacks and the selected stack file is not among the lines of the openstacks. (Dave, I think your reply in this matter is not correct, unless I overlook something). If I try this (using the short name and not the file name): on mouseUp put /Users/dave/Desktop/proptest.rev into tStackFile put the myProp of stack tStackFile into field 1 put the short name of stack tStackFile into tShortname put cr there is a stack tShortname after field 1 delete stack tStackFile put cr there is a stack tShortname after field 1 end mouseUp The first there is a stack tShortname return true, and the second returns false. So it would seem to be still in memory until you delete it. I think in some way that this is logical, as how would the engine know when to release it. I think Jacque's comment that only stacks that have been through the normal open procedure appear in the openStacks is correct. Cheers Dave ___ 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
Re: Rules governing stack purging
On 30 Oct 2006, at 18:28, J. Landman Gay wrote: The stack will not be in the openstacks, because technically it isn't open. It isn't listed in the the mainstacks either. The engine opens it silently and doesn't pass any messages to it when you are just accessing a property. Jacque, are you sure it isn't in the mainstacks. I modified teh script I just posted as follows: on mouseUp put /Users/dave/Desktop/proptest.rev into tStackFile put the myProp of stack tStackFile into field 1 put the short name of stack tStackFile into tShortname put cr (there is a stack tShortname) after field 1 put cr (tShortname is among the lines of the mainstacks) after field 1 delete stack tStackFile put cr (there is a stack tShortname) after field 1 put cr (tShortname is among the lines of the mainstacks) after field 1 end mouseUp I now get true true false false And I seem to remember that Rev uses the mainstacks somewhere to list all stacks in memory. Cheers Dave ___ 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
Re: Rules governing stack purging
Just to second what Dave says. For many of my apps where I 'load a document', I 'go' the stack, copy the necessary data from it, then 'delete stack xyz' in order to permanently remove it from memory. I don't like leaving inv data stacks in memory for a number of reasons: 1) larger memory footprint; 2) can get confusing esp with Save and Save As. ___ 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
Re: Rules governing stack purging
That works here. Having accessed a cp in the stack in question, it shows up in the mainStacks, but not the openStacks. However, close stack blah seems to purge it from memory just fine. Best, Mark On 30 Oct 2006, at 20:07, Dave Cragg wrote: On 30 Oct 2006, at 18:28, J. Landman Gay wrote: The stack will not be in the openstacks, because technically it isn't open. It isn't listed in the the mainstacks either. The engine opens it silently and doesn't pass any messages to it when you are just accessing a property. Jacque, are you sure it isn't in the mainstacks. I modified teh script I just posted as follows: on mouseUp put /Users/dave/Desktop/proptest.rev into tStackFile put the myProp of stack tStackFile into field 1 put the short name of stack tStackFile into tShortname put cr (there is a stack tShortname) after field 1 put cr (tShortname is among the lines of the mainstacks) after field 1 delete stack tStackFile put cr (there is a stack tShortname) after field 1 put cr (tShortname is among the lines of the mainstacks) after field 1 end mouseUp I now get true true false false And I seem to remember that Rev uses the mainstacks somewhere to list all stacks in memory. Cheers Dave ___ 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
Re: Rules governing stack purging
Chipp, If you delete the stack, do you need to close it? In other words, does go read delete suffice? Paul Looney ___ 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
Re: Rules governing stack purging
Dave Cragg wrote: On 30 Oct 2006, at 18:28, J. Landman Gay wrote: The stack will not be in the openstacks, because technically it isn't open. It isn't listed in the the mainstacks either. The engine opens it silently and doesn't pass any messages to it when you are just accessing a property. Jacque, are you sure it isn't in the mainstacks. I modified teh script I just posted as follows: on mouseUp put /Users/dave/Desktop/proptest.rev into tStackFile put the myProp of stack tStackFile into field 1 put the short name of stack tStackFile into tShortname put cr (there is a stack tShortname) after field 1 put cr (tShortname is among the lines of the mainstacks) after field 1 delete stack tStackFile put cr (there is a stack tShortname) after field 1 put cr (tShortname is among the lines of the mainstacks) after field 1 end mouseUp I now get true true false false And I seem to remember that Rev uses the mainstacks somewhere to list all stacks in memory. You're right, I only did a very quick test and I did expect to see it in the mainstacks. It wasn't in there, but your test is better than the one I did. And when I run yours, I get the same results. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.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
Re: Rules governing stack purging
So, you two are right and I was wrong :-) Thanks for clarifying this. Mark -- Economy-x-Talk Consultancy and Software Engineering http://economy-x-talk.com http://www.salery.biz Get your store on-line within minutes with Salery Web Store software. Download at http://www.salery.biz Op 30-okt-2006, om 20:36 heeft J. Landman Gay het volgende geschreven: Dave Cragg wrote: On 30 Oct 2006, at 18:28, J. Landman Gay wrote: The stack will not be in the openstacks, because technically it isn't open. It isn't listed in the the mainstacks either. The engine opens it silently and doesn't pass any messages to it when you are just accessing a property. Jacque, are you sure it isn't in the mainstacks. I modified teh script I just posted as follows: snip And I seem to remember that Rev uses the mainstacks somewhere to list all stacks in memory. You're right, I only did a very quick test and I did expect to see it in the mainstacks. It wasn't in there, but your test is better than the one I did. And when I run yours, I get the same results. ___ 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
Re: Rules governing stack purging
Thank you all for the verification. Contrary to many people's notions (including mine), it seems that merely reading a property of a stack will cause it to remain in memory -- even when that stack has its destroyStack set to false. I had been working under the presumption that when a property is read from a stack that hasn't been opened, the engine merely reads the stack, extracts the property contents, disposes of the stack and returns the property contents to me. Apparently that isn't how it works, even when a stack's destroyStack is true. So while we have a workaround using this odd application of the delete stack command which doesn't actually delete the stack but merely purges it, I'm wondering if we should consider this behavior a bug, as least as far as stack with their destroyStack set to true are concerned? Also, would it be worth pursuing a request for a purge stack command so newcomers don't get the impression that delete stack will actually delete their stack? -- 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
Re: Rules governing stack purging
On 30 Oct 2006, at 20:23, Richard Gaskin wrote: So while we have a workaround using this odd application of the delete stack command which doesn't actually delete the stack but merely purges it, I'm wondering if we should consider this behavior a bug, as least as far as stack with their destroyStack set to true are concerned? I think the current behavior can be seen as useful, although I agree it might seem odd in some ways. Say I want to do this: set the cProp of stack C:/myStack.rev save stack C:/myStack.rev If the stack is automatically purged after setting the prop, will the change be saved? By current logic, presumably not. And what will get saved in the second statement? Also, would it be worth pursuing a request for a purge stack command so newcomers don't get the impression that delete stack will actually delete their stack? You've only been asking for that for 8 years, Richard. Have patience! But yes, I think it would be good. However, I imagine it's not just a case of creating a synonym for delete, as the behavior when applied to substacks would be different. Cheers Dave ___ 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
Re: Rules governing stack purging
On 30 Oct 2006, at 21:15, Dave Cragg wrote: Say I want to do this: set the cProp of stack C:/myStack.rev save stack C:/myStack.rev Should be: set the cProp of stack C:/myStack.rev to somedata save stack C:/myStack.rev Also, I just remembered something (third time this week, must be the new pills). Aren't unused stacks purged from memory by the engine when it needs to reclaim memory? I think I'm referring to stacks without the destryStack set, but which have been closed. I seem to recall reading this somewhere, either in the old Metacard docs, or the MC mailing list from long ago. If it's true, I wonder if it applies to unopened stacks in memory too. Does anyone know? Cheers Dave ___ 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
Re: Rules governing stack purging
Dave Cragg wrote: On 30 Oct 2006, at 20:23, Richard Gaskin wrote: So while we have a workaround using this odd application of the delete stack command which doesn't actually delete the stack but merely purges it, I'm wondering if we should consider this behavior a bug, as least as far as stack with their destroyStack set to true are concerned? I think the current behavior can be seen as useful, although I agree it might seem odd in some ways. Say I want to do this: set the cProp of stack C:/myStack.rev save stack C:/myStack.rev If the stack is automatically purged after setting the prop, will the change be saved? By current logic, presumably not. And what will get saved in the second statement? Consider your subsequent post: I just remembered something (third time this week, must be the new pills). Aren't unused stacks purged from memory by the engine when it needs to reclaim memory? I think I'm referring to stacks without the destryStack set, but which have been closed. I seem to recall reading this somewhere, either in the old Metacard docs, or the MC mailing list from long ago. If it's true, I wonder if it applies to unopened stacks in memory too. This implies the engine introduces a sometimes rule (sometime it does one thing, sometimes something else), which is generally bad news. So to answer your question, I would suggest that saving might be limited to stacks which have been opened with the open or go command, provided the stack has its destroyStack set to true. If a stack has its destroyStack set to false, the current behavior seems somewhat acceptable (once the sometimes part is resolved). Also, would it be worth pursuing a request for a purge stack command so newcomers don't get the impression that delete stack will actually delete their stack? You've only been asking for that for 8 years, Richard. Have patience! But yes, I think it would be good. However, I imagine it's not just a case of creating a synonym for delete, as the behavior when applied to substacks would be different. Actually, my original request was for a related change, depricating the destroyStack property in favor of something less alarming: http://support.runrev.com/bugdatabase/show_bug.cgi?id=1072 This request is for a command, which I've just added to BZ: http://support.runrev.com/bugdatabase/show_bug.cgi?id=3932 -- 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
