Re: How to ensure that 'close stack' destroys the stack in RAM?

[Dr. Hawkins]

On Mon, Oct 17, 2016 at 12:14 PM, J. Landman Gay 
wrote:

> Is the stacks destroyStack property set to true? If not, just closing it
> isn't enough. Also, if it's a substack, it won't ever be removed as long as
> its mainstack is open.


I even tried setting every destroy property I could locate, and the
behavior was unchanged.

They are all now main stacks, so that I don't have an 11mb file every time
I need a development checkpoint (2mb is bad enough, but I'll stop before my
rant on the 21s century and usable revision control, patch, etch gets into
gear . . .)



-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How to ensure that 'close stack' destroys the stack in RAM?

[J. Landman Gay]

On 10/17/16 11:35 AM, Dr. Hawkins wrote:

the application browser shows the file as a loaded
main stack but clicking to open it causes it to disappear from that pane.


I don't think this is related to the problem, it's a bug in the App 
Browser that's been there forever. I'm so used to it that I don't even 
think about it any more, and I sometimes click on the stack I know is 
removed just to get it out of the list. There's a tiny "refresh" icon in 
the lower right corner of the stack list pane that does the same thing.



I also see that when I have stack mystic of stack.a.livecode loaded, then
save it as stack.b.livecode, and even ad an explicit close for the old
filename, that it tends to lurk somewhere, and give the "what do you want
to do with  stack.b.ivecode before loading stack.a.livecode" when a should
be gone.


Is the stacks destroyStack property set to true? If not, just closing it 
isn't enough. Also, if it's a substack, it won't ever be removed as long 
as its mainstack is open.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How to ensure that 'close stack' destroys the stack in RAM?

[J. Landman Gay]

On 10/17/16 5:39 AM, Mark Waddingham wrote:

This isn't in fact a bug, just a subtle interaction with the stackFiles
property of your 'Master' stack.

The stackFiles property maps names of stacks to filenames - it basically
means that when the engine resolves a chunk reference 'stack ', if
there is no stack in memory with the name , then it will look
through the stackFiles property of the stacks in memory to try and
resolve it (starting with the stack of the script being executed).
Furthermore, it resolves things relative to the path to the stack
containing the stackFile line.

So, if you have a line 'DataStack -> DataStack.livecode' in the
stackFiles, and if there is a DataStack.livecode file next to the stack
containing that stackFiles line; a reference 'stack DataStack' will
*always* resolve and load the stack.


In my case, the issue happens in the IDE instead of a standalone, and 
there are no stackfiles set up anywhere. It's likely I'm doing something 
in the scripts that causes the stacks to remain in memory, but the 
scripts used to work in LC 6 and stopped working in LC 7.


But it isn't a huge issue for us, and providing you with a test suite 
would mean sending you a mountain of files...the stacks are built and/or 
updated from hundreds of text and image files on disk. But I'll be happy 
to do that if you like. :)


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How to ensure that 'close stack' destroys the stack in RAM?

[Dr. Hawkins]

On Mon, Oct 17, 2016 at 3:39 AM, Mark Waddingham  wrote:

> The stackFiles property maps names of stacks to filenames - it basically
> means that when the engine resolves a chunk reference 'stack ', if
> there is no stack in memory with the name , then it will look through
> the stackFiles property of the stacks in memory to try and resolve it
> (starting with the stack of the script being executed). Furthermore, it
> resolves things relative to the path to the stack containing the stackFile
> line.


I think that I've finally figured out what happens in a sequence in 7.  My
main stack uses stored properties to load other stacks.  As near as I can
tell, a file didn't exist, but the director for it did..  The result for
this one of many is that the application browser shows the file as a loaded
main stack but clicking to open it causes it to disappear from that pane.

It's a rarely used stack so it took a long time to notice and gives me no
warning either that the load failed to succeed or that there is no stack as
I click.

I also see that when I have stack mystic of stack.a.livecode loaded, then
save it as stack.b.livecode, and even ad an explicit close for the old
filename, that it tends to lurk somewhere, and give the "what do you want
to do with  stack.b.ivecode before loading stack.a.livecode" when a should
be gone.

The only solution I've found is to quit and restart livecode



-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How to ensure that 'close stack' destroys the stack in RAM?

[Bob Sneidar]

Perhaps the rule of thumb is never use two stacks with the same name in the 
same project. You may want to give the template stack a different name, then 
store the name of whichever stack you want to work with in a variable, then 
update all references to that stack to use the variable. 

Bob S


> On Oct 17, 2016, at 07:07 , Graham Samuel  wrote:
> 
> Thanks Mark for that intervention. In the way this is a gotcha that should be 
> better documented, since one **must** populate the stackFiles property as a 
> side effect of including the stacks in the project in its standalone settings 
> - the information in the list of stacks to be included is exactly the 
> contents of the stackFiles property, at least initially. If say this contains 
> (as mine does) a template stack that’s got to go into the resources folder of 
> the standalone, then I have no choice but to tell the standalone builder 
> about it. To achieve what I want - the ability to close a stack which is in 
> effect a clone of this template and remove it from RAM, just as the IDE is 
> able to do - I will have to delete the reference to to the template stack in 
> the stackFiles property, and rely on the program’s own knowledge of where the 
> template is stored. I’m slightly surprised that this hasn’t come up before. 
> It occurs to me that there may be a solution in renaming the template stack 
> as soon as it is cloned, but I haven’t tried it.
> 
> Finally I should say that the Dictionary entry for ‘the stackFiles’ is a bit 
> inadequate, as it doesn’t mention the interaction between the standalone 
> builder and the property. Maybe this amounts to a bug, if only in the 
> documentation!
> 
> Thanks again
> 
> Graham
> 
> 
>> On 17 Oct 2016, at 12:39, Mark Waddingham  wrote:
>> 
>> On 2016-10-17 11:15, Graham Samuel wrote:
>>> Thanks Jacque - wise words as always. The idea that the delete would
>>> work depending on whether the stack was newly created had not occurred
>>> to me, but seems like a good reason why my simplified tests didn’t
>>> show the problem. I will try again to create a simple demo, and
>>> hopefully I can file a bug report.
>> 
>> Thanks for the bug report 
>> (http://quality.livecode.com/show_bug.cgi?id=18612) - I was a bit puzzled 
>> about the situation you and Jacque described until I saw your code.
>> 
>> This isn't in fact a bug, just a subtle interaction with the stackFiles 
>> property of your 'Master' stack.
>> 
>> The stackFiles property maps names of stacks to filenames - it basically 
>> means that when the engine resolves a chunk reference 'stack ', if 
>> there is no stack in memory with the name , then it will look through 
>> the stackFiles property of the stacks in memory to try and resolve it 
>> (starting with the stack of the script being executed). Furthermore, it 
>> resolves things relative to the path to the stack containing the stackFile 
>> line.
>> 
>> So, if you have a line 'DataStack -> DataStack.livecode' in the stackFiles, 
>> and if there is a DataStack.livecode file next to the stack containing that 
>> stackFiles line; a reference 'stack DataStack' will *always* resolve and 
>> load the stack.
>> 
>> Essentially, asking whether 'stack DataStack' or not exists doesn't work, 
>> because referencing the stack causes it to.
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> -- 
>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How to ensure that 'close stack' destroys the stack in RAM?

[Graham Samuel]

Thanks Mark for that intervention. In the way this is a gotcha that should be 
better documented, since one **must** populate the stackFiles property as a 
side effect of including the stacks in the project in its standalone settings - 
the information in the list of stacks to be included is exactly the contents of 
the stackFiles property, at least initially. If say this contains (as mine 
does) a template stack that’s got to go into the resources folder of the 
standalone, then I have no choice but to tell the standalone builder about it. 
To achieve what I want - the ability to close a stack which is in effect a 
clone of this template and remove it from RAM, just as the IDE is able to do - 
I will have to delete the reference to to the template stack in the stackFiles 
property, and rely on the program’s own knowledge of where the template is 
stored. I’m slightly surprised that this hasn’t come up before. It occurs to me 
that there may be a solution in renaming the template stack as soon as it is 
cloned, but I haven’t tried it.

Finally I should say that the Dictionary entry for ‘the stackFiles’ is a bit 
inadequate, as it doesn’t mention the interaction between the standalone 
builder and the property. Maybe this amounts to a bug, if only in the 
documentation!

Thanks again

Graham


> On 17 Oct 2016, at 12:39, Mark Waddingham  wrote:
> 
> On 2016-10-17 11:15, Graham Samuel wrote:
>> Thanks Jacque - wise words as always. The idea that the delete would
>> work depending on whether the stack was newly created had not occurred
>> to me, but seems like a good reason why my simplified tests didn’t
>> show the problem. I will try again to create a simple demo, and
>> hopefully I can file a bug report.
> 
> Thanks for the bug report (http://quality.livecode.com/show_bug.cgi?id=18612) 
> - I was a bit puzzled about the situation you and Jacque described until I 
> saw your code.
> 
> This isn't in fact a bug, just a subtle interaction with the stackFiles 
> property of your 'Master' stack.
> 
> The stackFiles property maps names of stacks to filenames - it basically 
> means that when the engine resolves a chunk reference 'stack ', if 
> there is no stack in memory with the name , then it will look through 
> the stackFiles property of the stacks in memory to try and resolve it 
> (starting with the stack of the script being executed). Furthermore, it 
> resolves things relative to the path to the stack containing the stackFile 
> line.
> 
> So, if you have a line 'DataStack -> DataStack.livecode' in the stackFiles, 
> and if there is a DataStack.livecode file next to the stack containing that 
> stackFiles line; a reference 'stack DataStack' will *always* resolve and load 
> the stack.
> 
> Essentially, asking whether 'stack DataStack' or not exists doesn't work, 
> because referencing the stack causes it to.
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How to ensure that 'close stack' destroys the stack in RAM?

[Mark Waddingham]

On 2016-10-17 11:15, Graham Samuel wrote:

Thanks Jacque - wise words as always. The idea that the delete would
work depending on whether the stack was newly created had not occurred
to me, but seems like a good reason why my simplified tests didn’t
show the problem. I will try again to create a simple demo, and
hopefully I can file a bug report.


Thanks for the bug report 
(http://quality.livecode.com/show_bug.cgi?id=18612) - I was a bit 
puzzled about the situation you and Jacque described until I saw your 
code.


This isn't in fact a bug, just a subtle interaction with the stackFiles 
property of your 'Master' stack.


The stackFiles property maps names of stacks to filenames - it basically 
means that when the engine resolves a chunk reference 'stack ', if 
there is no stack in memory with the name , then it will look 
through the stackFiles property of the stacks in memory to try and 
resolve it (starting with the stack of the script being executed). 
Furthermore, it resolves things relative to the path to the stack 
containing the stackFile line.


So, if you have a line 'DataStack -> DataStack.livecode' in the 
stackFiles, and if there is a DataStack.livecode file next to the stack 
containing that stackFiles line; a reference 'stack DataStack' will 
*always* resolve and load the stack.


Essentially, asking whether 'stack DataStack' or not exists doesn't 
work, because referencing the stack causes it to.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How to ensure that 'close stack' destroys the stack in RAM?

[Graham Samuel]

Thanks Jacque - wise words as always. The idea that the delete would work 
depending on whether the stack was newly created had not occurred to me, but 
seems like a good reason why my simplified tests didn’t show the problem. I 
will try again to create a simple demo, and hopefully I can file a bug report.

Graham

> On 17 Oct 2016, at 06:06, J. Landman Gay  wrote:
> 
> I don't have an answer for you, but the problem may be related to something I 
> noticed when LC 7 was released. I have automated scripts that create and/or 
> update a series of stacks. When changes are completed to each stack, the 
> script does this:
> 
> save stack x
> close stack x
> delete stack x
> 
> Prior to LC 7, the stacks would be removed from memory. In LC 7 and up, the 
> stack is closed and removed from RAM only if the stack was newly created 
> during that particular run. If the stack already existed on disk and was 
> opened and updated, it does what you describe -- it closes but remains in 
> RAM. (It remains listed in the App Browser, and "there is a stack x" returns 
> true.) The destroyStack property on all the stacks is always false, though 
> that shouldn't matter because an explicit command to delete the stack should 
> work regardless.
> 
> Since it isn't a big deal for my client we've been ignoring it. But maybe 
> that will give you a lead on how to pinpoint the problem. I suspect a bug in 
> there somewhere.
> 
> 
> On 10/16/16 10:47 AM, Graham Samuel wrote:
>> Using LC8.1.1 rc2, I’ve got a mainstack which I want to remove
>> entirely from my project before replacing it with a template stack of
>> the same name. The script to do this is in a library originating from
>> another mainstack. For the target stack I have set the ‘cantDelete’
>> to false, and the ‘destroyStack’ and ‘destroyWindow’ to true. If my
>> script just says
>> 
>> close stack “myStack”
>> 
>> then the stack window closes, but I think the stack is still in RAM -
>> at least an ‘exists’ test says so (it’s not clear from the dictionary
>> if ‘exists’ is supposed to work on stacks), and indeed the template
>> stack doesn’t replace the original. If I add another line
>> 
>> delete stack “myStack”
>> 
>> I get an error 370 (object: stack locked, or stack’s script is
>> executing). But it’s not locked. I don’t even know how to lock a
>> stack, unless it’s by setting its ‘cantDelete’ to true. There are no
>> ‘closeStack’ handlers in the target stack.
>> 
>> Attempts to turn this into a simple recipe have failed, but it’s a
>> real problem. What I want to do (I know I’ve asked before) is to
>> execute the same code as the IDE does for ‘close and remove from
>> memory’.
>> 
>> Any ideas welcome.
>> 
>> Graham ___ use-livecode
>> mailing list use-livecode@lists.runrev.com Please visit this url to
>> subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> 
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How to ensure that 'close stack' destroys the stack in RAM?

[J. Landman Gay]

I don't have an answer for you, but the problem may be related to 
something I noticed when LC 7 was released. I have automated scripts 
that create and/or update a series of stacks. When changes are completed 
to each stack, the script does this:


save stack x
close stack x
delete stack x

Prior to LC 7, the stacks would be removed from memory. In LC 7 and up, 
the stack is closed and removed from RAM only if the stack was newly 
created during that particular run. If the stack already existed on disk 
and was opened and updated, it does what you describe -- it closes but 
remains in RAM. (It remains listed in the App Browser, and "there is a 
stack x" returns true.) The destroyStack property on all the stacks is 
always false, though that shouldn't matter because an explicit command 
to delete the stack should work regardless.


Since it isn't a big deal for my client we've been ignoring it. But 
maybe that will give you a lead on how to pinpoint the problem. I 
suspect a bug in there somewhere.



On 10/16/16 10:47 AM, Graham Samuel wrote:

Using LC8.1.1 rc2, I’ve got a mainstack which I want to remove
entirely from my project before replacing it with a template stack of
the same name. The script to do this is in a library originating from
another mainstack. For the target stack I have set the ‘cantDelete’
to false, and the ‘destroyStack’ and ‘destroyWindow’ to true. If my
script just says

close stack “myStack”

then the stack window closes, but I think the stack is still in RAM -
at least an ‘exists’ test says so (it’s not clear from the dictionary
if ‘exists’ is supposed to work on stacks), and indeed the template
stack doesn’t replace the original. If I add another line

delete stack “myStack”

I get an error 370 (object: stack locked, or stack’s script is
executing). But it’s not locked. I don’t even know how to lock a
stack, unless it’s by setting its ‘cantDelete’ to true. There are no
‘closeStack’ handlers in the target stack.

Attempts to turn this into a simple recipe have failed, but it’s a
real problem. What I want to do (I know I’ve asked before) is to
execute the same code as the IDE does for ‘close and remove from
memory’.

Any ideas welcome.

Graham ___ use-livecode
mailing list use-livecode@lists.runrev.com Please visit this url to
subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode