-
Notifications
You must be signed in to change notification settings - Fork 6
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
General file #9
General file #9
Conversation
Provides new function `log_stop`, which stops logging for one or all active log files. This is mostly useful for tests (need to start and stop logging multiple times to give the features a good workout) but might be useful for some workflows (e.g., logging within a particular part of a program). Not yet exposed to the user.
- generalises the approach by providing `log_file` and `log_connection` as two alternative ways to start logging (note that logging to a connection will likely be significantly faster than logging by appending to a file, even with flushing after each write). - generalises the writing approach to allow different "types" of destination to have different writing functions. - fixes some extra whitespace that was being added to log messages - adds a `subscriptions` argument to `log_file` to help with programmatically setting up logging (see issue TODO) This also required renaming the option `loggr_files` to `loggr_objects` (as they may not all be files). There's a subtle change of behaviour; I kept the behaviour of "console" the same (it runs through `cat(..., file="")` but "stdout" now runs through `cat(..., file=stdout())`. That has some weirdness with `capture.output` not working when I really feel that it should be - it's possible that something to do with the signal handling is doing something with the sinks.
Looking forward to looking at this! Thanks so far :) |
I looked through your changes and I think it looks promising. I added you as collaborator, so feel free to work on it (even pull this yourself). I won't have much time the next some days to work on it, but excited about getting this more mature. |
OK, thanks! I'm excited about using this for a bunch of long-running simulations, though that won't be for a month or so. I'll incorporate the changes from the other issues to this PR and give you a bit longer to look over this. Perhaps if you've not had time by the end of the week I can just merge then. |
Simplifes things quite a bit, passes tests without change. For #10
I like it. I have merged with small modifications here and there. But this is much better. I still wonder:
PS feel free to add yourself as aut to the DESCRIPTION, as you did a lot of this work! |
Great! I'm going to be using this a bunch next week so will get more feedback. I agree with both suggestions (avoiding suppressed messages/warnings and dropping I'll add myself to the DESCRIPTION soon. Thanks for the merge! |
I made an attempt at muffling muffled messages and warnings! It doesn't catch package startup messages though... regular messages and warnings seem to work fine. |
With apologies, there is quite a bit in here, and more to come if you would like (see issues)
I've broken those across a series of commits that should make it easier to decide what, if anything, you want to keep. I've lumped it all together as one PR so you can see the end result though.
The third commit is the biggest: it
log_file
andlog_connection
as two alternative ways to start logging (note that logging to a connection will likely be significantly faster than logging by appending to a file, even with flushing after each write).subscriptions
argument tolog_file
to help with programmatically setting up logging (see issue)This also required renaming the option
loggr_files
tologgr_objects
(as they may not all be files).There's a subtle change of behaviour; I kept the behaviour of "console" the same (it runs through
cat(..., file="")
but "stdout" now runs throughcat(..., file=stdout())
. That has some weirdness withcapture.output
not working when I really feel that it should be - it's possible that something to do with the signal handling is doing something with the sinks.Aim:
I want to be able to generate machine readable (e.g., JSON) logs directly into a database (in my case Redis) so that I can log on AWS where I don't expect to have access to the "machines" but do have access to the Redis instance. I'm going to use Redis as a broker for logstash I think.
I've tried to retain complete backward compatability with your interface, but have some questions about the design there. I have changed the customised initialisation string though; it is now the same across all connection types and does not indicate if the file is being started or appended to (though that is fairly obvious in the file itself).
Use with Redis
With the interface changes, I can now write this amount of support code (which I'd be happy to contribute) to set up the Redis inteface (designed to work with my
RedisAPI
package, but could be tweaked to work with the nakedRcppRedis
package)Then, to support json writing (this required no tweaks to your formatter interface which was really nice)
Then in use:
Ordinarily we'd do a
LPOP
orBLPOP
to pop things off the list.I've tried to match your style as much as possible; apologies for differences that remain.