-
Notifications
You must be signed in to change notification settings - Fork 130
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
Add Target::Pipe #195
Add Target::Pipe #195
Conversation
I can't reproduce the failed check locally and I also didn't change anything on the code that is failing. Plz help? |
It's |
Ah, I wasn't using the nightly version of |
You did the rebase the wrong way around (you should rebase your branch on top of master, not the other way around).
What do you mean by "not breaking too much"? The derived traits for |
By the way, thank you for working on this! |
Ups, I knew there was something wrong after at least the 5th git command, is it still worth trying to fix? ^^ |
It should be as easy as // if you haven't set up the remote yet, though I guess you have
git remote add upstream https://github.com/env-logger-rs/env_logger
git fetch upstream
// rebase your branch on top of upstream's master branch
git rebase upstream/master even now. (git should detect the duplicate commit on your branch and get rid of it) Followed by |
Now logs can be written to custom pipes and not just to stdout or stderr
Co-authored-by: Jonas Platte <[email protected]>
4e6919b
to
aebf1c2
Compare
I have tried myself on keeping the pipe in the I will try something that takes the value out of |
Forgot about it... again
I'm quite happy with this version as it breaks very little if anything at all and it feels like a simple extension of the old |
I can take a closer look an Tuesday, up until then I don't have enough time for a full review :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rest looks decent. Maybe @jplatte could look over again as he was the initial reviewer, and a second pair of eyes is always good ;)
That being said, sorry that it took me that long.
*/ | ||
|
||
#[macro_use] | ||
extern crate log; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2018 idoms, you should be able to just call use log::{info, error, warn};
. Is there a policy in-place for examples and what edition they should target? If not, I would use the newer syntax.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would agree that this should be changed, but all other examples are very similar and use this line. So a bulk change of all the examples would be better. Should I still change it?
Co-authored-by: SirWindfield <[email protected]>
Co-authored-by: SirWindfield <[email protected]>
Co-authored-by: SirWindfield <[email protected]>
thx @sirwindfield (also for fixing my typos ^^) |
I can have a second look, sure. Probably going to take a while for me as well. |
I've been playing around with this pr since I need support for logging to a file and this works great for my use case! I did have one question about the possibility of having multiple targets like stdout and a file. Is this something out of scope for the goals of this library or is it something that could be entertained ? |
(I'm just a contributor, not a maintainer) |
target_type: TargetType, | ||
target_pipe: Option<Arc<Mutex<dyn io::Write + Send + 'static>>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why split the target into two fields and introduce a new TargetType
type? I think target
can just be wrapped in Option
for the build
method to work (where you can then use self.target.take().unwrap_or_default()
to get the actual value).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did try that, because I would like it way more that way, too. But the Target gets passed (and cloned) everywhere (for color checking and the shim_impl
) that is why TargetType
needs Clone, Copy, Debug, Eq, Hash, PartialEq
implemented which is hard to impossible with dyn io::Write + Send + 'static
.
@@ -70,46 +71,72 @@ impl Formatter { | |||
|
|||
pub(in crate::fmt::writer) struct BufferWriter { | |||
inner: termcolor::BufferWriter, | |||
test_target: Option<Target>, | |||
test_target_type: Option<TargetType>, | |||
target_pipe: Option<Arc<Mutex<dyn io::Write + Send + 'static>>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain why Arc<Mutex<>>
is needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the pipe is still partly owned by the Builder
(it doesn't get deconstructed on build()
).
I'm still planning to have a look at this again, hopefully this or next week. |
Merged in #204. |
Now logs can be written to custom pipes and not just to stdout or stderr.
This is my take on #178.
I would be very happy to hear some feedback, since I'm quite unsure about a few changes:
std::sync::mpsc
used as a pipe for that?Builder::target_pipe
is my idea for not breaking too much, but maybe there is a solution to implement that intoBuilder::target
directly?Buffer
it is assumed that iftarget_pipe
isSome
,test_target
is alwaysNone
. Is there a better way to enforce that?