Closed ArturKnopik closed 2 months ago
todo: missing month
I really dislike the fact that it doesn't even prints error messages on stderr. Also the output looks kinda ugly, especially with these _E_
, _F_
, etc.
I would probably also replace fatal with trace.
What's the purpose of making it a separate thread? I would rather keep it simple and just wrap around Boost.Log, which is already thread-safe.
clarification: 1) why no boost.log/spdlog - I didn't want to add another dependency 2) message format - I use the format that is used in my work (the project is over 25 years old), it works quite well, this can be changed if someone defines what it should look like 3) why separated thread: the file open + write operation is expensive, in many cases the file will be opened every time we log, I don't want to block the main thread by writing logs etc. 4) why a separate configuration file for logger: config.lua is loaded relatively late and I want to have a logger from the very beginning 5) why logF instead Log.fatal("fatal") etc: I want it to be short and quick to write logs
why separated thread: the file open + write operation is expensive, in many cases the file will be opened every time we log, I don't want to block the main thread by writing logs etc.
It would be better than to write to stdout or stderr and pipe to a file if necessary. So it stays open, managed by the OS
why a separate configuration file for logger: config.lua is loaded relatively late and I want to have a logger from the very beginning
How about using environment variables for that? So you don't need to read any file
It would be better than to write to stdout or stderr and pipe to a file if necessary. So it stays open, managed by the OS
In my opinion, the log size limit is quite significant feature
Pull Request Prelude
Changes Proposed
Logger that can handle LUA and C++ calls.
logger.conf - logger config file, not required
Issues addressed: Lack of true logger.