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
