I cannot use save_kable() to save tables created with knitr::kable() and knitr::kableExtra as images. It looks like this is due to PhantomJS being blocked by admins. Is there another function that could help me save them? This is the error i get:
Error in process_initialize(self, private, command, args, stdin, stdout, …: ! Native call to processx_exec failed Caused by error in
chain_call(c_processx_exec, command, c(command, args), pty, pty_options, …: ! create process
'C:\Users\user1\AppData\Roaming/PhantomJS/phantomjs.exe' (system error
1260, This program is blocked due to group policy. Contact the systems responsible person for more information. )
#win/processx.c:1040 (processx_exec)
PD: I translated to English the message that comes after "system error 1260...".
Related
I am using tryCatchLog and want to send all warnings and error messages to a log file. I do not want any output to the console.
In the documentation for tryCatchLog I came across this code snippet:
library(futile.logger)
# log to a file (not the console which is the default target of futile.logger).
# You could also redirect console output into a file if start your R > script with a shell script using Rscript!
flog.appender(appender.file("my_app.log"))
The vignette for tryCatchLog includes the following code snippet to change the logging behavior and send errors to a file instead of the console:
library(futile.logger)
flog.appender(appender.file("app.log"))
flog.threshold(ERROR) # TRACE, DEBUG, INFO, WARN, ERROR, FATAL
try(log(-1)) # the warning will not be logged!
This suggests to me that I can simply re-direct the messages to a log file using flog.apppender(appender.file()). However, instead of writing to a file I get the following output on the console:
NULL
NULL
Warning in log(-1) : NaNs produced
[1] NaN
The vignette for tryCatchLog provides this code example in the Best Practice section:
library(futile.logger)
library(tryCatchLog)
options(keep.source = TRUE) # source code file name and line number tracking
options("tryCatchLog.write.error.dump.file" = TRUE) # dump for post-mortem analysis
flog.appender(appender.file("my_app.log")) # to log into a file instead of console
flog.threshold(INFO) # TRACE, DEBUG, INFO, WARN, ERROR, FATAL
tryCatchLog(source("your_main_script.R"))
Adapting the last line of code to tryCatchLog(log("this will produce an error")) to make the example easier, I am still not writing to a log file but to the console:
NULL
NULL
Error in log("this will produce an error") : non-numeric argument to mathematical function
Looking at the documentation of futile.logger and examples on stackoverflow also did not help me. Based on them, I thought the following should write the error message to a file. I am using try() as a stand-in for more involved versions of tryCatchLog() to make sure that it is not an issue with tryCatchLog.
library(futile.logger)
flog.appender(appender.file(file.path(getwd(),'logs.txt')))
flog.threshold(WARN) # TRACE, DEBUG, INFO, WARN, ERROR, FATAL
try(log(-1)) # this will create a warning
try(log("this will create an error")) # this will create an error
The command neither creates a log file nor appends an existing one.
Instead, flog.appender() and flog.threshold() return NULL (to the console). And the warning and error message are also printed to the console. Presumably, I am missing something when linking the logger to the file (hence the NULL return value?).
How can I redirect all warnings and errors caught by tryCatchLog to a file (with futile.logger) without ANY output to the console?
The output of try() has nothing to do with futile.logger().
If you configure a file appender in futile.logger you still have to write your log output using the flog.* functions (that's how logging works):
library(futile.logger)
flog.info("this is an info log output")
# INFO [2021-12-08 19:51:13] this is an info log output
flog.warn("this is an warning log output")
# WARN [2021-12-08 19:51:14] this is an warning log output
flog.error("this is an error log output")
# ERROR [2021-12-08 19:51:14] this is an error log output
I guess what you want is kinda output redirection of the standard or error output (eg. via capture.output) but this function does not add logging information like a timestamp and does not support severity level management ("info", "warn", "error"...).
If you want to use try*() in combination with logging you can use the CRAN package tryCatchLog which does exactly what you want (and supports futile.logger too):
library(tryCatchLog)
tryLog(log(-1)) # this will create a warning
tryLog(log("this will create an error")) # this will create an error
Connecting Excel with 'ABC' throught Excel works, connecting R with Excel by DDE works also, but how to connect R with 'ABC' application ?
I have application providing DDE interface, from Excel I could retrieve value from it with this DDE reference :
='ABC'|DDE!_nazwa_value
from R I've tried to use tcltk2 library, as follows :
tcltk2::tk2dde.request(service="ABC", topic="DDE", item="_nazwa_value")
but error occurs :
Error in structure(.External(.C_dotTcl, ...), class = "tclObj") :
[tcl] remote server cannot handle this command.
[1] "Error in structure(.External(.C_dotTcl, ...), class = \"tclObj\") : \n [tcl] remote server cannot handle this command.\n\n"
attr(,"class")
[1] "try-error"
attr(,"condition")
<simpleError in structure(.External(.C_dotTcl, ...), class = "tclObj"): [tcl] remote server cannot handle this command.
I'm only trying to use tcltk dde functions to retrieve data from application, I think that item part of my tk2dde.request is wrong, but I've tried various modification (without _ for example), do you know any clues or resources for solving this problem ?
EDIT
something is wrong I don't see ABC server nor DDE topic on server-topic list :
tk2dde.services() but Excel can still connect and retrieve value using ='ABC'|DDE!_nazwa_value, DDE Query also do not see it
You can read in the article about DDE in tcl/tk wiki:
(Talking about using Internet Explorer) ... All of the above experiments should "work" reliably, in that, from the user perspective, IE indeed acts as described. However, back in the Tcl process, [dde] typically throws a "remote server cannot handle this command" exception. That's because, in KBK's analysis, DDE gives no "way to distinguish 'result expected, but the server failed to provide it' from 'no result is expected'." The only way not to receive a DMLERR_NOTPROCESSED is to invoke "dde exec -async ..."
Note: i tried tcl examples of DDE using Excel + "request" and i got the same error as you: "remote server cannot handle this command".
Saludos!,
I get the following error while attempting to use the "save hook" functionality in Bosun -
failed to call save hook: fork/exec /tools/bosun/bin/save-hook: exec format error. Restoring config: successful
The file is executable and I've removed all logic from it, and the error still occurs.
Should the file return anything? Or is this a bug?
The documentation indicates it should be successful as long as the hook exits ok.
https://bosun.org/system_configuration#commandhookpath
I would guess the OS is not accepting this as a proper executable?
If a binary, did you compile it on the same system, or make sure your cross compiled it for the right architecture?
If a script, does your script have the bang line at the start, for example #!/bin/bash?
I am asking this question out of curiosity. I have noticed that whenever I boot R, the instance starts up with this error message
As you can see, R boots with the error message "object 'a' not found" Is there any reason for this?
R reads and executes several files at startup, most prominently the ~/.Rprofile file (That is, the file .Rprofile in your home directory). Check these files to see if they contain anything weird.
You can quickly check whether .Rprofile is the culprit by running R with the --vanilla command line argument: this argument prevents the user profile to be read, thus the error should vanish.
I've often been frustrated by R's cryptic error messages. I'm not talking about during an interactive session, I mean when you're running a script. Error messages don't print out line numbers, and it's often hard to trace the offending line, and the reason for the error (even if you can find the location).
Most recently my R script failed with the the incredibly insightful message: "Execution halted." The way I usually trace such errors is by putting a lot of print statements throughout the script -- but this is a pain. I sometimes have to go through the script line by line in an interactive session to find the error.
Does anyone have a better solution for how to make R error output more informative?
EDIT: Many R-debugging things work for interactive sessions. I'm looking for help on command-line scripts run through Rscript. I'm not in the middle of an R session when the error happens, I'm at the bash shell. I can't run "traceback()"
Try some of the suggestions in this post:
General suggestions for debugging in R
Specifically, findLineNum() and traceback()/setBreakpoint().
#Nathan Well add this line sink(stdout(), type="message") at the beginning of the script and you should get in console message both script content and output along with error message so you can see it as in interactive mode in the console. (you can then also redirect to a log file if you prefer keeping the console "clean")
Have a look at my package tryCatchLog (https://github.com/aryoda/tryCatchLog).
While it is impossible to improve the R error messages directly you can save a lot of time by identifying the exact code line of the error and have actual variables at the moment of the error stored in a dump for "post mortem" analysis!
The main advantages of the tryCatchLog function over tryCatch are
easy logging of errors, warnings and messages into a file or console
warnings do not stop the program execution (tryCatch stops the execution if you pass a warning handler function)
identifies the source of errors and warnings by logging a stack trace with a reference to the source file name and line number (since traceback does not contain the full stack trace)
allows post-mortem analysis after errors by creating a dump file with all variables of the global environment (workspace) and each function called (via dump.frames) - very helpful for batch jobs that you cannot debug on the server directly to reproduce the error!
This will show a more detailed traceback, but not the line number:
options(error = function() {traceback(2, max.lines=100); if(!interactive()) quit(save="no", status=1, runLast=T)})
One way inside a script to get more info on where the error occurred is to redirect R message to the same stream as errors :
sink(stdout(), type="message")
This way you get both messages and errors in the same output so you see which line raised the error...