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.
Related
Getting a syntax error and not sure why. Trying to loadca dataframe. Please can someone help. Thanks
If you are getting started with programming, jupyter can be counter intuitive at some points, I assume that's not your first cell in the notebook, so be sure to run the previous ones where the definition for titanic_df/titanic_csv is loaded.
The error you are getting says NameError, not SyntaxError, and it is informing you that a variable called titanic_csv does not exist.
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.
I call a matrix in my code and R tells me that the object was not found, although it clearly exists.
Of course I checked for spelling errors and the typical issues. However, when I run parts of the line, where the error occurs, it finds the object perfectly and prints it as requested. Requesting the object itself does not produce the error either, only running that line of code.
print(object) also works before and after that line.
The line with the issue is:
a[h,k]<<-switch(as.character(a[h,k]-1),"0"=-1,a[h,k]-1)
a is the problematic matrix. It is used within a function, but even when I run the line independent of the function, it doesn't work either.
a[h,k] and switch(as.character(a[h,k]-1),"0"=-1,a[h,k]-1) properly work by themselves.
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.
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).