Pecan: Basieren Sie `PEcAn.logger` auf nativen R-Funktionen

Der Hauptgrund war eine einfache Möglichkeit, Nachrichten in einer Datei zu sammeln. Wie wäre das mit Meldung, Warnung und Stopp?

Die gesamte Protokollierung würde also genauso funktionieren wie jetzt, wenn das Paket PEcAn.logger geladen ist. Es ist nur nicht mehr erforderlich, die Protokollierungsfunktionen zu verwenden. Was ich effektiv vorschlage, ist:

# These call the default R functions
message("hello")
warning("whoops")
stop("whoah")

library(PEcAn.logger)
# By loading the logger package, the functions become masked so
message("hello")      # This actually calls `PEcAn.logger::logger.info
warning("whoops")   # This calls `PEcAn.logger::logger.warn
stop("error")      # This calls `PEcAn.logger::logger.severe

Daher sollten alle gleichen Funktionen zum Einstellen des Logger-Levels, der Ausgabedatei usw. auf die gleiche Weise funktionieren.

Nebenbei bemerkt, message , warning und stop Basis R können selektiv über sink umgeleitet werden.

Umbenennungen sind zu lang: Ich würde es vorziehen, Aliase zu exportieren, die den überflüssigen Teil logger.* weglassen, zB PEcAn.logger::info() . Alles, was darüber hinausgeht, kommt wieder in die Auseinandersetzung zwischen Namespaces und library -Aufrufen zurück.

Bezüglich der Ungeschicklichkeit mit Funktionen wie expect_error oder suppressMessages : Der große zugrunde liegende Unterschied besteht darin, dass PEcAn.logger nicht den formalen Zustandssignalisierungsmechanismus von R verwendet und daher mit jeder Funktion umständlich zu verwenden ist das erwartet ein condition . Wenn PEcAn.logger überarbeitet werden kann , um Bedingungen zu verwenden, würde ich das bevorzugen, aber ich bin auch nicht mit der Geschichte hier vertraut - @robkooper , vermied signalCondition eine absichtliche Designentscheidung / notwendig zu handhaben einige Weiterleitungsfälle?

Nachdem ich noch etwas darüber nachgedacht habe, stimme ich zu, dass mein Ansatz keinen Sinn ergibt und nicht wirklich funktionieren würde. Persönlich würde ich wahrscheinlich lieber die Standardfunktionen von R verwenden ( stop , warning , message ) und sie bei Bedarf über sink umleiten, aber ich kann sehen der Grund dafür, bei PEcAn.logger zu bleiben. Eine andere Möglichkeit ist der Wechsel zu futile.logger , was bereits vorgeschlagen wurde (#1362).

In der Zwischenzeit gefallen mir beide Vorschläge von @infotroph – kürzere Aliase und Signalisierungsbedingungen hinzuzufügen.

Eine weitere vielversprechende Idee ist das Paket debugme , das folgende Syntax bietet:

f <- function(a, b = 3) {
  c <- a + b
  d <- a * b
  e <- a ^ b
  "!DEBUG arguments are a = `a` and b = `b`"
  c(c, d, e)
}

Diese Ausgabe ist veraltet, da sie 365 Tage lang ohne Aktivität geöffnet war.

Siehe auch Diskussion in #1362