Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable logging #10

Open
jacob-carlborg opened this issue Jul 26, 2018 · 4 comments
Open

Configurable logging #10

jacob-carlborg opened this issue Jul 26, 2018 · 4 comments
Labels
wontfix This will not be worked on

Comments

@jacob-carlborg
Copy link
Collaborator

Currently the recator (and possible other parts of the library) is doing quite a lot of logging. It would be nice if the logging could be configurable. To start with to be able to disable/enable the different log levels, ideally both at compile time and run time.

@baruch
Copy link
Collaborator

baruch commented Oct 13, 2019

The logging is intended as an implementation-dependent placeholder, as such, we wouldn't want to complicate it too much and in fact, for our internal use we replace it and hook it up to our internal tracing facility. We expect others to do the same for their logging needs so if you want a runtime configurable logging you can implement it in your own logging facility and if you want it at compile time you can just implement null functions for the levels you don't want to care about.

Does that make sense?

@baruch baruch added the wontfix This will not be worked on label Oct 13, 2019
@jacob-carlborg
Copy link
Collaborator Author

for our internal use we replace it and hook it up to our internal tracing facility

That's what I thought.

We expect others to do the same for their logging needs.

The problem though is that there is no straightforward way to do this when using Dub. I haven't at least figured out a good way to do it. I'm guessing Weka doesn't used Dub.

It's also not clear what the interface need to be. I can read the existing implementation. DEBUG, INFO, WARN and ERROR are pretty clear. But META, what is that used for? Then there's LOG_EXCEPTION and LOG_TRACEBACK as well, which are also not as clear. Reading the implementation there's a level associated with each of the above mentioned functions. But it's not clear how to order the log levels. Usually in a logging framework it's possible to specify a severity level: anything below will not be logged but anything above will be logged. It's not clear how to do that with the given interface. Is META more or less severe than INFO? In the current implementation log level is basically only used to color the output, so the order doesn't really matter.

@SingingBush
Copy link

How about removing mecca.log and instead use std.logger which would make it convenient for users to either use one of the loggers provided in the standard library, implement their own, or use one of the dub packages that implement std.logger.core.Logger

@jacob-carlborg
Copy link
Collaborator Author

jacob-carlborg commented Oct 16, 2023

How about removing mecca.log and instead use std.logger

Hmm, I don't know. So far, IIRC, Phobos is not used in mecca. I feel it goes against the philosophy of mecca.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants