I was very pleased when I made ASH trace its execution in the DEBUG log, many years ago. I saw it as a debugging tool for scripters. I considered having it go to a separate trace file of some sort, but since ASH scripts can make requests, and requests are logged in the DEBUG log, I put it there. So, you can see visit_url(), followed by the request/response, and then the script continuing.
I think it's time to revisit this, now that we have extremely sophisticated between battle scripts and consult scripts and such. I recently asked somebody for a DEBUG log and he gave me a 1.5 MB file which consisted of:
99% was the between battle script (which one? Who knows? We don't log the script name)
adventure.php
fight.php
api.php
I have a number of ideas:
- ASH parse trees and execution traces should go to ASH_xxx.txt, in the same directory that DEBUG and TRACE files go. There should be a way to turn that on and off, just as you can turn DEBUG and TRACE logging on and off
- When we invoke an ASH script for any reason - CLI command, between battle script, counter script, consult script - log the name in both the DEBUG and ASH files:
Starting execution of <script>
…
Ending execution of <script>
- When we are executing an ASH script, do a small amount of extra logging to the ASH file:
Requesting URL
Response received for URL
Following redirection to URL
You want to look at the returned text? That's the return value of visit_url and is already there in the trace
- What about gigantic strings? relay scripts, especially, do a visit_url, getting back a 8000 character string, and then they do massive amounts of string manipulation on that string - and we log all 8000 characters every time. Perhaps we want to see the output of string manipulation functions, since you can end up with something different, but do we need to see the entire input string every time? I suspect that CHIT traces are ginormous. is the debug trace usable at all for debugging CHIT?
Thoughts?
I think it's time to revisit this, now that we have extremely sophisticated between battle scripts and consult scripts and such. I recently asked somebody for a DEBUG log and he gave me a 1.5 MB file which consisted of:
99% was the between battle script (which one? Who knows? We don't log the script name)
adventure.php
fight.php
api.php
I have a number of ideas:
- ASH parse trees and execution traces should go to ASH_xxx.txt, in the same directory that DEBUG and TRACE files go. There should be a way to turn that on and off, just as you can turn DEBUG and TRACE logging on and off
- When we invoke an ASH script for any reason - CLI command, between battle script, counter script, consult script - log the name in both the DEBUG and ASH files:
Starting execution of <script>
…
Ending execution of <script>
- When we are executing an ASH script, do a small amount of extra logging to the ASH file:
Requesting URL
Response received for URL
Following redirection to URL
You want to look at the returned text? That's the return value of visit_url and is already there in the trace
- What about gigantic strings? relay scripts, especially, do a visit_url, getting back a 8000 character string, and then they do massive amounts of string manipulation on that string - and we log all 8000 characters every time. Perhaps we want to see the output of string manipulation functions, since you can end up with something different, but do we need to see the entire input string every time? I suspect that CHIT traces are ginormous. is the debug trace usable at all for debugging CHIT?
Thoughts?