[chirp_devel] [PATCH 1/7] Add chirp.logger module (#2347)

[Zach Welch]

On 02/26/2015 04:49 PM, Dan Smith wrote:
....
>>> What is the point of writing the raw string into the file before we
>>> open it? That said, the above should be this for consistency:
>>
>> Well, it works.  The string does make it into the log file.
> 
> Sure, but that wasn't the question, the question was: "why?"

Why does it work?  No clue! :)  Why write it?  So when we are handed a
log from a user, we know what version it came from.  That would be
doubly useful if the daily builds munge the version with the build date
(which I haven't investigated, so I don't know either way).

>> It's not a log message because that would end up on the console as
>> well, and we should not unilaterally spam that line at every launch
>> (as that could preclude chirpc from being usable in command
>> pipelines).
> 
> Logging at DEBUG level seems appropriate, regardless of where it ends
> up. So far, you're still relying on the stdout intervention for
> generating debug.log on Win32, so logging it, having it go to the
> console, and thus ending up there is appropriate at the moment. When you
> add a FileHandler for debug.log, you can set that to DEBUG, let the
> console handler default to INFO, and then you won't see it on the console.

I am not familiar with this "stdout intervention" of which you speak.
How do I learn more about it (and turn it off)?  That will be required
for me to write a complete debug.log handler patch, as we don't want the
two features fighting over the same file.

The version should appear in log files regardless of the configured
logging level.  As far as I can tell, there is no way to do that with
the logging module.  Conversely, it should never appear on the console.

Presently, the debug.log would only have contained that version string
in the GUI (prior to my patches, which removed it).  If this is
critical, I would say the best immediate solution would be to add it
back in the GUI for now.  Tonight, I'll write a patch that generates a
proper debug.log, and I can remove it again.

-- 
Zach Welch
Mandolin Creek Farm
www.mandolincreekfarm.com
farm: 541-453-4131
cell: 541-740-3410