I was updating the packages in my emacs 25.0.50 build. And for some reason it didn't work properly. When I restarted emacs I received the following fatal error message:
error: Recursive load, /usr/local/Cellar/emacs/HEAD/share/emacs/25.0.50/lisp/emacs-lisp/cl-extra.elc, /usr/local/Cellar/emacs/HEAD/share/emacs/25.0.50/lisp/emacs-lisp/bytecomp.elc, /Users/Maurice/.emacs.d/elpa/seq-2.15/seq-25.elc, /Users/Maurice/.emacs.d/elpa/seq-2.15/seq.elc, /usr/local/Cellar/emacs/HEAD/share/emacs/25.0.50/lisp/emacs-lisp/cl-extra.elc, /usr/local/Cellar/emacs/HEAD/share/emacs/25.0.50/lisp/emacs-lisp/bytecomp.elc, /Users/Maurice/.emacs.d/elpa/seq-2.15/seq-25.elc, /Users/Maurice/.emacs.d/elpa/seq-2.15/seq.elc, /usr/local/Cellar/emacs/HEAD/share/emacs/25.0.50/lisp/emacs-lisp/cl-extra.elc, /usr/local/Cellar/emacs/HEAD/share/emacs/25.0.50/lisp/emacs-lisp/bytecomp.elc, /Users/Maurice/.emacs.d/elpa/seq-2.15/seq-25.elc, /Users/Maurice/.emacs.d/elpa/seq-2.15/seq.elc, /usr/local/Cellar/emacs/HEAD/share/emacs/25.0.50/lisp/emacs-lisp/cl-extra.elc, /usr/local/Cellar/emacs/HEAD/share/emacs/25.0.50/lisp/emacs-lisp/bytecomp.elc, /Users/Maurice/.emacs.d/elpa/seq-2.15/seq-25.elc, /Users/Maurice/.emacs.d/elpa/seq-2.15/seq.elc, /usr/local/Cellar/emacs/HEAD/share/emacs/25.0.50/lisp/emacs-lisp/cl-extra.elc, /Users/Maurice/.emacs.d/core/prelude-packages.elc, /Users/Maurice/.emacs.d/init.el
Could anyone explain to me what I should do to rectify this situation?
"Recursive load" means you have a circular dependency between packages. cl-extra pulls in (by way of load or require, etc) seq, which pulls in bytecomp, which pulls in cl-extra, which pulls in seq, ...
By the looks of it, you have a locally installed third-party packaged version of seq, so removing that as the probable culprit seems like the way to go; but there is a reason it's being pulled in, so it's likely that something else stops working because of this change, and so on.
Prelude seems to want this; maybe you'll need to give up on it until this problem has been resolved. (File a bug report if you can!)
Related
tl;dr on the solution: this error apparently gets flagged on Big Sur using XCode CL tools when you use CharacterVector.push_back() inappropriately. I commented out an offending line, and it promptly stopped throwing the error!
I'm currently working on using Rcpp to write a C++ function for R using Rcpp::sourceCpp("FilePathName"), and it's returning a weird error.
Library/FrameWorks/R.framework/Versions/4.1/Resources/library/Rcpp/include/Rcpp/Vector.h
Line 5: no matching constructor for initialization of 'std::string' (aka 'basic_string')
I've tried running the gamut on updating XCode, gfortran, R, & Rcpp, clearing .R/Environ & .R/MakeVars, and manually editing .R/MakeVars to avoid using clang, but I can't seem to get past this one weird error. I think it has something to do with the update to Big Sur, seeing as that seems to cause some weirdness from time to time.
Any insight as to how best to proceed? For now I'm just trawling through various articles and documentation pieces to find another instance of this error, but so far I've had no luck.
Thanks
I built my own package in R and it works very well. When I hit build and load in Rstudio, there are no errors at all. Everything is fine. However, When I run my function that include .c file I got this error:
Error in .C("SimulateRVine", as.integer(N), as.integer(n), as.integer(w1), : "SimulateRVine" not available for .C() for package "Vicop"!!
What is the problem and how can I solve it?
This is my own package so I rebuild it many times but nothing happen. When I try to use useDynLib("Vicop") and then rebuild my package I got an error. I think this is my problem but do not know how to solve it.
After a hard search as a beginner to c language I see the problem.
I face this issue because I did not register my function. That is for each .c function I must register it in a file which is called int.c
That solve my problem.
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 been using some R libraries to analyze some large data recently, and I find myself frustrated by waiting several hours for the beginning of an analysis, just to get to the end and receive some trivial error, like that I did not install a prerequisite library, or that one of my parameters was wrong. So, then I have to start all over, do the exact same analysis, generate the same variables that it had when it died, and wait a long time. Please note that these are not handled exceptions--they are fatal errors from R.
This is just a thought--and perhaps it is too good to be true, so please at least explain why it wouldn't work--but is there any way to cause R to execute "browser()" in the environment whenever it has a fatal error? For example, say it is executing a script, and encounters "require(notInstalledYet)". Instead of just dying, and losing all the variables in the memory, it would be great if it would give me a browser() at the place it died, so that I could at least save the variables, and at best, fix the problem (e.g. install the library) and try again.
You can change the error option to open a browser on error
options(error=browser)
the default is
options(error=NULL)
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).