drakulix / simplelog.rs Goto Github PK

So write now I have it working were I can do info!("Some text");, but when I try and put a variable in here it won't compile. I have a vec that reads paths from a file, then it manipulates them and then deletes the paths. I want it to log the value of each vec[i] when going through a for loop. So you can have a list of the final paths that it tried to delete and weather it was successful full or not.

error: format argument must be a string literal.
--> src/main.rs:92:9
|
92 | info!(file_vec[i]);
| ^

error: aborting due to previous error

I am using :
simplelog = "^0.7.3"
and I am getting utc(?) time in the log file. My local time (Sweden) is currently +2 hours, so every log entry in the log file is two hours off. Is this by design, or is it something that I have failed to set up correctly?

I might be missing it in the documentation but is there a way to set the timezone? Looks like with the default configuration it only uses UTC which is fine from a dev perspective but may throw off users.

As a side note, would it be possible to get a clear example in the documentation for overriding the default configuration and using it for the logger?

Thanks for the good work on this.

A logger configured with any timezone related output format does not work.
No output can be seen on the terminal for a TermLogger.
No output is written to the logfile for a WriteLogger.

Example:

// Setup logging: Use local time in RFC3339 format
let log_config = LogConfigBuilder::new()
    .set_time_to_local(true)
    .set_time_format_str("%Y-%m-%dT%H:%M:%S%.3f%:z")
    .build();

As soon as I remove the last "%:z" the logger works as expected.

Tested version: 0.7.3
Version 0.5 and 0.6 work just fine with those format specifiers.

When logging from two different threads, statements written to stdout and stderr might become interleaved.

Example:

#[macro_use]
extern crate log;
extern crate simplelog;

use simplelog::{LevelFilter, SimpleLogger};

use std::{thread, time};

fn main() {

    let _ = SimpleLogger::init(LevelFilter::Debug, simplelog::Config::default());

    thread::spawn(move || {
        loop {
          info!("from thread 1");
        }
    });

    thread::spawn(move || {
        loop {
          error!("from thread 2");
        }
    });

    info!("starting");
    thread::sleep(time::Duration::from_millis(1000));
}

Example output:

19:51:07 [INFO] starting
19:51:07 [INFO] from thread 1
19:51:07 [INFO] from thread 1
19:51:07 [INFO] from thread 1
19:51:019:51:07 [INFO] from thread 1
7 [ERROR] from thread 2
19:51:07 [INFO] from thread 1
19:51:07 19:51:07 [INFO] from thread 1
[ERROR] from thread 2
1919:51:07 [INFO] from thread 1
:51:07 [19:51:07 [INFO] from thread 1
ERROR] from thread 2
1919:51:07 [INFO] from thread 1

I was hoping they were configurable, but:

I don't think this would be hard to add, so if you like the idea, I could make a pull request.

pub fn new(
    log_level: LevelFilter,
    config: Config,
    mode: TerminalMode,
    color_choice: ColorChoice // Was this breaking change really necessary?
) -> Box<TermLogger>

I've spent the last two hours cleaning up the damage from that undocumented change.

4d9de6c added a field to Config for offset. Unlike all other config options, this field is not Option. Consequently, users are required to specify this even if they want the same UTC default provided by Config::default().

This wouldn't be such a deal if it didn't mean users need to now add chrono to their declared dependencies in order to instantiate it (assuming I understand rust import semantics correctly...)

I'd love to be able to log ISO8601 timestamps so that I can see the date as well as the time.

Hi, this crate is a perfect low-overhead logger implementation I want.
However, from my point of view, human-readable logs should go to stderr instead of stdout.
Would it be possible to add some configuration to select stderr or stdout output for the crate?
Maybe through a cargo feature or via an init function?

not sure if i'm doing something wrong, but when I try:

# Cargo.toml
[package]
name = "test"
version = "0.1.0"
edition = "2021"

[dependencies]
simplelog = { version = "0.11", features = ["paris"] }

use log::info;

fn main() {
  simplelog::CombinedLogger::init(vec![
    simplelog::TermLogger::new(
      simplelog::LevelFilter::Debug,
      simplelog::Config::default(),
      simplelog::TerminalMode::Mixed,
      simplelog::ColorChoice::Auto,
    ),
    simplelog::WriteLogger::new(
      simplelog::LevelFilter::Debug,
      simplelog::Config::default(),
      std::fs::File::create("my_rust_binary.log").unwrap(),
    ),
  ])
  .expect("Failed to start simplelog");

  info!("I can write <b>bold</b> text or use tags to <red>color it</>");
}

it outputs: 02:33:51 [INFO] I can write <b>bold</b> text or use tags to <red>color it</>

The old TermLogger::new(LevelFilter::Warn, Config::default(), TerminalMode::Mixed), call with three arguments is shown in the Usage section.

Hello, first of all, thank you for this great crate.
Could it be possible to update the README documentation under the section "Getting Started", where it explains the dependency version? Saying that because the example in the section "Usage" does not work with v0.7.6 ;) but indeed works for the current version: 0.9.
Many thanks!
Cheers

I've used [email protected] and after bumping to the newest version, my logging levels get padded by default. Is this an intended change?

I'm trying to have a general log initializing function that I can share
between my binaries. However, it seems that terminal output does
not happen in this case, and I'm not sure why. Any clues on how I
can get this working so I get the logging both on the terminal and
in my logfile? Suffice to say, it works if I use the lib.rs code in my
binary directly, and not as an abstracted function in a crate.

lib.rs

use simplelog::*

pub fn init_logging(verbose: bool, log_path: &str) -> Result<(), log::SetLoggerError> {
    let debug_level = if verbose { LevelFilter::Debug } else {LevelFilter::Off };
    let logger_config = ConfigBuilder::new().set_time_format_str("%T%6.f").build();

    Ok(CombinedLogger::init(vec![
        SimpleLogger::new(debug_level, logger_config),
        WriteLogger::new(
            LevelFilter::Debug,
            Config::default(),
            std::fs::File::create(log_path).unwrap(),
        ),
    ])?)
}

bin/logme.rs

use log::debug;
use my_crate::init_logging;

fn main() -> Result<(), log::SetLoggerError> {
    init_logging(true, "/tmp/mylog.txt")?;
    debug!("I see this in my file but not on my terminal");
    Ok(())
}

I think there is something wrong with the level comparison in the new config. Previously I would set thread to 'None' to disable logging the thread number for all levels. Setting it to 'Off' with the config builder seems to enable it for all levels

Would you be open to the possibility to configure simplelog based on environment variables (like in
https://github.com/resamplr/rsynth/blob/9787b615098e815ee84ba6842948e5ee14db90c1/examples/test_synth.rs#L165-L213)? I can prepare a pull request for that, I just wanted to check if this is something that can be in scope of this crate.

I think file logging, which depends on sync read/write, is seemingly a blocking operation and it will starve the process?

I have a very basic systemd service with this logger in it:

[Unit]
Description=Rust Imap Server
After=network-online.target

[Service]
ExecStart=/home/marcel/rust/IMAPServer-rs/target/debug/IMAPServer
User=root
Group=root

Environment=RUST_BACKTRACE=1

Restart=on-failure
SyslogIdentifier=IMAPServer

[Install]
WantedBy=multi-user.target

It fails with:

Jun 29 08:34:17 riot.nordgedanken.de IMAPServer[9675]:    0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:    1: std::sys_common::backtrace::_print
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/sys_common/backtrace.rs:71
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:    2: std::panicking::default_hook::{{closure}}
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/sys_common/backtrace.rs:60
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/panicking.rs:355
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:    3: std::panicking::default_hook
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/panicking.rs:371
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:    4: std::panicking::rust_panic_with_hook
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/panicking.rs:549
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:    5: std::panicking::begin_panic
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/panicking.rs:511
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:    6: std::panicking::begin_panic_fmt
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/panicking.rs:495
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:    7: rust_begin_unwind
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/panicking.rs:471
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:    8: core::panicking::panic_fmt
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libcore/panicking.rs:69
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:    9: core::panicking::panic
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libcore/panicking.rs:49
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:   10: <core::option::Option<T>>::unwrap
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libcore/macros.rs:21
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:   11: IMAPServer::helper::init_log
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./home/marcel/rust/IMAPServer-rs/src/helper.rs:13
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:   12: IMAPServer::main
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./home/marcel/rust/IMAPServer-rs/src/main.rs:36
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:   13: std::panicking::try::do_call
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/panicking.rs:454
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:   14: __rust_maybe_catch_panic
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libpanic_unwind/lib.rs:98
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:   15: std::rt::lang_start
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/panicking.rs:433
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/panic.rs:361
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:              at ./checkout/src/libstd/rt.rs:57
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:   16: main
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:   17: __libc_start_main
Jun 29 08:34:18 riot.nordgedanken.de IMAPServer[9675]:   18: _start

The code that fails is:

pub fn init_log() {
    let mut config_dir = get_config_dir();
    config_dir.push("IMAP.log");
    CombinedLogger::init(vec![TermLogger::new(LogLevelFilter::Info, simplelog::Config::default()).unwrap(),
                          WriteLogger::new(LogLevelFilter::Debug, simplelog::Config::default(), File::create(config_dir.to_str().unwrap())
                          .unwrap())])
    .unwrap();
}

The failing code is the CombinedLogger line

Hi!
I really like use your simplelog as my main logger for projects :)
I am now experimenting with adding support for bold/italic and colors in my log messages.
I am not aware of this with the simplelog (correct me if I am wrong), so I am using an ansi_term crate for this.

The downsides of this approach:

1. A plenty of additional calls are needed, eg to make a text bold green I have to call:
   Style::new().bold().fg(Green).paint(err.to_string())
2. the writelogger is not aware of the control characters and put it "as is" in the files - making it less readable (this is currently also a problem when using some other crates which is using a colored text, eg rocket).

I want to ask what is your opinion to have in simplelog something similar as in paris, ie parser for the following:
log.info("<blue><on-bright-red> This text is blue on a bright red background</> it's a pain");
I am not sure if the above parsing is even possible when using error!, info! macros from rust...?

Is it in a scope of this project?

Summary

The dependency

term = { version = "0.5.1", optional = true }

brings transitively memoffset=0.2.1 that according to cargo audit:

ID:      RUSTSEC-2019-0011
Crate:   memoffset
Version: 0.2.1
Date:    2019-07-16
URL:     https://github.com/Gilnaa/memoffset/issues/9#issuecomment-505461490
Title:   Flaw in offset_of and span_of causes SIGILL, drops uninitialized memory of arbitrary type on panic in client code
Solution: upgrade to: >= 0.5.0

How to reproduce

cargo install cargo-audit
cargo new boom
cd boom
echo 'simplelog ="*"' >> Cargo.toml
cargo fetch
cargo audit

I just added logging to a simple application in about 10 minutes. Thanks for such having such clear documentation and a simple but flexible API.

After running cargo audit on my project, I got the following warning (Link to advisory) concerning this package's dependencies. Perhaps they should be implemented by replacing term with crossterm, termcolor, or yansi? I realize it would not be an easy fix since this dependency is likely important to simplelog's functioning.

Crate:         term
Version:       0.5.2
Warning:       unmaintained
Title:         term is looking for a new maintainer
Date:          2018-11-19
ID:            RUSTSEC-2018-0015
URL:           https://rustsec.org/advisories/RUSTSEC-2018-0015
Dependency tree:
term 0.5.2
└── simplelog 0.5.3

I noticed today that when using the default configuration output does not seem to match that shown in the examples. The levels with shorter character counts have a leading space which makes it look odd.

Using the slightly modified example from this repo:

use log;
use simplelog::*;

fn main() {
    TermLogger::init(LevelFilter::Trace, Config::default(), TerminalMode::Mixed).unwrap();

    log::error!("error");
    log::warn!("warning");
    log::info!("info");
    log::debug!("debug");
    log::trace!("trace");
}

I see the following output:

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/logdemo`
23:29:17 [ERROR] error
23:29:17 [ WARN] warning
23:29:17 [ INFO] info
23:29:17 [DEBUG] (1) logdemo: debug
23:29:17 [TRACE] (1) logdemo: [src/main.rs:11] trace

Can the leading space either be removed, or switched to a trailing space to make things look a bit cleaner? I think its there to help the lines look consistent but ends up looking weird as a leading space.

Hello.
It would be nice to have an option to remove the target from the logged message, or at least having a way to change it.
Thanks.

Can anyone else reproduce this error, or is it just me?
I create a new cargo project

Cargo.toml

[package]
name = "testing"
version = "0.1.0"
authors = ["Ammon Dodson <[email protected]>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
simplelog = "0.8"

main.rs

use simplelog::TestLogger;

fn main() {
    println!("Hello, world!");
}

Terminal:

ammon@PC-ammon:~/Desktop/dev/testing$ cargo check
    Updating crates.io index
   Compiling autocfg v1.0.1
   Compiling libc v0.2.79
   Compiling log v0.4.11
    Checking cfg-if v0.1.10
    Checking termcolor v1.1.0
   Compiling num-traits v0.2.12
   Compiling num-integer v0.1.43
    Checking time v0.1.44
    Checking chrono v0.4.19
    Checking simplelog v0.8.0
    Checking testing v0.1.0 (/home/ammon/Desktop/dev/testing)
error[E0432]: unresolved import `simplelog::TestLogger`
 --> src/main.rs:1:5
  |
1 | use simplelog::TestLogger;
  |     ^^^^^^^^^^^----------
  |     |          |
  |     |          help: a similar name exists in the module: `TermLogger`
  |     no `TestLogger` in the root

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `testing`.

To learn more, run the command again with --verbose.

Context

The examples (both in the documentation and in the README) for TermLogger initialization with TermLogger::new suggest to .unwrap() the result directly :

TermLogger::new(LevelFilter::Warn, Config::default(), TerminalMode::Mixed).unwrap(),

Issue

I recently had the surprise to see it failing. In short, it was in a CI environment where the TERM environment variable was not set, resulting in TermInfo::new failing, and thus term::stdout() and term::stderr() too. It took a while to debug mainly because TermLogger::new() was failing without any hint on why it was failing, may it be in the documentation or in the returned information.

Note: I don't use TermLogger::init() but I guess it is impacted by the same issue.

Fix

What would be the best fix there? Would it make sense to have TermLogger::new return a Result instead of an Option so it could convey more information in the returned Err ?

If this would be too much of a breaking change, I'll submit a PR on the documentation explaining why TermLogger::new() could return None.

I would like to have an other mode (have no good idea for the mode name) that does that - Warnings and Errors to stderr, everything else to stdout. TerminalMode::Mixed splits on Errors, this would split on Warnings.

I imagine I could implement it myself, if you would prefer that, and would accept a PR for it.

TermLogger::new return Option<Box>
WriteLogger::new return Box

The simplelog output is not captured by tests, due to capturing only happening on LOCAL_STDOUT.
The only way I'm aware of for writing to LOCAL_STDOUT, is using print!() and println!().

I suggest adding a dedicated logger for tests, to be able to use the stdout capturing feature.
https://github.com/AlexW-GH/simplelog.rs

Projects using simplelog are currently affected by RUSTSEC-2020-0159. There is also current discussion in the chrono repo about fixing the situation there: chronotope/chrono#499.

Still I was wondering how much of the chrono features simplelog actually relies on? chrono is based on time and the later caught up a lot on most of the same features chrono provides. Is it an option to cut out the chrono dependency entirely like many other crates do these days and use time directly?

The title points to https://docs.rs/simplelog.rs, which does not exist. Maybe you want to use https://docs.rs/simplelog instead.

Is it possible to pad module names? Alignment is kinda screwed up (because of different module names) when I log different modules

Sometimes I also don't need full module path. Just module name would be sufficient. Is it possible to customize this?

Line 66 /// Builder for the Logger Confogurations...

Either that, or I'm confused by the documentation.

For example, the documentation for set_max_level states that:

Set at which level and below the level itself shall be logged (default is Error)

Looking at the LevelFilter I have the impression that Off is the lowest level, while Trace is the highest, so set_max_level(Trace) should enable this for all levels. However, it seems to work in reverse.

use log::{debug, error, info, trace, warn};
use simplelog;
use simplelog::*;

fn main() {
TermLogger::init(LevelFilter::Trace,
    ConfigBuilder::new()
        .set_thread_mode(ThreadLogMode::Both)
        .set_max_level(LevelFilter::Trace)
        // Set everything else to `Off` so the output is simpler.
        .set_time_level(LevelFilter::Off)
        .set_thread_level(LevelFilter::Off)
        .set_target_level(LevelFilter::Off)
        .set_location_level(LevelFilter::Off)
        .build(),
    TerminalMode::Mixed).unwrap();
    trace!("This is a trace");
    debug!("This is a debug");
    info!("This is a info");
    warn!("This is a warn");
    error!("This is a error");
}

This outputs:

[TRACE] This is a trace
This is a debug
This is a info
This is a warn
This is a error

Setting the LevelFilter to Error display the level every time:

[TRACE] This is a trace
[DEBUG] This is a debug
[INFO] This is a info
[WARN] This is a warn
[ERROR] This is a error

The same is true for all other options. I'm not sure if this is a bug, because there seems to be a consistency between all the set_ methods, but things are not working as documented. This is especially confusing because the LevelFilter for init works as documented: if I change TermLogger::init(LevelFilter::Trace to TermLogger::init(LevelFilter::Warn I'm seeing only Warn and Error messages.

I'm also not sure about set_thread_mode which seems to behave a bit weird in regards to ThreadLogMode::Names:

fn main() {
    TermLogger::init(
        LevelFilter::Trace,
        ConfigBuilder::new()
            .set_thread_mode(ThreadLogMode::Names)
            .set_thread_level(LevelFilter::Error)
            .build(),
        TerminalMode::Mixed,
    )
    .unwrap();

    error!("This is a error from the main thread");

    let t = thread::Builder::new()
        .name("xxx".to_string())
        .spawn(move || {
            error!("This is a error");
        })
        .unwrap();

    t.join().unwrap();
}

This logs the thread IDs, but does not log the names. Using set_thread_level(LevelFilter::Trace) seems to have the same problem as the one described above.

Again, I'm not sure if this is a bug, or I'm simply misunderstanding the documentation.

cargo audit returns:

...

warning: 1 warning found

Crate:  term
Title:  term is looking for a new maintainer
Date:   2018-11-19
URL:    https://rustsec.org/advisories/RUSTSEC-2018-0015
Dependency tree:
term 0.6.1
└── simplelog 0.7.5
    └── audit 0.1.0

warning: 1 warning found!

reproduction:

cargo new audit
cd audit
echo 'simplelog ="*"' >> Cargo.toml
cargo fetch
cargo audit

using macOS

Looking at the documentation I did not see an option to disable colored output with TermLogger, so I decided to attempt to disable the default features. I did not realize this would then disable the usage of TermLogger completely. I have an option in my program to also log to a file, not just the terminal, and CombinedLogger does not seem to allow combining of SimpleLogger and WriteLogger.

Is there a way to disable colored output while using a CombinedLogger? Currently in some cases the colors can become unreadable, for example the blue text in a default colored Powershell window since it has a blue background.

Very small issue but the example in the Readme needs .unwrap() on the TermLogger.

TermLogger::new(LogLevelFilter::Warn, Config::default()),
=>
TermLogger::new(LogLevelFilter::Warn, Config::default()).unwrap(),

Is there a reason why the generic W for WriteLogger must be Send? The struct already moves the value in, and then wraps it in a Mutex. Mutex impls Send regardless of whether its encapsulated type is Send or not.

In the current version of simplelog, it seems that you need to unwrap the option containing a TermLogger when initializing the CombinedLogger

error[E0308]: mismatched types
   --> /home/jgoerzen/.cargo/registry/src/github.com-1ecc6299db9ec823/simplelog-0.7.1/src/loggers/testlog.rs:106:12
    |
106 |     if let Some(time) = config.time {
    |            ^^^^^^^^^^   ----------- this match expression has type `log::LevelFilter`
    |            |
    |            expected enum `log::LevelFilter`, found enum `std::option::Option`
    |
    = note: expected type `log::LevelFilter`
               found type `std::option::Option<_>`

error[E0308]: mismatched types
   --> /home/jgoerzen/.cargo/registry/src/github.com-1ecc6299db9ec823/simplelog-0.7.1/src/loggers/testlog.rs:112:12
    |
112 |     if let Some(level) = config.level {
    |            ^^^^^^^^^^^   ------------ this match expression has type `log::LevelFilter`
    |            |
    |            expected enum `log::LevelFilter`, found enum `std::option::Option`
    |
    = note: expected type `log::LevelFilter`
               found type `std::option::Option<_>`

error[E0308]: mismatched types
   --> /home/jgoerzen/.cargo/registry/src/github.com-1ecc6299db9ec823/simplelog-0.7.1/src/loggers/testlog.rs:118:12
    |
118 |     if let Some(thread) = config.thread {
    |            ^^^^^^^^^^^^   ------------- this match expression has type `log::LevelFilter`
    |            |
    |            expected enum `log::LevelFilter`, found enum `std::option::Option`
    |
    = note: expected type `log::LevelFilter`
               found type `std::option::Option<_>`

error[E0308]: mismatched types
   --> /home/jgoerzen/.cargo/registry/src/github.com-1ecc6299db9ec823/simplelog-0.7.1/src/loggers/testlog.rs:124:12
    |
124 |     if let Some(target) = config.target {
    |            ^^^^^^^^^^^^   ------------- this match expression has type `log::LevelFilter`
    |            |
    |            expected enum `log::LevelFilter`, found enum `std::option::Option`
    |
    = note: expected type `log::LevelFilter`
               found type `std::option::Option<_>`

error[E0308]: mismatched types
   --> /home/jgoerzen/.cargo/registry/src/github.com-1ecc6299db9ec823/simplelog-0.7.1/src/loggers/testlog.rs:130:12
    |
130 |     if let Some(location) = config.location {
    |            ^^^^^^^^^^^^^^   --------------- this match expression has type `log::LevelFilter`
    |            |
    |            expected enum `log::LevelFilter`, found enum `std::option::Option`
    |
    = note: expected type `log::LevelFilter`
               found type `std::option::Option<_>`

error[E0599]: no method named `unwrap_or` found for type `std::borrow::Cow<'static, str>` in the current scope
   --> /home/jgoerzen/.cargo/registry/src/github.com-1ecc6299db9ec823/simplelog-0.7.1/src/loggers/testlog.rs:144:44
    |
144 |         cur_time.format(config.time_format.unwrap_or("%H:%M:%S"))
    |                                            ^^^^^^^^^

error: aborting due to 6 previous errors

Builds fine without test feature... but I need that feature

When using the minimally requested version, chrono 0.4.0 is used which in turns requires num 0.1.0 which does not compile anymore:

   Compiling num v0.1.0
error: expected identifier, found keyword `mod`
  --> /home/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/num-0.1.0/src/bigint.rs:66:16
   |
66 | use std::str::{mod, FromStr};
   |                ^^^ expected identifier, found keyword

Chrono dependency must be bumped to at least 0.4.1. You can test this using cargo-edit and the command cargo update -Z minimal-versions. I suggest adding this to the CI as well.

PR pending.

currently TermLogErroris private, that way i cannot call init and parse the result, or convert TermLogErrorto a project specific error, and so on.
is there a special reason for that?

Hi! A new major version of log was released, and simple log is not compatible with it.

I am not sure what's the proper way to update simplelog though: simplelog reexports LogLevel and LogLevelFilter from log, but these are the structures which got changed (now they are log::Level and log::LevelFilter).

Is the ability to select whether to log to stdout vs stderr something you consider within the scope of simple log? If so it would be helpful for me. I use simplelog a lot for little terminal utilities, and I'd like the ability for stdout to be the output of the program, with stderr remaining the log output, so I can pipe them into eachother. I'd be willing to take a crack at it.

Tokio spams my log how can I prevent that?

Maybe I'm doing something wrong. Not sure, but when I'm using a debian docker image with my rust binary and simplelog, I get this error message. See code and trace below.

Everything works just fine, when not using docker in non-interactive mode. I'm not sure, if the library should handle the case, when something is running non-interactive?

CombinedLogger::init(vec![
        TermLogger::new(log_level, simplelog::Config::default()).expect("Could not init TermLogger"),
    ]).expect("Could not init CombinedLogger");

thread 'main' panicked at 'Could not init TermLogger', libcore/option.rs:1000:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:477
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:391
   6: rust_begin_unwind
             at libstd/panicking.rs:326
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::option::expect_failed
             at libcore/option.rs:1000
   9: bernard::main
  10: std::rt::lang_start::{{closure}}
  11: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  12: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:103
  13: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  14: main
  15: __libc_start_main
  16: _start

It would be great if https://github.com/Drakulix/simplelog.rs/blob/master/src/loggers/logging.rs#L56 were able to use a custom formatting string to align or pad the level so that ERROR & INFO etc would neatly align the first character of their messages, for skimming over a large amount of output…

Luckily the log crate supports this already by using fmt.pad in the right place https://github.com/rust-lang-nursery/log/blob/master/src/lib.rs#L488

16:43:30 [INFO] stalling ‘Batch 00334’ < Stalled(3, 66) 2019-05-10T17:22:15Z >
16:43:30 [DEBUG] finished process queue.
16:43:30 [INFO] queueing state for next time

vs {: >5}

16:43:30 [ INFO] stalling ‘Batch 00334’ < Stalled(3, 66) 2019-05-10T17:22:15Z >
16:43:30 [DEBUG] finished process queue.
16:43:30 [ INFO] queueing state for next time

Hi Victor,
I think it is sometimes desirable to log times using a local timezone instead of UTC:

Can you make it configurable somehow?