wlogsolutions/r-logging

R port of the popular log4j logging module

Travis	Total downloads	Downloads	CRAN version

r-logging

R port of the popular Python logging package.

It implements hierarchical logging, multiple handlers at a single logger, formattable log records...

What you find here behaves similarly to what you also find in Python's standard logging module.

Far from being comparable to a Python standard module, this tiny logging module does include

• hierarchic loggers,

• multiple handlers at each logger,

• the possibility to specify a formatter for each handler (one default formatter is given),

• same levels (names and numeric values) as Python's logging package,

• a simple basicConfig function to quickly put yourself in a usable situation...

• some sample handlers, sending log records

• to the console,

• to a file

for more information, have a look at the [online tutorial] (http://logging.r-forge.r-project.org/sample_session.php) on [r-forge] (http://r-forge.r-project.org/).

installation

Simply call

devtools::install_github("WLOGSolutions/r-logging/pkg")

r-logging's Issues

Print variables along with their name

I often find myself to write

logdebug("x: %s", x)

What do you think about supporting

logdebug(x)

as a shortcut? This should be accompanied by a parameter to explicitly turn on or off this behavior:

logdebug(msg, ..., logger='', print.name=!is.character(msg))

The same holds for all other debug levels, of course.

log level never considered under INFO level.

Whenever I try to lower the logging level from INFO (20), I'm never able to printout messages passed to logdebug, logfine, etc...

test case:

> library(logging)
> basicConfig("DEBUG")  # or something lower than 20
> getLogger()
Reference class object of class "Logger"
Field "name":
[1] ""
Field "handlers":
$basic.stdout
<environment: 0x9e23c8c>

Field "level":
DEBUG 
   10 
> loginfo("info")
2013-02-07 11:48:29 INFO::info # ok, as I expected...
> logdebug("debug") # ... shouldn't I see the debug message here?
> logReset() # let's see if at higher levels works
> basicConfig("ERROR")
> getLogger()
Reference class object of class "Logger"
Field "name":
[1] ""
Field "handlers":
$basic.stdout
<environment: 0x8d64934>

Field "level":
ERROR 
   40 
> loginfo("info")
> logwarn("warn")
> logerror("error")
2013-02-07 11:50:05 ERROR::error # no problems here.

The version I'm using through CRAN is 0.6-92, maybe I should update from here ;)

HTH,
Giuseppe

Dependency on Ruuid

Ruuid doesn't belong to the current release or devel version of Bioconductor anymore so I am getting errors when trying to install it on R 3.0.1. Should this dependency be removed since BioC seem to be deprecating it?

Louis

custom levels

from an email (Paul Roebuck, 2014-10-03)
can I add a custom level?

Desired processing follows...

R> addLevelName <- function(value, levelname) {
    stopifnot(is.numeric(value) && length(value) == 1)
    stopifnot(is.character(levelname) && length(levelname) == 1 && nzchar(levelname))
    names(value) <- levelname
    loglevels <<- sort(c(loglevels, as.integer(value)))
}

R> addLevelName(9, 'NUMBER9')
R> loglevels
  NOTSET   FINEST    FINER     FINE  NUMBER9    DEBUG     INFO
  WARNING     WARN    ERROR CRITICAL    FATAL 
  0        1        4        7        9       10       20
  30       30       40       50       50 

someone looks at the CRAN issues

https://cran.r-project.org/web/checks/check_results_logging.html

leading whitespace in msg

Hi, thanks for writing this logging package.

I just realised the leading whitespaces in a message are trimmed, I am not sure if it is a bug or a feature, but wonder if there's a way to preserve those whitespaces?

   R> loginfo("a")
   2016-08-30 16:43:51 INFO::a
   R> loginfo("     a")
   2016-08-30 16:43:55 INFO::a

Thanks

failing test in runit.data.interaction.R

the test test.recordIsEmitted.deepToRoot.DI.dropped fails with message:

Error in structure(function (value)  : 
  invalid replacement for field 'level', should be from 
  class "numeric" or a subclass (was class "NULL")

add a dry-run option to handlers

some handlers (specifically the sentryHandler) need check or load packages in order to run. or they might want to test for the presence of all needed parameters. it would be nice to have a dry-run option that informs the handler action not to do anything except check the environment.

So you would be able to follow the workflow:

• create the handler
• ask it whether it can function
• if yes, continue attaching it to a logger
• if no, take alternative measures

without this dry-run option, you are here:

• create the handler
• attach it to a logger
• when the handler is activated, fall in some error situation if things are not in order

What are the implications of log4j's recently revealed security vulnerability for r-logging and python's logging?

I was wondering to what extent r-logging and Python's logging could be affected or have related issues. It seems like the vulnerability is specific to Java, but thought it would be wise to ask here.

Thank you for your time,
Ravi B. Sojitra

using 'as.environment(NULL)' is defunct

from an email (Paul Roebuck, 2014-10-03)

this doesn't appear to work anymore (logging 0.7-103)...

R> setLevel(30, getHandler('basic.stdout'))
Error in as.environment(pos) : using 'as.environment(NULL)' is defunct

reference to futile package is broken

the futile package does not seem to be accessible for reference.
this causes a WARNING, which ends cluttering the package check.
since this is there only for historical reasons and I never had a look at futile after the first weeks while developing this package, I think we can safely remove the reference.

logging.logReset could keep the root logger

currently, logging.logReset destroys all content of the logging subsystem.
it could be less destructive by keeping the object representing the root logger.
this would enable scripts to rely on the pointer to the root logger also after the subsystem has been reset.

correct membership for 'mfrasca'

Hi there, I did what we (@ws171913 and myself) had agreed in issue transfer old issues to new repository (#10) in your fork, but since part of the plan included removal your fork, we also lost the discussion and description.
what we did:

• you made me part of your organization, which didn't prove sufficient, so you made me 'owner' of it.
• I merged your fork into my base repository
• removed your fork
• moved my base repository to your organization
• forked the repository into my user (as not to break links)

that's it.

I suppose you should now remove me from your organization.

add a rotating file handler

please add a rotating file handler
see http://stackoverflow.com/questions/4883272

this is relevant on windows, where you do not have logrotate and only in the cases where the solution at http://www.datori.org/?p=7 is not enough.

two failing tests in runit.handlers.R

both test.loggingToFile and test.loggingToFile.oo fail with the message:

Error in file(file, ifelse(append, "a", "w")) : 
  invalid 'description' argument

New named loggers should inherit ROOT logger level

Calling a logging function with a new named logger creates a new logger implictly, with level = INFO. Is this intended? I would suggest inheriting the level (and possibly the handlers etc) from logging.ROOT.

library("logging")
basicConfig(level = 0)

logdebug("test")
#> 2019-07-11 11:53:30 DEBUG::test

# Current, unexpected behaviour
logdebug("test", logger = "named_logger")
# No output

# Proposed behaviour: named loggers should use the root config by default.
logdebug("test", logger = "named_logger")
#> 2019-07-11 11:53:45 DEBUG::test

ls(logging:::logging.options)
[1] "logging.ROOT"              "logging.ROOT.named_logger"

In this example, I would have expected the logging.ROOT.name_logger to be set at DEBUG level.

This behaviour can be traced to how logging::getLogger creates loggers that are not yet in logging.options using level = namedLevel("INFO").

logging::getLogger <- function (name = "", ...) {
    if (name == "") {
        fullname <- "logging.ROOT"
    }
    else {
        fullname <- paste("logging.ROOT", name, sep = ".")
    }
    if (!exists(fullname, envir = logging.options)) {
        logger <- Logger$new(name = name, handlers = list(), 
            level = namedLevel("INFO"))
        updateOptions.environment(logger, ...)
        logging.options[[fullname]] <- logger
        if (fullname == "logging.ROOT") {
            .basic_config(logger)
        }
    }
    logging.options[[fullname]]
}

Failure on trying to log dates

Hey 👋

I noticed that logging started to fail when I pass dates:

loginfo(as.Date("2022-01-01"))
Error in as.Date.default(e) : 
  do not know how to convert 'e' to class "Date"

I think this happened once I upgraded R to 4.1.2 from 3.6.3.

Is that a known issue, or are we not supposed to pass dates anymore?

Thanks!

implement package function logging.shutdown

this function sounds useful: http://docs.python.org/2/library/logging.html#logging.shutdown

for example when you have a handler that is producing a log-file that has a prologue and an epilogue, you need to make sure that the epilogue section is written in all cases.

in Python, this is achieved having logging.shutdown invoke all .close methods of all registered handlers. we can do the same here. again the advantage of mimicking the behaviour of the Python library is that it is very well defined and clearly documented.