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 sta
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 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
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
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 whe
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 visibl
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,
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 memo
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 consistent
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 sta
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)
put the cp of stack 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
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
propert
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
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 b
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
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
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 G
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 th
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.
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 c
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.
B
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
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
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 thei
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
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-ok
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 prope
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 subscriptio
That works here. Having accessed a cp in the stack in question, it
shows up in the mainStacks, but not the openStacks.
However, 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 wil
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
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, a
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
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
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.
>>
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 o
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 sele
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 op
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
___
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
39 matches
Mail list logo
