Re: Deleting stacks on the fly

[panagiotis merakos via use-livecode]

Hi Brahmanathaswami,

What happens if you set the acceleratedRendering of the stack to false?

Best,
Panos
--

On Thu, Feb 16, 2017 at 9:08 PM, Sannyasin Brahmanathaswami via
use-livecode  wrote:

> @ Jacque: I don't think it is ram after all.
>
> FYI: on my Nexus 5 I have 1.8 GB RAM and our new app + All of Googles
> "widgets" that come preloaded take up a mere .8 GB and I have a full GB of
> RAM free. after proceeding (as we discussed off list with our team) to
> delete stacks when we move from one to another, so that only 1 or 2 are
> ever open in memory… I am pretty certain I'm not have a memory issue on
> this Android Device: but it still crashes.
>
> I took this to HQ… I guess you all know about plugging in your android
> phone and running ./adb logcat  and then pass that over to LC support.
>
> If you are interested  you can view it here:
>
> http://wiki.hindu.org/uploads/siva-siva-app_adb-log.txt  # 13MB file
>
> if you search
>
> Activity Manager: Process com.himalayan
>
> You will run into all the instances of
>
> ActivityManager: Process com.himalayanacademy.sivasiva (pid 25473) has died
>
> (crash/exit)
>
>
> There appear to be three different "flavors" of "exited due to signal
> (11)  in that log.  I won't detail them here as I don't grok the log well
> enough to talk about it.
>
> Hopefully HQ will figure it out… building from 8.1.3 (RC2)
>
> does 9 dp4 change the file format? Safe?  I could make back ups of
> course.  and test… but need to keep moving on content dev…
>
>  I have no recipe or rather, we do, but it seems harmless.
>
> we "Go" from one stack to another, then after 10 milliseconds, delete the
> first one
>
> here is the handler where the app exits on signal 11, you can  see where
> we were fiddling with
>
> 1) just closing it,
> 2) opening stack B and deleting stack A
> 3) Opening stack B and send a "Delete" stack A in 10 milliseconds.
>
> All three scenarios cause android to crash and we have *lots* of open RAM.
>
> command portal_GoStack stackName
>-- goes to the new stack
>-- closes the current stack
>-- safely ignores if we are alrady in the new stack
>
>put the short name of this stack into oStackName
>if oStackName = stackName then return oStackName
>
>go to stack stackName
>   --close stack oStackName
>-- test deleting the stacks to save on RAM
>   send "portal_RemoveStack oStackName" to me in 10 milliseconds
> --   delete stack oStackName
>return oStackName
> end portal_GoStack
>
> command portal_RemoveStack stackName
> if stackName <> "Siva-Siva-App" then
> delete stack stackName
> end if
> end portal_RemoveStack
>
>
> # Works perfectly well on iOS
>
>
>
>
>
>
>
>
> Svasti Astu, Be Well
> Brahmanathaswami
>
> www.himalayanacademy.com
>
>
>
> On 2/14/17, 6:48 AM, "use-livecode on behalf of J. Landman Gay via
> use-livecode"  use-livecode@lists.runrev.com> wrote:
>
> I frequently delete stacks when memory is an issue, which is the
> problem
> with Swami's stack suite. I also create almost all new stacks with
> destroystack set to true for the same reason.
>
>
>
> ___
> 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: Deleting stacks on the fly

[Sannyasin Brahmanathaswami via use-livecode]

@ Jacque: I don't think it is ram after all.

FYI: on my Nexus 5 I have 1.8 GB RAM and our new app + All of Googles "widgets" 
that come preloaded take up a mere .8 GB and I have a full GB of RAM free. 
after proceeding (as we discussed off list with our team) to delete stacks when 
we move from one to another, so that only 1 or 2 are ever open in memory… I am 
pretty certain I'm not have a memory issue on this Android Device: but it still 
crashes.

I took this to HQ… I guess you all know about plugging in your android phone 
and running ./adb logcat  and then pass that over to LC support.

If you are interested  you can view it here:

http://wiki.hindu.org/uploads/siva-siva-app_adb-log.txt  # 13MB file

if you search 

Activity Manager: Process com.himalayan

You will run into all the instances of 

ActivityManager: Process com.himalayanacademy.sivasiva (pid 25473) has died

(crash/exit)


There appear to be three different "flavors" of "exited due to signal (11)  in 
that log.  I won't detail them here as I don't grok the log well enough to talk 
about it. 

Hopefully HQ will figure it out… building from 8.1.3 (RC2)

does 9 dp4 change the file format? Safe?  I could make back ups of course.  and 
test… but need to keep moving on content dev… 

 I have no recipe or rather, we do, but it seems harmless.

we "Go" from one stack to another, then after 10 milliseconds, delete the first 
one

here is the handler where the app exits on signal 11, you can  see where we 
were fiddling with 

1) just closing it, 
2) opening stack B and deleting stack A
3) Opening stack B and send a "Delete" stack A in 10 milliseconds.

All three scenarios cause android to crash and we have *lots* of open RAM. 

command portal_GoStack stackName
   -- goes to the new stack
   -- closes the current stack
   -- safely ignores if we are alrady in the new stack
   
   put the short name of this stack into oStackName
   if oStackName = stackName then return oStackName
   
   go to stack stackName
  --close stack oStackName
   -- test deleting the stacks to save on RAM
  send "portal_RemoveStack oStackName" to me in 10 milliseconds  
--   delete stack oStackName
   return oStackName
end portal_GoStack

command portal_RemoveStack stackName
if stackName <> "Siva-Siva-App" then
delete stack stackName
end if
end portal_RemoveStack


# Works perfectly well on iOS








Svasti Astu, Be Well 
Brahmanathaswami

www.himalayanacademy.com

 

On 2/14/17, 6:48 AM, "use-livecode on behalf of J. Landman Gay via 
use-livecode"  wrote:

I frequently delete stacks when memory is an issue, which is the problem 
with Swami's stack suite. I also create almost all new stacks with 
destroystack set to true for the same reason.



___
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 on the fly

[J. Landman Gay via use-livecode]

On 2/14/17 3:38 PM, Richard Gaskin via use-livecode wrote:

J. Landman Gay wrote:


My other project is crashing on Android the same way. It also has heavy
server/internet use. I'm starting to think that's where the problem lies.


I wonder if that may be related to some of the leaks closed recently.



Would be nice, but it happens in 9.0dp4 too. :( My stack is in the QCC, 
maybe they can figure it out. We have a repeatable recipe.


--
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 on the fly

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:


My other project is crashing on Android the same way. It also has heavy
server/internet use. I'm starting to think that's where the problem lies.


I wonder if that may be related to some of the leaks closed recently.

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

Re: Deleting stacks on the fly

[J. Landman Gay via use-livecode]

BTW, we're not talking about creating and deleting new stacks on the fly, 
we mean the "delete stack" command that removes an open stack from RAM.

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



On February 14, 2017 10:51:06 AM "J. Landman Gay via use-livecode" 
<use-livecode@lists.runrev.com> wrote:



I frequently delete stacks when memory is an issue, which is the problem
with Swami's stack suite. I also create almost all new stacks with
destroystack set to true for the same reason.

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



On February 14, 2017 9:44:36 AM Bob Sneidar via use-livecode
<use-livecode@lists.runrev.com> wrote:


Is there any reason to delete the stack? If not, don't. Clearly any CtoD
should be investigated, but I have never seen why an app would be designed
to create and delete stacks when all you have to do is show and hide
existing ones.

Bob S



On Feb 13, 2017, at 22:00 , Sannyasin Brahmanathaswami via use-livecode
<use-livecode@lists.runrev.com> wrote:

   This works if we just use "close stack oStackName"

   but if I change this to "delete stack oStackName"



___
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: Deleting stacks on the fly

[J. Landman Gay via use-livecode]

I frequently delete stacks when memory is an issue, which is the problem 
with Swami's stack suite. I also create almost all new stacks with 
destroystack set to true for the same reason.


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



On February 14, 2017 9:44:36 AM Bob Sneidar via use-livecode 
 wrote:


Is there any reason to delete the stack? If not, don't. Clearly any CtoD 
should be investigated, but I have never seen why an app would be designed 
to create and delete stacks when all you have to do is show and hide 
existing ones.


Bob S


On Feb 13, 2017, at 22:00 , Sannyasin Brahmanathaswami via use-livecode 
 wrote:


   This works if we just use "close stack oStackName"

   but if I change this to "delete stack oStackName"



___
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: Deleting stacks on the fly

[Bob Sneidar via use-livecode]

Is there any reason to delete the stack? If not, don't. Clearly any CtoD should 
be investigated, but I have never seen why an app would be designed to create 
and delete stacks when all you have to do is show and hide existing ones. 

Bob S


> On Feb 13, 2017, at 22:00 , Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
>This works if we just use "close stack oStackName"
> 
>but if I change this to "delete stack oStackName"


___
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 on the fly

[J. Landman Gay via use-livecode]

On 2/14/17 12:00 AM, Sannyasin Brahmanathaswami via use-livecode wrote:

Deleting stacks isn't helping. My Nexus 5 has 1 GB free RAM even with
all of Google's widgets and my app open and going from Stack B back
to stack A then deleting StackcB in 10 milliseconds  is "nothing" in
terms of memory requirement, but crashes in Android every time…


My other project is crashing on Android the same way. It also has heavy 
server/internet use. I'm starting to think that's where the problem lies.


--
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 on the fly

[Sannyasin Brahmanathaswami via use-livecode]

FWIW, tested on an android device with plenty of memory

Deleting stacks isn't helping. My Nexus 5 has 1 GB free RAM even with all of 
Google's widgets and my app open and going from Stack B back to stack A then 
deleting StackcB in 10 milliseconds  is "nothing" in terms of memory 
requirement, but crashes in Android every time… 

I have a report in to HQ…

 

On 2/11/17, 8:38 AM, "use-livecode on behalf of Sannyasin Brahmanathaswami via 
use-livecode"  wrote:

I'm trying to optimize for minimal RAM usage on mobile. The app is modular 
with many stacks that are opened from the mainstack.

I had this before in a global library:

command portal_GoStack stackName
-- goes to the new stack
-- closes the current stack # But we want to delete it to clear RAM
-- safely ignores if we are alrady in the new stack
put the short name of this stack into oStackName
if oStackName = stackName then return oStackName
go to stack stackName
--close stack oStackName
-- test deleting the stacks to save on RAM
delete stack oStackName
return oStackName
end portal_GoStack

This is called from a button on a navigation bar of the stack we want to 
close and delete, as it opens a different stack.

This works if we just use "close stack oStackName"

but if I change this to "delete stack oStackName"

we get an error: stack "lib_SivaSivaPortal": execution error at line n/a 
(Object: stack locked, or object's script is executing) near "widget 
"go-home-portal" of group "homeScreensBottomNav" of card "images-quotes" of 
stack 
"/Users/Brahmanathaswami/Documents/_Siva-Siva-App/modules/gems/gems.livecode""

Obviously this means that the stack "gem.livecode" which has the button 
which is trying to "navigate" back to the home/main stack, cannot be deleted 
because the button script that calls the library handler is considered to be 
executing.

Closing it first before deleting does not help.

so I tried using "send in 10 milliseconds"  And this *does* work.. I'm just 
trying to see if this is best practice. both stacks will occupy RAM briefly, 
but  there is no other way that I know of to avoid this without a "flash" of 
some empty screen.

command portal_GoStack stackName
-- goes to the new stack
-- closes the current stack
-- safely ignores if we are alrady in the new stack
put the short name of this stack into oStackName
if oStackName = stackName then return oStackName
go to stack stackName
send "removeStack oStackName" to me in 10 milliseconds
return oStackName
end portal_GoStack

command removeStack stackName
delete stack stackName
end removeStack


Stack A opens
Stack B opens on top
Stack B want to close itself, be deleted (removed from memory) and open 
stack A

Anyone has gone through this loop already and discovered best practices to 
accomplish this?

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


___
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 on the fly

[Sannyasin Brahmanathaswami via use-livecode]

I'm trying to optimize for minimal RAM usage on mobile. The app is modular with 
many stacks that are opened from the mainstack.

I had this before in a global library:

command portal_GoStack stackName
-- goes to the new stack
-- closes the current stack # But we want to delete it to clear RAM
-- safely ignores if we are alrady in the new stack
put the short name of this stack into oStackName
if oStackName = stackName then return oStackName
go to stack stackName
--close stack oStackName
-- test deleting the stacks to save on RAM
delete stack oStackName
return oStackName
end portal_GoStack

This is called from a button on a navigation bar of the stack we want to close 
and delete, as it opens a different stack.

This works if we just use "close stack oStackName"

but if I change this to "delete stack oStackName"

we get an error: stack "lib_SivaSivaPortal": execution error at line n/a 
(Object: stack locked, or object's script is executing) near "widget 
"go-home-portal" of group "homeScreensBottomNav" of card "images-quotes" of 
stack 
"/Users/Brahmanathaswami/Documents/_Siva-Siva-App/modules/gems/gems.livecode""

Obviously this means that the stack "gem.livecode" which has the button which 
is trying to "navigate" back to the home/main stack, cannot be deleted because 
the button script that calls the library handler is considered to be executing.

Closing it first before deleting does not help.

so I tried using "send in 10 milliseconds"  And this *does* work.. I'm just 
trying to see if this is best practice. both stacks will occupy RAM briefly, 
but  there is no other way that I know of to avoid this without a "flash" of 
some empty screen.

command portal_GoStack stackName
-- goes to the new stack
-- closes the current stack
-- safely ignores if we are alrady in the new stack
put the short name of this stack into oStackName
if oStackName = stackName then return oStackName
go to stack stackName
send "removeStack oStackName" to me in 10 milliseconds
return oStackName
end portal_GoStack

command removeStack stackName
delete stack stackName
end removeStack


Stack A opens
Stack B opens on top
Stack B want to close itself, be deleted (removed from memory) and open stack A

Anyone has gone through this loop already and discovered best practices to 
accomplish this?

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