I spend way too much time trying to debug my automations.
It'd be really helpful if there was a debug/idiot mode that you could turn on if you were having a problem, and for every bet it would lay out clearly why you had the bet. It would include the details of all of your conditions, and all of your SVs and whatever else.
For example:
Condition 1: There must be at least 10 runners in the race. Situation: # of runners=12. Condition met.
Condition 2: The price of the fave must be greater than 2. Situation: Fave price =2.2. Condition met.
Condition 3: The value of HistoryList 1 for this runner must be > 7. Situation: etc
(It would also be very nice to be able to customise the name of each History List)
In an ideal world we'd also be able to debug why a bet was NOT processed, but I'm not sure how to go about that, other than logging every (time period) the same (which actually seems not too difficult)
Detailed Debugging/Logging
-
- Posts: 1053
- Joined: Fri Nov 20, 2015 9:38 am
I find using stored values can help a lot with debugging (but appreciate your point)...Anbell wrote: ↑Wed Sep 02, 2020 8:29 amI spend way too much time trying to debug my automations.
It'd be really helpful if there was a debug/idiot mode that you could turn on if you were having a problem, and for every bet it would lay out clearly why you had the bet. It would include the details of all of your conditions, and all of your SVs and whatever else.
For example:
Condition 1: There must be at least 10 runners in the race. Situation: # of runners=12. Condition met.
Condition 2: The price of the fave must be greater than 2. Situation: Fave price =2.2. Condition met.
Condition 3: The value of HistoryList 1 for this runner must be > 7. Situation: etc
(It would also be very nice to be able to customise the name of each History List)
In an ideal world we'd also be able to debug why a bet was NOT processed, but I'm not sure how to go about that, other than logging every (time period) the same (which actually seems not too difficult)
If possible anything you want to condition against that can be held as a stored value set up in an "initiation" SV rule, then use these SV's in your rules files. You can then set up a "test" rule to output the values you are conditioning against to see what the actual values are... Not saying it will solve the issue but may help..
Was just thinking exact thing . Suddenly my automation is not betting at all. I have tried using SV's to track the changes but it is a nightmare to watch logs, ladder numbers changing or use signals to track conditionsAnbell wrote: ↑Wed Sep 02, 2020 8:29 amI spend way too much time trying to debug my automations.
It'd be really helpful if there was a debug/idiot mode that you could turn on if you were having a problem, and for every bet it would lay out clearly why you had the bet. It would include the details of all of your conditions, and all of your SVs and whatever else.
For example:
Condition 1: There must be at least 10 runners in the race. Situation: # of runners=12. Condition met.
Condition 2: The price of the fave must be greater than 2. Situation: Fave price =2.2. Condition met.
Condition 3: The value of HistoryList 1 for this runner must be > 7. Situation: etc
(It would also be very nice to be able to customise the name of each History List)
In an ideal world we'd also be able to debug why a bet was NOT processed, but I'm not sure how to go about that, other than logging every (time period) the same (which actually seems not too difficult)
Yeah, that's true, but tracking and tracing is just so time consuming, and there's no particular reason why we all spend that time individually (if we have the tech wherewithal), when I imagine that it could be so easily automated.sionascaig wrote: ↑Wed Sep 02, 2020 9:19 amI find using stored values can help a lot with debugging (but appreciate your point)...Anbell wrote: ↑Wed Sep 02, 2020 8:29 amI spend way too much time trying to debug my automations.
It'd be really helpful if there was a debug/idiot mode that you could turn on if you were having a problem, and for every bet it would lay out clearly why you had the bet. It would include the details of all of your conditions, and all of your SVs and whatever else.
For example:
Condition 1: There must be at least 10 runners in the race. Situation: # of runners=12. Condition met.
Condition 2: The price of the fave must be greater than 2. Situation: Fave price =2.2. Condition met.
Condition 3: The value of HistoryList 1 for this runner must be > 7. Situation: etc
(It would also be very nice to be able to customise the name of each History List)
In an ideal world we'd also be able to debug why a bet was NOT processed, but I'm not sure how to go about that, other than logging every (time period) the same (which actually seems not too difficult)
If possible anything you want to condition against that can be held as a stored value set up in an "initiation" SV rule, then use these SV's in your rules files. You can then set up a "test" rule to output the values you are conditioning against to see what the actual values are... Not saying it will solve the issue but may help..
Yeah, it's such a laborious manual process.mcgoo wrote: ↑Wed Sep 02, 2020 9:26 amWas just thinking exact thing . Suddenly my automation is not betting at all. I have tried using SV's to track the changes but it is a nightmare to watch logs, ladder numbers changing or use signals to track conditionsAnbell wrote: ↑Wed Sep 02, 2020 8:29 amI spend way too much time trying to debug my automations.
It'd be really helpful if there was a debug/idiot mode that you could turn on if you were having a problem, and for every bet it would lay out clearly why you had the bet. It would include the details of all of your conditions, and all of your SVs and whatever else.
For example:
Condition 1: There must be at least 10 runners in the race. Situation: # of runners=12. Condition met.
Condition 2: The price of the fave must be greater than 2. Situation: Fave price =2.2. Condition met.
Condition 3: The value of HistoryList 1 for this runner must be > 7. Situation: etc
(It would also be very nice to be able to customise the name of each History List)
In an ideal world we'd also be able to debug why a bet was NOT processed, but I'm not sure how to go about that, other than logging every (time period) the same (which actually seems not too difficult)
I grab the logs and then try to parse them in excel to get the relevant data and it's still really difficult to get the right information.
Debugging is an inherently cumbersome process, so it would be good to streamline it where we can.
in an ideal world, BA would expose a .Net interface (in the form of an addin for visual studio to allow scripting). this addin would have a companion DLL that contained the *stubs* of the Guardian automation routines. THis would allow you to create, test and debug your rules in an environment that was setup for debugging. The addin would *constrain* input so as to be 100% compatable with standard Guardian rules syntax (output!!), thus allowing the rule to be EXPORTED to Guardian if required.
I know this will never happen due to licencing and costs (tho there are many 3rd party software vendors that do exactly this - UIPath etc) but it would be a GREAT way to allow developers to get some higher octane action against the BA engine - either as a hybrid model or exclusivley running .Net based rules thro the BA innards.
I know this will never happen due to licencing and costs (tho there are many 3rd party software vendors that do exactly this - UIPath etc) but it would be a GREAT way to allow developers to get some higher octane action against the BA engine - either as a hybrid model or exclusivley running .Net based rules thro the BA innards.
Agreed. Also not sure why there is a limit - 10 history lists but 5 or 10 more would help while we are talking about such thingsAnbell wrote: ↑Wed Sep 02, 2020 9:42 amYeah, it's such a laborious manual process.mcgoo wrote: ↑Wed Sep 02, 2020 9:26 amWas just thinking exact thing . Suddenly my automation is not betting at all. I have tried using SV's to track the changes but it is a nightmare to watch logs, ladder numbers changing or use signals to track conditionsAnbell wrote: ↑Wed Sep 02, 2020 8:29 amI spend way too much time trying to debug my automations.
It'd be really helpful if there was a debug/idiot mode that you could turn on if you were having a problem, and for every bet it would lay out clearly why you had the bet. It would include the details of all of your conditions, and all of your SVs and whatever else.
For example:
Condition 1: There must be at least 10 runners in the race. Situation: # of runners=12. Condition met.
Condition 2: The price of the fave must be greater than 2. Situation: Fave price =2.2. Condition met.
Condition 3: The value of HistoryList 1 for this runner must be > 7. Situation: etc
(It would also be very nice to be able to customise the name of each History List)
In an ideal world we'd also be able to debug why a bet was NOT processed, but I'm not sure how to go about that, other than logging every (time period) the same (which actually seems not too difficult)
I grab the logs and then try to parse them in excel to get the relevant data and it's still really difficult to get the right information.
Debugging is an inherently cumbersome process, so it would be good to streamline it where we can.