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

Used to have console color output, but not anymore. #1736

Closed
gamagan opened this issue Nov 18, 2020 · 1 comment
Closed

Used to have console color output, but not anymore. #1736

gamagan opened this issue Nov 18, 2020 · 1 comment

Comments

@gamagan
Copy link

gamagan commented Nov 18, 2020

Hi,
I upgrade from spdlog 0.16.4-rc, to 1.8.1 (Checked out from master, on 2020.11.18: #eebb921)
In the previous version, I was getting colored console output via 'spdlog::sinks::wincolor_stdout_sink_mt'.
After the upgrade, the console output is now black and white.

I was using the previous version as header only. The new version, I'm using as shared library.
I include the header like this:

#define SPDLOG_COMPILED_LIB 
#include "spdlog/spdlog.h"
...

This is all in Windows 10, 64bit. MSVC 2019, v16.8

Any ideas what I can try so that I can get color output back?

@gamagan
Copy link
Author

gamagan commented Nov 19, 2020

Please document somewhere whenever you make a semantic change to things. If something works one way, and then works a different way, you should write that, somewhere.

  1. In a pattern, %i used to mean sequence number. Now, is some delta time. When upgrading, that behabior goes from looking like sequence of numbers to random numbers.

  2. You used to be able to set a color, and that color would apply to the output line. Now, you have to set color delimiters to the formatter to take color into effect. Without the delimiters, set_color() is pointless.

  3. Before, you could create a list of sinks in an array, and create loggers based on that list, and set different patterns for the loggers. Now, the patterns are attached to the sinks, even though they are called like logger::set_pattern (why?!); so the effect is that the last pattern will override the previous ones, even though they are for different loggers, because they are attached to the sinks, not the loggers.

Imagine making a bunch of changes to your codebase, and upgrading the logging framework in the process, and then running into all 3 behavior changes. Of course, you'll blame your work code, and spend time chasing ghosts. That is very confusing.

@gabime gabime closed this as completed Nov 23, 2020
bachittle pushed a commit to bachittle/spdlog that referenced this issue Dec 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants