Detailed Debugging/Logging

Help improve Bet Angel.
Post Reply
Anbell
Posts: 2004
Joined: Fri Apr 05, 2019 2:31 am

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)
sionascaig
Posts: 1053
Joined: Fri Nov 20, 2015 9:38 am

Anbell wrote:
Wed Sep 02, 2020 8:29 am
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)
I find using stored values can help a lot with debugging (but appreciate your point)...

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..
User avatar
mcgoo
Posts: 898
Joined: Thu Jul 18, 2013 12:30 pm

Anbell wrote:
Wed Sep 02, 2020 8:29 am
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)
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 conditions
Anbell
Posts: 2004
Joined: Fri Apr 05, 2019 2:31 am

sionascaig wrote:
Wed Sep 02, 2020 9:19 am
Anbell wrote:
Wed Sep 02, 2020 8:29 am
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)
I find using stored values can help a lot with debugging (but appreciate your point)...

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, 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.
Anbell
Posts: 2004
Joined: Fri Apr 05, 2019 2:31 am

mcgoo wrote:
Wed Sep 02, 2020 9:26 am
Anbell wrote:
Wed Sep 02, 2020 8:29 am
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)
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 conditions
Yeah, it's such a laborious manual process.

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.
User avatar
jimibt
Posts: 3641
Joined: Mon Nov 30, 2015 6:42 pm
Location: Narnia

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.
User avatar
mcgoo
Posts: 898
Joined: Thu Jul 18, 2013 12:30 pm

Anbell wrote:
Wed Sep 02, 2020 9:42 am
mcgoo wrote:
Wed Sep 02, 2020 9:26 am
Anbell wrote:
Wed Sep 02, 2020 8:29 am
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)
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 conditions
Yeah, it's such a laborious manual process.

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.
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 things :)
Post Reply

Return to “Suggestions”