During a process, I need to copy a directory using fs::dir_copy(currentPath, newPath). Some of the time, I get the following error message:
Error in link_copy(links, path(new_path[[i]], path_rel(links, path[[i]])), :
all(is_link(path)) is not TRUE
This only happens some of the time, not always. What's more, if I replace my directory with a manual copy of itself (i.e. manually copy directory, delete original, rename the copy), then my code will work.
Could someone please explain why this could be happening? Is there a way I can sidestep that error once and for all?
This does not answer your question but may help you to further analyse what is going on. One of the great things of R is that you can easily inspect source code. Especially in a situation where unusual things appear to happen, looking at the code may be useful.
In your case, we can inspect the source code of fs::dir_copy and trace back to which code generates the error message. If you type fs::dir_copy (no parenthesis) into the console, R will print the R code of the function (if the function is not primitive). Doing that here will show you that the fs:dir_copy function calls the fs::link_copyfunction. Makes sense, as the error message comes from this function.
We can now print this function with fs::link_copy
This function generates the error message in this line:
stopifnot(all(is_link(path)))
From the error message we know that all(is_link(path)) returns FALSE. Next step is to have a look at the fs::is_link function. Here we see that the error may come from the call to the setNames function, which depends on the fs::file_info function: res <- file_info(path)
Here we see that setNames is called with a condition depending on what the file_infofunction returned:
setNames(!is.na(res$type) & res$type == "symlink", res$path)
This looks unusual as setNames takes an object and a character vector as formals. But then, I am not the developer of these functions ;-)
Perhaps there are issues with the file type on your machine and fs::file_info(path) returns something unexpected under some conditions.
Related
When working in RStudio (version 0.99.482 and 1.0.136), if I source a file and an error occur I just get the error message without any context. If the file is longer than a few lines of code, that informaiton is largely useless. What I want to know when an error occurs is the following:
What function threw the error? Preferably what function I called from my script, not something burried deep inside a package.
On what line of my file did the error occur?
This seems like a very basic thing for a scripting language to do, but yet I am unable to find an easy solution. Yes, I am aware of the traceback() function, but (a) it is a hassle to call it every time there is an error, and (b) the output is massive and not that helpful.
I have a chunk of code which produces an error only the first time I run it. Strangely if I run it a second time I get no error (craziness definition?). Also the error does not show up always at the same position, I mean that if I add a few lines of comments the error message is printed after the comments and not after a specific instruction.
I cannot provide a reproducible example because I do not know where exactly the error comes from. The error is the following:
Error in names(frame)[names(frame) == "x"] <- name :
names() applied to a non-vector
I should specify that in my code I don't have -at least explicitly- a names() function.
This is a tricky error. I was able to track down the reason and it seems to be that R has an object of the same name as the function cached. This is most likely if using an IDE such as RStudio a tab for View(df). Unless the tab is closed even running the function without code will give you this error. Likewise, if the tab is not closed not even removing all objects or doing a garbage collection will solve it. Once the tab is closed the error will be gone.
I had the same error, and It was faulting on a particular function that I wrote. It was throwing the error whenever I loaded the function, even when the I commented out all the code in the function. I found that changing the variable name of my function stopped the error. My only guess is that there is some weird variable name conflict.
I had the same error. The reason for it is something related to a file I saved long ago with the name "df", which is interfering with a current variable, also called df.
The solution however is straigthforward: Find the problematic line, by running the first line of the code, then clearing the global environment, and running it again. If no error occurs, add the next line, and so forth until the error occurs. Then, change the name of the variable in that line.
Even I had the same error. The reason in my case was that there was another data frame with the same name as the function inside the function. I guess R throws this error when there is a type mismatch as well. In my case the name was first read as a function. When R came across the same name again, it would be looking for a function but instead found a data frame.
All I had to do was change the name of one of them and the error was gone.
This error also appears in my code everytime when I tried to delete everything through remove(list = ls()). In my case the problem was, that I had an object named df (datatype = data.frame) and also had the View opened of a previous version of df. After closing the View the error disappeared.
Just add
as.vector(dataframe)
This works.
I have a very odd problem. I designed a function a while back that has arguments defined as follows:
elisa<-function(
file="data.csv",
Out=paste("Elisa Analysis",Sys.time(),".xlsx"),
wd="~/Desktop",
out.folder=wd,
Rep=2,
standards=c(1,2),
orient="horizontal")
{
As you can see above, wd is defaulted to the value of the desktop, and out.folder is defaulted to the value of wd. This is so that users can specify where an output excel document goes separately from where the working directory is, but the default is that they are the same. What is weird is that I have used this function for a while, and I have several users who use this exact code (I installed it on their CPUs, and so I know that it is the exact same), and it works fine for them, but suddenly on my computer it is not working. It gives the following error when I run the function.
Error in setwd(out.folder) : object 'wd' not found
This is odd for a number of reasons. The first is that if I remove the functional enclosure and run the exact same code "naked," the code works just fine. The object wd is definitely still present by the time it gets to the line of code being referenced, which is simply just
setwd(out.folder)
Moreover, out.folder has the same definition as wd. What is even weirder is that if you read the error code, it doesn't say that out.folder is not defined or the object isn't found. It says that the other object, wd, is not found, which is odd because out.folder should have just been set to the value
"~/Desktop"
I am at a loss. A line of code early in the function uses wd just fine, but the error occurs hundreds of lines farther down at the line of code specified. If I remove it, everything functions fine, and if I run the function without the functional enclosure, everything functions fine.
Anybody have any clue what is going on?
Sample (only lines involved since the full code is so large it won't let me post it here)
elisa<-function(
file="data.csv",
Out=paste("Elisa Analysis",Sys.time(),".xlsx"),
wd="~/Desktop",
out.folder=wd,
Rep=2,
standards=c(1,2),
orient="horizontal")
{
setwd(wd)
setwd(out.folder)
setwd(wd)
}
I have found a way around it. This is really interesting. If you state the argument explicitly the same way as the default argument, the function won't work. In other words,
elisa(...,out.folder=wd)
will throw an error even though it is the default argument format. If you omit it when doing the function call, the function works, or if you give it the same value as wd without going through wd as an intermediary, it works. In other words,
elisa(...,wd="~/Desktop",out.folder="~/Desktop",...)
and
elisa(...,wd="~/Desktop",...)
both work. You just can't do
elisa(...,wd="~/Desktop",out.folder=wd,...)
even though the definition of the function arguments is
elisa<-function(
file="data.csv",
Out=paste("Elisa Analysis",Sys.time(),".xlsx"),
wd="~/Desktop",
out.folder=wd,
Rep=2,
standards=c(1,2),
orient="horizontal")
It makes no sense, but that's the way around it.
After poking around on the internet I wasn't able to find anyone who had written a quine in R (Edit: since writing this, have found several on SO, but am still interested in this one). So I figured I'd try my hand at coming up with one myself. My result was the (surprisingly short) code:
function(){}
which will output function(){} when run. This takes advantage of the fact that a function name without parens or arguments after it will return the function's source code.
However, a program that "looks at itself" is not generally considered a true quine. There are two things I realized I don't understand in the course of trying to decide whether I'd written a "real" quine: (1) What constitutes a program "looking at itself" (from a quine standpoint) beyond use of file i/o and (2) the extent to which function(){} (or similar commands like logical(0)) are self referential when they print themselves. The former seems to be too subjective for SO, but I was hoping for some clarification on the latter. So...
When I run function(){}, what exactly is happening that causes it to print its own "source code"? For example, is R loading an empty function into a local environment, evaluating that function, and then looking back at the code that defined it to print? Or, is it just looking at function(){} and echoing its definition right away? Is there a fundamental difference between this and
f<-function(){cat("f<-");print(f);cat("f()")}
f()
in terms of how they both print themselves when run?
You don't completely get what's going on here. Actually, the code
function(){}
doesn't do anything apart from constructing a function without arguments and body, returning it and deleting it immediately after it's returned. Its output would be NULL, so doesn't "recreate itself".
The output you see in the console, is not the output given by function(){} but by print.function. This is the S3 method that takes care of showing a function object in the console. What you actually do, is:
a <- function(){}
print(a)
rm(a)
A true R quine would be something like this:
m<-"m<-0;cat(sub(0,deparse(m),m))";cat(sub(0,deparse(m),m))
See also Wikipedia for this and other examples
This is not a true quine as it does not print anything to stdout. Whole point of Quine is that it can reproduce itself by printing. Program must create a new file or output in stdout containing its exact code.
Example of a javascript quine would be:
(function a(){console.log(`(${a}())`)}())
(function(x) print(substitute(x(x))))(function(x) print(substitute(x(x))))
I have a longer, complex code (>7000 lines) with many nested functions, each of them enclosed in a separate tryCatch. The code works perfectly except for a "pseudo-error":
Error in doWithOneRestart(return(expr), restart): no function to return from, jumping to top level
doWithOneRestart() is internal in R as an element of the tryCatch function. I call it "pseudo-error", because the tryCatch should lead to stop() if an error ocurrs and write the error message in a log file. Instead, this "error" is not stopping the program (actually not influencing it at all) and it is shown only on the console and not written into the log file. Usual debugging procedures did not help, because the error is not reproducible (!): it may ocurr at different processing stages of the program. Changing the warning options to 0 or -1 will not help.
Since the program does the job, this error is not critical. But I would like to understand what is happening. Maybe someone has already experienced the same problem, or could come up with an original debugging strategy ...
Update (28.10.2013):
I found out where the problem came from. It's linked to a problem with java heap overflow (I was using the xlsx package to read Excel files). Among many other problems: although the connection to the Excel file is closed (definitely!), the system considers it as an unused connection (shown in traceback()), tries to close it, but finds out it is already closed: you get the "pseudo-error" described above, and never exactly at the same moment (not reproducible). Using the garbage collector gc() at the right place solved the problem. The script is now running stable for several days.
Advice from Peter Dalgaard on R-help.
The easiest way to get that message is to execute return() from the
top level:
return(1)
You might be trying to return() from source()d file. Or maybe
source()ing something that was intended to be inside a function body
(extraneous '}' characters can do that).
The usual debugging strategies should work: calling traceback() after the error, or setting options(error = recover).