When troubleshooting something using the flow log, I found something like this.
======================
05.07.2018 00:15:41.953 [Windows Recognizer] Starting to execute flow 'Windows Recognizer' with Context{global{global_clipboard=[,.....
......
a
bunch
of
global
variable
value
.......
05.07.2018 00:15:41.954 [Windows Recognizer] Start executing condition 'Expression: containsElement(newList( "ch.gridvision.ppam.androidautomagic", "com.teslacoilsw.launcher" ), package_name)'
05.07.2018 00:15:41.958 [Windows Recognizer] End executing condition 'Expression: containsElement(newList( "ch.gridvision.ppam.androidautomagic", "com.teslacoilsw.launcher" ), package_name)' with return value true
05.07.2018 00:15:41.958 [Windows Recognizer] Flow continues executing with the next step.
05.07.2018 00:15:41.958 [Windows Recognizer] Start executing action 'Sleep: 5s (keep device awake)'
05.07.2018 00:15:41.958 [Windows Recognizer] Action 'Sleep: 5s (keep device awake)' Sleeping for 5s (keep device awake)
05.07.2018 00:15:42.998 [Windows Recognizer] Stopping execution due to stop-execution policy
05.07.2018 00:15:43.001 [Windows Recognizer] Action 'Sleep: 5s (keep device awake)' sleep interrupted
05.07.2018 00:15:43.001 [Windows Recognizer] End executing action 'Sleep: 5s (keep device awake)'
==================
Everytime the flow execute, the first line always tell that the flow execute with the Context{global...... And I have a bunch of glovar there, most of them are map/list, so very long. They will show up and always makes the log harder to read, especially to spot the beginning of the execution. I wish there is a way I can uncheck an option and supress the glovar message. I know it will be harder to spot what's going wrong when glovar is involved inside the flow. But We have debug dialog for that purpose already. So I think the glovar can be hidden from the log, of course it is should toggleable in case we need to it again.
Then the whole long value of the date, time down to miliseconds, including the flow name.
05.07.2018 00:15:41.953 [Windows Recognizer]
I think those should be customizeable too. It is too long and eating half of the log windows already, while most them are similar. Flow name always stays the same already when we view the log inside a flow, shouldn't be needed anymore. For date time, most of our flow execution 98% of the time finished within seconds, so the date should be unnecessary. Even the hour and minute, most of the time is not used. So It would be nice if we can specified what information we can show there.
Maybe using some pattern character. the default pattern is
Code: Select all
dd.MM.yyyy HH:mm:ss.SSS {flow_name} {log}
We can then specify something like
Code: Select all
ss.SSS {log}
41.954 Start executing condition 'Expression: containsElement(newList( "ch.gridvision.ppam.androidautomagic", "com.teslacoilsw.launcher" ), package_name)'
41.958 End executing condition 'Expression: containsElement(newList( "ch.gridvision.ppam.androidautomagic", "com.teslacoilsw.launcher" ), package_name)' with return value true
41.958 Flow continues executing with the next step.
41.958 Start executing action 'Sleep: 5s (keep device awake)'
41.958 Action 'Sleep: 5s (keep device awake)' Sleeping for 5s (keep device awake)
42.998 Stopping execution due to stop-execution policy
43.001 Action 'Sleep: 5s (keep device awake)' sleep interrupted
43.001 End executing action 'Sleep: 5s (keep device awake)'
This makes the flow much shorter and easily to spot the problem and flow execution.
Or much better, if there is another extra option to automatically deduct the rest of the time for the trigger time. In most cases, we only need to know how fast or how long it takes for the flow to finish. I sometimes try and see which script finished faster, especially when dealing with looping with more than hundreds of elements. Nested looping usually takes longer, but need to be crosschecked with the time taken. The original log won't be override, only the currrent flow log view is modified. When this "anchor triggertime" option turned on, all flow execution will be measured starting from 00.000. so the above will be
00.000 Start executing condition 'Expression: containsElement(newList( "ch.gridvision.ppam.androidautomagic", "com.teslacoilsw.launcher" ), package_name)'
00.004 End executing condition 'Expression: containsElement(newList( "ch.gridvision.ppam.androidautomagic", "com.teslacoilsw.launcher" ), package_name)' with return value true
00.004 Flow continues executing with the next step.
00.004 Start executing action 'Sleep: 5s (keep device awake)'
00.004 Action 'Sleep: 5s (keep device awake)' Sleeping for 5s (keep device awake)
01.044 Stopping execution due to stop-execution policy
01.047 Action 'Sleep: 5s (keep device awake)' sleep interrupted
01.047 End executing action 'Sleep: 5s (keep device awake)'
I can see easily see now that the expression took 4 ms to complete and continue to next element execution, much easier to troubleshoot and to determine if the script/element is running at its best perfomance. When new trigger occured, the first execution will be 00.000 again. But the real log still show the real time, the 00.000 only shows up in this flow's log view only.
Proceeding to the next customization is the coloring. Probably we can have some coloring for certain logic. Example, when the flow continue with true, next line will be green, while false will be red. New starting execution will be light blue. Stopped execution will be orange. Error will shown in gray. But i am afraid this will affect the log perfomance, so if should be toggleable if it is implemented.
Last one is to supress the error exception. When encounter exception, usually there will be about a dozen of error lines, most of the time those error are meaningless to us. While the real error is already shown in the first line. So if we can supress those exception lines, we can spot the real error much easier.
Summary
To summarize, the whole customization of the log are :
1. Option to supress the Global variable context
2. Customize the date time and whether to show flow name in the log
3. option to use triggertime as 00.000 in the log view
4. Coloring the log based on the logic
5. Supress the error exception.
These should be toggleable or customizeable option located in the setting > logging.
I am sorry if i request too many at once. But I thought they all fall into the same topic, so it is better to customize all at once rather than requesting one by one, making the planning of the big picture much more complicated.
Thank & Regards,
Desmanto