Hi,
Thanks for reporting. The errors in the log are not meant to look this way. The errors happen when a flow is stopped by an action 'Stop Flows' or with the Stop menu item. The next update will show a less scary entry in the log.
The issue that the widgets don't update anymore is caused by an optimization that I made some time ago to avoid that widgets are updated too frequently which can cause the system to slow down. Updating widgets is quite a heavy weight process on Android and should only be done when really necessary and not every few milliseconds. To avoid that widgets are updated too frequently, the updates are delayed by about 500ms and skipped when another update becomes necessary in the next 500ms. When you are updating one widget each 500ms, the update will still work. As soon as you update a second widget every 500ms, the chances are that the widgets don't update at all since Automagic waits until no update is requested anymore within the next 500ms. This will not work for your case.
I'll change the optimization so that updates are grouped together but at least an update is executed each 500ms. This should still be OK for the system and should work for your blinking elements. I have to test this change so it will become available in v1.38 (EAP build will become available soon).
Regards,
Martin
Multiple sleep() calls from multiple flows
Moderator: Martin
-
- Posts: 69
- Joined: 14 Feb 2019 15:04
Re: Multiple sleep() calls from multiple flows
Hi Martin,
Thank you for your input and future fix.
I'll try the EAP build as soon as it's available and report back.
Thank you for your input and future fix.
I'll try the EAP build as soon as it's available and report back.
Re: Multiple sleep() calls from multiple flows
@elektroinside : I am very confused with your flow, have to rearrange the whole elements first before I can understand what it does. I am sure this is just the temporary flow only, because if this is the function flow, the number elements will contribute to the overall slowdown. The best way to this is to use loop with initialized value outside of the loop.
1. Put script to initialize
2. Put the loop into expression.
This loop toggle between true and false. Since your script use 2000 and I combine both true and false, the loop should be 4000 now. (Beware of Automagic's maximum loop at 10000)
3. Add action sleep 500ms after true branch to loop back to 2. We don't use sleep(500) inside script, as it will suffer from global script lock. So we have to put sleep outside of the script/expression.
Using this, I can create a blinking widget at 1 fps (500 ms disappear, 500 ms appear).
This, along with your other question about calling flow with parameter, probably can avoid the global lock or the problem of multiple error when executing multiple flow.
@Martin : If you are going to prettify the log view, can you take a look at this : viewtopic.php?f=4&t=7484
1. Put script to initialize
Code: Select all
tf = true; i = 0;
Code: Select all
if(i < 4000)
{
tf = !tf; i = i + 1;
setWidgetElementProperty("CLIENTS", "Text_1", "visible", tf);;
return true;
}
return false;
3. Add action sleep 500ms after true branch to loop back to 2. We don't use sleep(500) inside script, as it will suffer from global script lock. So we have to put sleep outside of the script/expression.
Using this, I can create a blinking widget at 1 fps (500 ms disappear, 500 ms appear).
This, along with your other question about calling flow with parameter, probably can avoid the global lock or the problem of multiple error when executing multiple flow.
@Martin : If you are going to prettify the log view, can you take a look at this : viewtopic.php?f=4&t=7484
Index of Automagic useful thread List of my other useful posts (and others')
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.
Re: Multiple sleep() calls from multiple flows
@Desmanto: I saw your request to improve the logging view but this will take a bit longer to implement. The fix in this case is very simple and will already be in the next update (today or tomorrow).