Re: Stacks not removed from memory?
On 5/15/21 9:56 AM, Bob Sneidar via use-livecode wrote: I agree that when a handler refers to this stack, it should ALWAYS refer to the stack the script object belongs to. That would be a catasrophe when the handler is in a library or a backscript. I use "this stack" in those. It would be good to get some guidance though on how the engine determines which stack is "this stack." I don't usually have a problem with it, but once in a while it fools me. -- 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: Stacks not removed from memory?
This issue is so pervasive that I ended up converting all of my relative references to absolute ones. I wrote two handlers, getParentCard and getParentStack, so when I need absolute references I put getParentCard() into tParentCard and then use of tParentCard after any object I need to absolutely reference. I NEVER use this stack anymore. I agree that when a handler refers to this stack, it should ALWAYS refer to the stack the script object belongs to. Bob S > On May 14, 2021, at 12:49 PM, Marty Knapp via use-livecode > wrote: > > When you close a stack that has its destroyStack set to true, it should not > remain in memory. In my case it also seems to get stuck as the default stack. > Even if my preference stack did not remove from memory as it should, > specifically going to stack "XYZ" and setting it as the defaultStack, one > would expect "this stack" to be be "XYZ" but it is not. > > As mentioned I am now querying revLoadedStacks and manually deleting from > memory the preference stack and that seems to have taken care of it. But it > makes me nervous that the same issue may unexpectedly arise elsewhere in my > code. This is an app that has been working fine for years and this has not > been an issue till now. > > Marty > >> On May 14, 2021, at 12:35 PM, Richard Gaskin via use-livecode >> wrote: >> >> Thanks, Marty. >> >> I used to use stacks for preferences, but I found arrays to be simpler in >> addition to being slightly faster. >> >> But it seems the core of your issue isn't so much about LC's cache >> management as with object referencing with "this" - do I understand the >> issue correctly? >> >> -- >> Richard Gaskin >> Fourth World Systems >> >> >>> In my case it's not a name conflict. Lets say I have a main stack "XYZ" and >>> then I query a separate Preference stack: >>> put the cpCustomProperty of stack "full_path_to_pref_stack" into tPref >>> close stack "pref_stack" >>> (my preference stack has destroyStack set to true) >>> Now thinking that I'm back in my main stack "XYZ" I do something like: >>> put tPref into fld "123" of this stack >>> This worked fine for me for years. In LC 9.6.2 rc 5, it would fail most of >>> the time. Curious, I inserted code to find out what LC thought was "this >>> stack" only to discover that *sometimes* it's the preference stack that I >>> just closed. >>> Then after closing the preference stack, I tried "go stack "XYZ" and "set >>> the default stack to "XYZ" But "this stack" would still (most of the time) >>> report my supposedly closed preference stack. >>> So now I'm having to query for revLoadedStacks and if my preference stack >>> is listed then I delete it from memory. >>> I did file a bug report (#23194 ) but as it does not always happen I have >>> not provided a test stack. >>> Marty >> > > > ___ > 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: Stacks not removed from memory?
Richard: > Because if it's just the stack name conflict thang, > I'd rather we solve that at the root by being done > with that IDE-imposed limitation Yes, good idea. I would be happy if LC either: 1. Solves it at the root, per RG suggestion. 2. Fixes what they already have, in the IDE. Which way is better? I'd say #1 is superior. That's my ideal too. Truly fixing it is much better than putting on a field dressing. BUT... (!) What's the caveat? New LC code is usually buggy and glitchy. Some issues are solved quickly, others take many years, or never. Thus, unfortunately "#1" versus "#2" might not a real choice. Actual choice, if quality is desired: "#2" versus "#1 PLUS #2." It shouldn't work that way, but unfortunately it has, so far. Anyway, good idea! I would be happy if LC does either. Just do it well. Besides the more obvious name conflict issues, we also have SE sometimes becoming dis-associated from the control whose script is being edited. That one is pretty fun to keep people on their toes while coding! Also, it's pretty crazy when standalone mishaps embed LC stacks in user stacks, and then the IDE makes it a little bit more difficult to remove the offending substacks due to the name conflicts. Similar: With certain project organization habits, it can add to the mayhem when name conflicts join the new messages-on Standalone Builder dance. Purge dialogs galore! Easy enough to work around, but a robust SB process that doesn't conflict with itself would be a big boost for LC. > So many things can legitimately change the value of "this" > I generally prefer more explicit references. > Maybe with this apparent bug there's one more reason > I'm grateful to have adopted this habit. "This" habit? Which habit was that? (J/K) :) Thanks for promoting this solution. Best wishes, Curry Kenworthy Custom Software Development "Better Methods, Better Results" LiveCode Training and Consulting http://livecodeconsulting.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: Stacks not removed from memory?
On 5/14/21 2:49 PM, Marty Knapp via use-livecode wrote: When you close a stack that has its destroyStack set to true, it should not remain in memory. In my case it also seems to get stuck as the default stack. Even if my preference stack did not remove from memory as it should, specifically going to stack "XYZ" and setting it as the defaultStack, one would expect "this stack" to be be "XYZ" but it is not. As mentioned I am now querying revLoadedStacks and manually deleting from memory the preference stack and that seems to have taken care of it. But it makes me nervous that the same issue may unexpectedly arise elsewhere in my code. This is an app that has been working fine for years and this has not been an issue till now. I agree this should work but until it does, a workaround might be to use "the topstack" rather than "this stack". -- 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: Stacks not removed from memory?
Thanks. So many things can legitimately change the value of "this" I generally prefer more explicit references. Maybe with this apparent bug there's one more reason I'm grateful to have adopted this habit. -- Richard Gaskin Fourth World Systems When you close a stack that has its destroyStack set to true, it should not remain in memory. In my case it also seems to get stuck as the default stack. Even if my preference stack did not remove from memory as it should, specifically going to stack "XYZ" and setting it as the defaultStack, one would expect "this stack" to be be "XYZ" but it is not. As mentioned I am now querying revLoadedStacks and manually deleting from memory the preference stack and that seems to have taken care of it. But it makes me nervous that the same issue may unexpectedly arise elsewhere in my code. This is an app that has been working fine for years and this has not been an issue till now. Marty ___ 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: Stacks not removed from memory?
When you close a stack that has its destroyStack set to true, it should not remain in memory. In my case it also seems to get stuck as the default stack. Even if my preference stack did not remove from memory as it should, specifically going to stack "XYZ" and setting it as the defaultStack, one would expect "this stack" to be be "XYZ" but it is not. As mentioned I am now querying revLoadedStacks and manually deleting from memory the preference stack and that seems to have taken care of it. But it makes me nervous that the same issue may unexpectedly arise elsewhere in my code. This is an app that has been working fine for years and this has not been an issue till now. Marty > On May 14, 2021, at 12:35 PM, Richard Gaskin via use-livecode > wrote: > > Thanks, Marty. > > I used to use stacks for preferences, but I found arrays to be simpler in > addition to being slightly faster. > > But it seems the core of your issue isn't so much about LC's cache management > as with object referencing with "this" - do I understand the issue correctly? > > -- > Richard Gaskin > Fourth World Systems > > >> In my case it's not a name conflict. Lets say I have a main stack "XYZ" and >> then I query a separate Preference stack: >> put the cpCustomProperty of stack "full_path_to_pref_stack" into tPref >> close stack "pref_stack" >> (my preference stack has destroyStack set to true) >> Now thinking that I'm back in my main stack "XYZ" I do something like: >> put tPref into fld "123" of this stack >> This worked fine for me for years. In LC 9.6.2 rc 5, it would fail most of >> the time. Curious, I inserted code to find out what LC thought was "this >> stack" only to discover that *sometimes* it's the preference stack that I >> just closed. >> Then after closing the preference stack, I tried "go stack "XYZ" and "set >> the default stack to "XYZ" But "this stack" would still (most of the time) >> report my supposedly closed preference stack. >> So now I'm having to query for revLoadedStacks and if my preference stack is >> listed then I delete it from memory. >> I did file a bug report (#23194 ) but as it does not always happen I have >> not provided a test stack. >> Marty > ___ 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: Stacks not removed from memory?
Thanks, Marty. I used to use stacks for preferences, but I found arrays to be simpler in addition to being slightly faster. But it seems the core of your issue isn't so much about LC's cache management as with object referencing with "this" - do I understand the issue correctly? -- Richard Gaskin Fourth World Systems In my case it's not a name conflict. Lets say I have a main stack "XYZ" and then I query a separate Preference stack: put the cpCustomProperty of stack "full_path_to_pref_stack" into tPref close stack "pref_stack" (my preference stack has destroyStack set to true) Now thinking that I'm back in my main stack "XYZ" I do something like: put tPref into fld "123" of this stack This worked fine for me for years. In LC 9.6.2 rc 5, it would fail most of the time. Curious, I inserted code to find out what LC thought was "this stack" only to discover that *sometimes* it's the preference stack that I just closed. Then after closing the preference stack, I tried "go stack "XYZ" and "set the default stack to "XYZ" But "this stack" would still (most of the time) report my supposedly closed preference stack. So now I'm having to query for revLoadedStacks and if my preference stack is listed then I delete it from memory. I did file a bug report (#23194 ) but as it does not always happen I have not provided a test stack. Marty ___ 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: Stacks not removed from memory?
It’s happening for me in standalone. And I should mention that my tests were on Mac only (Mojave). Marty > On May 14, 2021, at 10:59 AM, Niggemann, Bernd via use-livecode > wrote: > > If the Project Browser is open then it may be related to > > https://quality.livecode.com/show_bug.cgi?id=22460 > > Kind regards > Bern > ___ ___ 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: Stacks not removed from memory?
If the Project Browser is open then it may be related to https://quality.livecode.com/show_bug.cgi?id=22460 Kind regards Bern ___ 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: Stacks not removed from memory?
On 5/14/21 10:05 AM, Richard Gaskin via use-livecode wrote: Is this to avoid stack name conflicts, or is there some other reason to use this feature? Because if it's just the stack name conflict thang, I'd rather we solve that at the root by being done with that IDE-imposed limitation that doesn't actually exist in the engine: https://quality.livecode.com/show_bug.cgi?id=1061 LOL. That bug report (still driving developers up the wall after 18 years) has my favorite team comment (#13): Re-assigning to engine team for future re-assignment. -- Mark Wieder ahsoftw...@gmail.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: Stacks not removed from memory?
In my case it's not a name conflict. Lets say I have a main stack "XYZ" and then I query a separate Preference stack: put the cpCustomProperty of stack "full_path_to_pref_stack" into tPref close stack "pref_stack" (my preference stack has destroyStack set to true) Now thinking that I'm back in my main stack "XYZ" I do something like: put tPref into fld "123" of this stack This worked fine for me for years. In LC 9.6.2 rc 5, it would fail most of the time. Curious, I inserted code to find out what LC thought was "this stack" only to discover that *sometimes* it's the preference stack that I just closed. Then after closing the preference stack, I tried "go stack "XYZ" and "set the default stack to "XYZ" But "this stack" would still (most of the time) report my supposedly closed preference stack. So now I'm having to query for revLoadedStacks and if my preference stack is listed then I delete it from memory. I did file a bug report (#23194 ) but as it does not always happen I have not provided a test stack. Marty > On May 14, 2021, at 10:05 AM, Richard Gaskin via use-livecode > wrote: > > Devin Asay wrote: > > > I have seen what you’re describing on all of the recent releases—9.5 - > > 9.6.x; i.e., a stack with destroyStack set to true, then closed, is > > not always removed from memory. Sometimes this has caused an infinite > > loop with the Save - Purge - Cancel dialog. I would report it, but I > > haven’t been able to come up with a reliable recipe. It’s a problem > > that I would like to nail down and squash. > > Is this to avoid stack name conflicts, or is there some other reason to use > this feature? > > Because if it's just the stack name conflict thang, I'd rather we solve that > at the root by being done with that IDE-imposed limitation that doesn't > actually exist in the engine: > > https://quality.livecode.com/show_bug.cgi?id=1061 > > -- > 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: Stacks not removed from memory?
Devin Asay wrote: > I have seen what you’re describing on all of the recent releases—9.5 - > 9.6.x; i.e., a stack with destroyStack set to true, then closed, is > not always removed from memory. Sometimes this has caused an infinite > loop with the Save - Purge - Cancel dialog. I would report it, but I > haven’t been able to come up with a reliable recipe. It’s a problem > that I would like to nail down and squash. Is this to avoid stack name conflicts, or is there some other reason to use this feature? Because if it's just the stack name conflict thang, I'd rather we solve that at the root by being done with that IDE-imposed limitation that doesn't actually exist in the engine: https://quality.livecode.com/show_bug.cgi?id=1061 -- 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: Stacks not removed from memory?
Marty, I had intended to respond to this, but got busy with other things. I have seen what you’re describing on all of the recent releases—9.5 - 9.6.x; i.e., a stack with destroyStack set to true, then closed, is not always removed from memory. Sometimes this has caused an infinite loop with the Save - Purge - Cancel dialog. I would report it, but I haven’t been able to come up with a reliable recipe. It’s a problem that I would like to nail down and squash. - Devin > On Apr 28, 2021, at 12:40 PM, Marty Knapp via use-livecode > wrote: > > Is anybody else experiencing with LC 9.6.2 rc5 that stacks with destroyStack > set to true are not always removed from memory when they're closed? It's been > happening to me in the IDE and standalones but not every time. And even when > I specifically go to another stack, set that stack to the defaultStack, that > any script with “of this stack” throws an error because it thinks "this > stack" it's the stack I just closed. > > Marty > ___ > 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 Devin Asay Director Office of Digital Humanities Brigham Young University ___ 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
