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

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to