ErrExit on Perform Task, not child task

[David White]

Running 4.3b9m - Put a popup before the Perform Task, and another popup as the first action in the child task. The popup before appears, the one inside the child doesn't. A log shows an ErrExit at the Perform Task step, with no activity inside the child task.

The call passes a string and catches a string returned by the child task. Apparently, something about the call isn't sitting well with Tasker.  How do I debug this to understand what's making Tasker exit before it enters?

Thanks in advance!

Dave White

[Rich D]

> Running 4.3b9m - Put a popup before the Perform Task, and another popup as the first action in the child task. The popup before appears, the one inside the child doesn't. A log shows an ErrExit at the Perform Task step, with no activity inside the child task.
>
> The call passes a string and catches a string returned by the child task. Apparently, something about the call isn't sitting well with Tasker.  How do I debug this to understand what's making Tasker exit before it enters?

Could be a few things. First thought might be you have not saved out of Tasker since making the child task.  Or  you did not use the mag glass to select child task and the name is not correct.

Could you export both task descriptions..

To post your profile or task here...  Long press on the profile or task name / ( 3 dot menu with 4.0+ ) export / export description to clipboard (not XML)

Any linked tasks will be exported with the profile they are linked to..

The beginner mode needs to be off and the profile needs to have a name to be able to export.

[David White]

> Could you export both task descriptions..

Log:
20140316 21.49.46 A Err      ID4:4.6  BestMatch.Get the regexp for the current domain
20140316 21.49.46 T ExitErr  ID4:4    BestMatch

Parent task; Err occurs at A6
BestMatch (4)
<Reconstitute current domain>
A1: Variable Set [ Name:%current_domain To:%par1 Do Maths:Off Append:Off ]
<Reconstitute the transcriptions>
A2: Variable Set [ Name:%voice_data To:%par2 Do Maths:Off Append:Off ]
A3: Variable Split [ Name:%voice_data Splitter:, Delete Base:On ]
<How confident are we in our match?  Only update when match is better than Best>
A4: Variable Set [ Name:%confidence To:0 Do Maths:Off Append:Off ]
A5: [X] Popup [ Title: Text:Calling GetDomainRegexp %current_domain Background Image: Layout:Popup Timeout (Seconds):5 Show Over Keyguard:On ]
<Get the regexp for the current domain>
A6: Perform Task [ Name:GetDomainRegexp Stop:Off Priority:%priority+1 Parameter 1 (%par1):%current_domain Parameter 2 (%par2): Return Value Variable:%domain_regexp ]
<Get available commands for the current domain>
A7: Perform Task [ Name:GetAvailableCommands Stop:Off Priority:%priority+1 Parameter 1 (%par1):%current_domain Parameter 2 (%par2): Return Value Variable:%available_commands ]
A8: Popup [ Title: Text:%voice_data() Background Image: Layout:Popup Timeout (Seconds):5 Show Over Keyguard:On ]
<Iterate over all commands in this domain>
A9: For [ Variable:%current_command Items:%available_commands() ]
<Get regexp for this command>
A10: Perform Task [ Name:GetCommandRegexp Stop:Off Priority:%priority+1 Parameter 1 (%par1):%current_domain Parameter 2 (%par2):%current_command Return Value Variable:%cmd_regexp ]
<Get scoring task for this command>
A11: Perform Task [ Name:GetScoringTask Stop:Off Priority:%priority+1 Parameter 1 (%par1):%current_domain Parameter 2 (%par2):%current_command Return Value Variable:%scoring_task ]
<Get name of task which will perform this command>
A12: Perform Task [ Name:GetActionTask Stop:Off Priority:%priority+1 Parameter 1 (%par1):%current_domain Parameter 2 (%par2):%current_command Return Value Variable:%action_task ]
<Iterate over all transcriptions>
A13: For [ Variable:%transcription_index Items:1:%voice_data(#) ]
A14: Flash [ Text:%voice_data(%transcription_index) Long:On ]
<Forget prior parsing results>
A15: Array Clear [ Name:%tokens ]
<Split into chunks we recognize>
A16: Variable Search Replace [ Variable:%voice_data(%transcription_index) Search:%domain_regexp%cmd_regexp Ignore Case:On Multi-Line:Off One Match Only:Off Store Matches In:%tokens Replace Matches:Off Replace With: ]
<Evaluate how good of a match this is>
A17: Perform Task [ Name:%scoring_task Stop:Off Priority:%priority+1 Parameter 1 (%par1):%tokens() Parameter 2 (%par2): Return Value Variable:%score ]
<Is this match better than what we've seen?>
A18: If [ %score > %Best_Confidence ]
A19: Variable Set [ Name:%confidence To:%score Do Maths:Off Append:Off ]
A20: Variable Set [ Name:%Best_Confidence To:%score Do Maths:Off Append:Off ]
A21: Variable Set [ Name:%Best_Parser To:%action_task Do Maths:Off Append:Off ]
A22: Variable Set [ Name:%Best_Transcription To:%transcription_index Do Maths:Off Append:Off ]
<If we're confident this is what was intended and not exhaustively searching, run it>
A23: Perform Task [ Name:%action_task Stop:On Priority:5 Parameter 1 (%par1):%current_domain Parameter 2 (%par2):%voice_data(%transcription_index) Return Value Variable: ] If [ %score > %Required_Confidence & %Exhaustive_Command_Search != 1 ]
<End of better match>
A24: End If
<Examine next transcription>
A25: End For
A26: Return [ Value:%confidence Stop:On ]

Child task:
GetDomainRegexp (6)
A1: Popup [ Title: Text:Entering GetDomainRegexp %par1 Background Image: Layout:Popup Timeout (Seconds):5 Show Over Keyguard:On ]
A2: Variable Set [ Name:%current_regexp_name To:%par1 Do Maths:Off Append:Off ]
A3: Variable Set [ Name:%current_regexp_name To:_Regexp Do Maths:Off Append:On ]
A4: Variable Set [ Name:%domain_regexp To:%%current_regexp_name Do Maths:Off Append:On ]
A5: Return [ Value:%domain_regexp Stop:On ]

> The beginner mode needs to be off and the profile needs to have a name to be able to export.

Didn't see beginner mode in the preferences. I must have turned it off previously, as it obviously exported.

Many thanks for any enlightenment you can provide.
Dave White

[Rich D]

> A6: Perform Task [ Name:GetDomainRegexp Stop:Off Priority:%priority+1 Parameter 1 (%par1):%current_domain Parameter 2 (%par2): Return Value Variable:%domain_regexp ]
> <Get available commands for the current domain>

It is the %priority+1.  When testing with play button priority is set at 10. There is no priority 11. 

Pent knows about this and I believe it will be fixed for the next beta.  In the mean time if you long press on the play button you can set the launch priority to something lower..

[David White]

There's something funky with priorities...  I added an action to flash %priority when entering from the profile. Despite the profile being set to "Normal" priority, the initial task shows %priority to be 16

To set the record straight, I hadn't been testing via the play button, only by entering via the profile.  (I'm attempting to process voice data from Utter! If that makes any difference.)

Thanks!

[Rich D]

On Mar 25, 2014 6:56 PM, "David White" <d.b.wh...@gmail.com> wrote:
>
> There's something funky with priorities...  I added an action to flash %priority when entering from the profile. Despite the profile being set to "Normal" priority, the initial task shows %priority to be 16
>
>

I can confirm this.  This profile will flash 16..

Profile: Win Changed (301)
Event: New Window [ Label:* Window Type:Any ]
Enter: Anon (302)
A1: Flash [ Text:%priority Long:Off ]

I will copy this to the beta thread..

[Bob Hansen]

It appears that the profile %priority value is added to 11. When the profile priority is set to 1 flashing %priority in the task displays 12. When the profile priority is set to 10 flashing %priority in the task displays 21.

[Pent]

>It appears that the profile %priority value is added to 11. When the profile priority is set to 1 flashing %priority in the task displays 12. When >the profile priority is set to 10 flashing %priority in the task displays 21.

After 4 years some of the inner priority voodoo has been revealed to the light of day :-)

The priority you specify in some places in the UI is relative to how the task is run. There are 2 categories relevant to users. Enter
tasks start with a base of 0, so if you say priority 5 in profile properties, that's what the task runs at. Exit tasks start with a base of 11,
meaning if you specify 5, the task actually runs at 16. The point of that originally was to make sure exit tasks always run before enter
tasks. So if I have two profiles both with app contexts, when I go from one app to the other, the exit task of profile A runs before the
enter task of profile B.

Instant profiles are an exception: there was want the enter task to run first (because it's listed first in the UI so is intuitive to the user)
and the exit task (shown as enter to the user) to run second, so the base priorities are switched.

Next Tasker verson (4.4, not current 4.3) I will increased the base for the exit tasks to 31 or similar, so that you never jump into the
next category by specifying %priority + 1 in Perform Task.

Now I think about it, instead of instant profiles switching priority base, they should both run with the enter base, but the second gets a one-higher priority, will also test that in 4.4.

Hope you could wrap your minds around all that :-)

Pent

[Bob Hansen]

I had a feeling that this might be intentional. It seems like it is also a good thing to know as it could make it easier to understand the relationship between different profile enter and exit task priorities. It makes sense to me that exit tasks should have a higher priority than enter task.

The way it is currently set up, then, is that all exit tasks have a higher priority than any enter task. Correct?

To my way of thinking, that would be necessary to insure that interrelated profiles worked as expected. 

[David White]

If I had the ability to call a task like a subroutine or function and be guaranteed that it completed before returning to the parent task, I wouldn't need to be messing around with the priority setting.  Less chance of bumping into the priority limit too. For what it's worth....

[Pent]

The way it is currently set up, then, is that all exit tasks have a higher priority than any enter task. Correct?

Correct.

To my way of thinking, that would be necessary to insure that interrelated profiles worked as expected.

It was where the whole priority system started. I can remember clearly in 2010 puzzling about what the best way to
ensure that was. It was a tough summer solving all these problems in 3 months from scratch for the
developer competition.

Pent

[Pent]

If I had the ability to call a task like a subroutine or function and be guaranteed that it completed before returning to the parent task, I wouldn't need to be messing around with the priority setting.  Less chance of bumping into the priority limit too. For what it's worth....

You don't need to 'mess about with it', just put %priority + 1 and forget about it. If it doesn't work as a subroutine, report it as a bug.

Pent

[David White]

> You don't need to 'mess about with it', just put %priority + 1 and forget about it. If it doesn't work as a subroutine, report it as a bug.

That's how this thread started - I couldn't enter a subroutine, which Rich attributed to me exceeding the max %priority level. Pretty easy to exceed 10 when starting at 16...

Are you saying there's no maximum limit enforced on %priority (for  recursive calls for example)? Not that I was recursing, but something blocked entry to my subtask.

Thanks,
Dave White

[Rich D]

> > You don't need to 'mess about with it', just put %priority + 1 and forget about it. If it doesn't work as a subroutine, report it as a bug.
>
> That's how this thread started - I couldn't enter a subroutine, which Rich attributed to me exceeding the max %priority level.

When you first posted you were on beta 9 and %priority+1 had a bug at that time. It has been fixed in the latest beta, Is that what you are running now? If so are you still getting the same errors in the run log you posted before or is this a different problem?

> Are you saying there's no maximum limit enforced on %priority (for  recursive calls for example)? Not that I was recursing, but something blocked entry to my subtask.
>

Good question.

@Pent, I also noticed I can set %priority with a 'variable set' action.

1. I assume this actually changes the priority of the task?

2. I set it to 10000 without a error so I assume there now is no limit to the priority of a task now?

Rich..

[hippoma...@gmail.com]

On Wednesday, March 26, 2014 8:10:52 PM UTC-4, Rich D wrote:

> > You don't need to 'mess about with it', just put %priority + 1 and forget about it. If it doesn't work as a subroutine, report it as a bug.

> Are you saying there's no maximum limit enforced on %priority (for  recursive calls for example)? Not that I was recursing, but something blocked entry to my subtask.
>

Good question.

@Pent, I also noticed I can set %priority with a 'variable set' action.

1. I assume this actually changes the priority of the task?

2. I set it to 10000 without a error so I assume there now is no limit to the priority of a task now?

I have a semi-related question: in an earlier discussion that I was involved with, I was told (I think by Pent) that in the new version(s) of Tasker, as long as we invoke a child task with the same priority as the caller, the caller would block until the child completes. But now, it seems that it's being said that the child's priority must be greater than the caller's priority, before the caller will block.

I'm confused about this. Which is it? If the child is set to run at the same priority as the caller, will the caller block, or does the child need to have a greater priority in order to block the caller?

Thank you very much.

.

[Pent]

> Are you saying there's no maximum limit enforced on %priority (for  recursive calls for example)? Not that I was recursing, but >something blocked entry to my subtask.

That was already noted in some previous beta release notes.

@Pent, I also noticed I can set %priority with a 'variable set' action.

I wasn't sure whether it was worth taking the time to block that or not.
 

1. I assume this actually changes the priority of the task?

No. There's no reason I can think of that changing priority dynamically should not be possible,
but I wouldn't want to set the precendent of changing builtin variables having some effect.
 

2. I set it to 10000 without a error so I assume there now is no limit to the priority of a task now?

Correct deduction from wrong facts :-)

Pent

[Pent]

I have a semi-related question: in an earlier discussion that I was involved with, I was told (I think by Pent) that in the new version(s) of Tasker, as long as we invoke a child task with the same priority as the caller, the caller would block until the child completes. But now, it seems that it's being said that the child's priority must be greater than the caller's priority, before the caller will block.

 

I'm confused about this. Which is it? If the child is set to run at the same priority as the caller, will the caller block, or does the child need to have a greater priority in order to block the caller?

Equal or both should result in subroutine-like behaviour in Perform Task. There was some other thread where people were reporting it wasn't (relating to Waits I believe) but I hope that is fixed now.

I just find it clearer in examples if the kid has a higher priority.

Pent

[hippoma...@gmail.com]

On Thursday, March 27, 2014 2:04:54 AM UTC-4, Pent wrote:

Equal or both should result in subroutine-like behaviour in Perform Task. There was some other thread where people were reporting it wasn't (relating to Waits I believe) but I hope that is fixed now.

I just find it clearer in examples if the kid has a higher priority.

Oh, OK. Thank you. Actually, if equal priorities result in the child blocking the caller, then it becomes a moot point as to what happens with %priority+1 in, say, recursive calls, and we wouldn't have to be concerned with whether there is any kind of upper value for task priorities in cases like this. Therefore, it's perhaps simpler in the explanations to not talk about %priority+1.

Just a thought.

.

[Pent]

Oh, OK. Thank you. Actually, if equal priorities result in the child blocking the caller, then it becomes a moot point as to what happens with %priority+1 in, say, recursive calls, and we wouldn't have to be concerned with whether there is any kind of upper value for task priorities in cases like this. Therefore, it's perhaps simpler in the explanations to not talk about %priority+1.

That's some more clear thinking from you, I guess I agree. Maybe deep down inside I don't trust the parent-child mechanism
and want to set the priority higher just in case :-)

Pent

[David White]

> When you first posted you were on beta 9 and %priority+1 had a bug at that time. It has been fixed in the latest beta, Is that what you are running now?

Sorry, I missed the updated version announcement. Will have to go back to the group and follow the thread. Downloaded b12 and will give it a go. Thanks!

Dave White

[hippoma...@gmail.com]

On Thursday, March 27, 2014 5:12:47 AM UTC-4, Pent wrote:

That's some more clear thinking from you, I guess I agree. Maybe deep down inside I don't trust the parent-child mechanism
and want to set the priority higher just in case :-)

Pent

Thank you.

Anyway, based on my earlier messages, you can tell that I don't quite trust the reliability of that priority-controlled parent-child mechanism, either. :)

If (or better expressed, when) this invoking-a-child-with-equal-priority-blocks-the-caller-functionality ends up working as well as intended, our trust will eventually increase.

.

[Pent]

If (or better expressed, when) this invoking-a-child-with-equal-priority-blocks-the-caller-functionality ends up working as well as intended, our trust will eventually increase.

.

Let me know if (or when) it fails.

Pent