RFC: ParamUtils::ReportParamsUsageStatistics(): report the tesseract variables actually used during the current run. #4021
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… rough first draft, as in: not compile-tested, not backported to using PrintFontsTable() instead of fmt::format et al.
|
Sideways related: #3943 -- this does not intend to produce config files; this RFC is about answering "what was actually used?" and similar diagnostics questions. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The idea is this:
I assume I am not alone in this.
When running tesseract, I wonder which variables (
tesseract -c var=value) are actually used and might have an impact on what I'm trying to do. This includes thedebug_*variable set -- though I tend to tweak that set through debugger runs. 🤧This code, ripped straight from my master branch, hence non-working in tesseract mainline due to various other patches I pulled in or did myself over time, is to give an idea of how this should look, code-wise.
The tesseract variable class tracks access (read & write invocations), the whole access thing is parked behind a couple of getter/setters so we can guarantee access tracking accuracy, so we get reports like these at the end of a tesseract run:
BTW: I find the leader dots do improve readability (though I'ld loved it when
fmtcould do some spaces first, but that's just being fancy 😉 ) which is another argument to perhaps migrate tofmtinside tprintf() as was done by @stweil. Of course, the same can be accomplished with the sprintf() series, but I was lazy and foundfmtdoes this 'by default':{:.<30}and presto: leader dots (or rather more precisely technical: trailer dots 😄 🥳 )