Re: "Deleting" Stacks in Memory - What About Behaviors?

[J. Landman Gay via use-livecode]

How would the engine know whether that behavior is used elsewhere, or will 
be needed in the stack that opens next? The easiest way to get the behavior 
you want, without any scripting, is to put the script in a button in the 
stack. Then when the stack is deleted, the behavior is gone.


If you're using script only stacks, it's not difficult to remove the script 
stack when you no longer need it.



On February 10, 2017 10:45:01 AM Sannyasin Brahmanathaswami via 
use-livecode  wrote:


When we delete a main stack, the main stack and all its substacks are 
removed from memory.


But if we delete a stack that has behaviors set from external 
*_behavior.livecodescript  stacks for controls in the "main" (parent?) 
stack, those behaviors are still in memory.


Does it make sense to file an enhancement request, to at least allow the 
dev to set a preference


__ Delete behavior stacks from memory when stack using them are deleted 
[YES/NO]



--
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: "Deleting" Stacks in Memory - What About Behaviors?

[Bob Sneidar via use-livecode]

I was thinking the same thing. I'm pretty sure that when an app for Windows 
uses DotNET Framework, it takes some time to initially load the framework, then 
the app can launch. Once the app is quit, I do not think it unloads DotNET 
Framework, because the next time I launch the app, the process is almost 
instantaneous. 

If more than one app is using your "framework" (behavior script only stack) 
then it doesn't make sense to purge it. Now if you want to maintain a system of 
registering and unregistering your apps with your framework, and purging the 
framework when the last app quits, that would make sense. 

I find that a lot of times in lieu of an enhancement request, the problem can 
really be handled by a little ingenuity on the part of the end developer. As I 
have said in the past, Livecode is less like raw materials and a full set of 
tools (C variants or Java) and more like a constructor set. All the different 
parts have been made, and we really put the parts together to make something 
useful, like a toy house for example. The logical conclusion to any approach to 
less granularity than necessary would result in opening the box of the 
constructor set and finding inside walls and a roof. But what if I didn't want 
to make a house?? 

I guess I'm saying that it's more beneficial to keep as much flexibility in the 
hands of the developer as possible. It's up to us to detemine how best to put 
the parts together in a way that suits us. 

Bob S


> On Feb 10, 2017, at 09:48 , Richard Gaskin via use-livecode 
>  wrote:
> 
> > __ Delete behavior stacks from memory when stack using them are
> > deleted [YES/NO]
> 
> My vote: No.
> 
> Different stack, different purge.
> 
> I want to remain in control of when things get purged.


___
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: "Deleting" Stacks in Memory - What About Behaviors?

[Richard Gaskin via use-livecode]

Sannyasin Brahmanathaswami wrote:

> When we delete a main stack, the main stack and all its substacks are
> removed from memory.
>
> But if we delete a stack that has behaviors set from external
> *_behavior.livecodescript  stacks for controls in the "main"
> (parent?) stack, those behaviors are still in memory.
>
> Does it make sense to file an enhancement request, to at least allow
> the dev to set a preference
>
> __ Delete behavior stacks from memory when stack using them are
> deleted [YES/NO]

My vote: No.

Different stack, different purge.

I want to remain in control of when things get purged.

Imagine, for example, an app that uses multiple documents.  Once I've 
inited the stack containing behavior scripts, I'll want to allow the 
user to open and close any document stacks they like during the session. 
 If I lost control over then behaviors are purged, I'd have to add code 
to ensure the stack with the behaviors is properly set up each time a 
document is opened.


And as someone who does a lot of LiveCode training, I've come to 
appreciate that the fewer "sometimes" rules we have the better.


Right now we give the developer the freedom to manage their own stack 
purging (however wonky that syntax may currently be).


If we introduce a "sometimes" rule about if some other stack happens to 
have an object that had been used as a behavior, things get muddy quickly.




> This is in line with trying to manage memory usage on small devices.
>
> Yes, someone will no doubt respond "but they are so small why are you
> worried?"
>
> But small android phone with limited RAM, really do need help keeping
> the heap as low as possible.  I am just looking for all possible
> means to clear ram, then set a "policy" in app to do all possible
> house keeping along the way: set images to empty, delete stacks not
> in use are the main two "tricks" we need to have that are obvious;
>
> But that leaves libraries and behaviors that are not in use. So if we
> *could* clean them up… why not do it.  Some times 200K means the diff
> between running and crashing on these "weak" devices.
>
> Obviouslyl if one is using Libraries with Start Using, the intent is
> probably that these are serving as globally accessible handlers. But
> this is not the case with behaviors attached to controls in a stack
> that may be deleted. So does it not make sense they are treated the
> same way as sub-stacks when their "parent" stack is deleted?
>
> Before filing an enhancement request I want to check here with
> everyone. What do you think?

If you want to purge things, purge them.

But please don't purge my things. :)

And given the relatively low overhead of all but the longest of scripts, 
I wonder how much of a difference it'll make in your app.


Could there be something with images or other RAM-heavy elements that 
may benefit from reviewing first?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.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

"Deleting" Stacks in Memory - What About Behaviors?

[Sannyasin Brahmanathaswami via use-livecode]

When we delete a main stack, the main stack and all its substacks are removed 
from memory.

But if we delete a stack that has behaviors set from external 
*_behavior.livecodescript  stacks for controls in the "main" (parent?) stack, 
those behaviors are still in memory.

Does it make sense to file an enhancement request, to at least allow the dev to 
set a preference

__ Delete behavior stacks from memory when stack using them are deleted [YES/NO]

This is in line with trying to manage memory usage on small devices.

Yes, someone will no doubt respond "but they are so small why are you worried?"

But small android phone with limited RAM, really do need help keeping the heap 
as low as possible.  I am just looking for all possible means to clear ram, 
then set a "policy" in app to do all possible house keeping along the way: set 
images to empty, delete stacks not in use are the main two "tricks" we need to 
have that are obvious;

But that leaves libraries and behaviors that are not in use. So if we *could* 
clean them up… why not do it.  Some times 200K means the diff between running 
and crashing on these "weak" devices.

Obviouslyl if one is using Libraries with Start Using, the intent is probably 
that these are serving as globally accessible handlers. But this is not the 
case with behaviors attached to controls in a stack that may be deleted. So 
does it not make sense they are treated the same way as sub-stacks when their 
"parent" stack is deleted?

Before filing an enhancement request I want to check here with everyone. What 
do you think?

BR
___
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