On Debian, I had a bunch of cruft installed in /usr/lib/sbcl/site-systems that wouldn't load because the FASLs didn't match the version of SBCL that is actually installed.
For some reason, none of these files were associated with any Debian package (this is an old computer that has been running the same Debian install for over a decade– it's on Debian Sid).
I deleted the bad systems one at a time, and for most of them, Quicklisp did the right thing and downloaded the Quicklisp version. Sometimes, ASDF would insist that the system should exist at its previous path, but restarting SBCL got past that problem.
But for one system, ASDF has persistently cached the location of its .asd file as being in the /usr/lib/sbcl/site-systems/ directory. Loading this system is impossible because ASDF will not look anywhere else, even after restarting SBCL.
I tried looking in all the paths specified in various config files under /etc/common-lisp. None of those files contain a reference to the now-missing library.
I've resorted to doing a grep -rli across all the files under /usr. I don't expect that to complete in less than a day, and it might not find anything, in which case I'll be forced to grep the whole hard drive, which might take a whole week. Hopefully, the cache isn't compressed, because then I'll never find it.
Does anyone happen to know how ASDF persists the paths of files?
After a lot of excruciating debugging, I discovered that the files in /usr/lib/sbcl/site-systems/ actually do exist. They're broken symlinks.
The files I deleted were in the similar-looking path /usr/lib/sbcl/site/, to which the symlinks pointed.
Removing the symlinks fixed all the loading errors.
A couple of ideas about troubleshooting Quicklisp, particularly if your getting bizarre behavior.:
If you use Quicklisp for any length of time you'll probably eventually use local packages, found here by default, ~/quicklisp/local-projects It's valid to symlink you're projects into that directory. If you ever rename one of your projects, of course, don't forget to create a new symlink and delete the old one
Likewise, if you rename a local project, also delete the system index which Quicklisp will then recreate the next time it runs: ~/quicklisp/local-projects/system-index.txt Doesn't hurt to delete it from time to time just to keep your system fresh.
your *.fasl files can become stale too, deleting the system cache forces quicklisp to recompile everything. On an Ubuntu system running SBCL that would mean deleting the contents of:
rm -rf ~/.cache/common-lisp
Try updating the Quicklisp client
(ql:update-client)
Potentially deleting and reinstalling Quicklisp itself at ~/quicklisp can be necessary. (It's possible to inadvertently edit source files when your debugging and using Swanks lookup definition feature, breaking installed packages that used to work. Not that I would ever have done something as careless as that.)
Also, don't forget that ASDF decends into directories looking for *.asd files. If you have a stray one that's improperly structured that can cause havoc on you build system. (See my comment above about registering local projects to Quicklisp)
Finally, don't forget to check your lisp init file, e.g. .sbclrc for any debugging or quick and dirty hacks you might have left there and forgot about.
These are all things that have worked for me at one time or another, hopefully I'm not perpetuating legend and cant on things have have long since been fixed!
enter image description here
Even I export the R path to be the correct one, rstudio still use the deleted R path.
I checked my ~/.bashrc file and the deleted path is not in $PATH variable...
Ok , thanks for user 42's answer.
However, I can't find where is .Rprofile located and I've made too many changes to configuration files that it's hard to pinpoint where's the problem any more. I completely erase my disk division and reinstall ubuntu.
My system is ubuntu server so I try to install everything just as user rather than root. And specifically I install R, R-essentials using conda in the directory /usr. This time the Rstudio can find R without problem. Therefore I think Rstudio can only find R in certain directories... like /bin /usr/bin. And somehow it ignores R in other directories.
I have attempted to install R and R studio on the local drive on my work computer as opposed to the organization network folder because anything that runs through the network is really slow. When installing, the destination path shows that it's my local C:drive. However, when I install a new package, the default path shown is my network drive and there is no option to change:
.libPaths()
[1] "\\\\The library/path/I/don't/want"
[2] "C:/Program Files/R/R-3.2.1/library"
I'm running windows 7 professional. How can I remove library path [1] and make path [2] my primary for all base packages and all new packages that I install?
Windows 7/10: If your C:\Program Files (or wherever R is installed) is blocked for writing, as mine is, then you'll get frustrated editing RProfile.site (as I did). As specified in the accepted answer, I updated R_LIBS_USER and it worked. However, even after reading the fine manual several times and extensive searching, it took me several hours to do this. In the spirit of saving someone else time...
Let's assume you want your packages to reside in C:\R\Library:
Create the folder C:\R\Library. Next I need to add this folder to the R_LIBS_USER path:
Click Start --> Control Panel --> User Accounts --> Change my environmental variables
The Environmental Variables window pops up. If you see R_LIBS_USER, highlight it and click Edit. Otherwise click New. Both actions open a window with fields for Variable and Value.
In my case, R_LIBS_USER was already there, and Value was a path to my desktop. I added to the path the folder that I created, separated by semicolon. C:\R\Library;C:\Users\Eric.Krantz\Desktop\R stuff\Packages.
(NOTE: In the last step, I could have removed the path to the Desktop location and simply left C:\R\Library).
See help(Startup) and help(.libPaths) as you have several possibilities where this may have gotten set. Among them are
setting R_LIBS_USER
assigning .libPaths() in .Rprofile or Rprofile.site
and more.
In this particular case you need to go backwards and unset whereever \\\\The library/path/I/don't/want is set.
To otherwise ignore it you need to override it use explicitly i.e. via
library("somePackage", lib.loc=.libPaths()[-1])
when loading a package.
Facing the very same problem (avoiding the default path in a network) I came up to this solution with the hints given in other answers.
The solution is editing the Rprofile file to overwrite the variable R_LIBS_USER which by default points to the home directory.
Here the steps:
Create the target destination folder for the libraries, e.g.,
~\target.
Find the Rprofile file. In my case it was at C:\Program Files\R\R-3.3.3\library\base\R\Rprofile.
Edit the file and change the definition the variable R_LIBS_USER. In my case, I replaced the this line file.path(Sys.getenv("R_USER"), "R", with file.path("~\target", "R",.
The documentation that support this solution is here
Original file with:
if(!nzchar(Sys.getenv("R_LIBS_USER")))
Sys.setenv(R_LIBS_USER=
file.path(Sys.getenv("R_USER"), "R",
"win-library",
paste(R.version$major,
sub("\\..*$", "", R.version$minor),
sep=".")
))
Modified file:
if(!nzchar(Sys.getenv("R_LIBS_USER")))
Sys.setenv(R_LIBS_USER=
file.path("~\target", "R",
"win-library",
paste(R.version$major,
sub("\\..*$", "", R.version$minor),
sep=".")
))
Windows 10 on a Network
Having your packages stored on the network drive can slow down the performance of R / R Studio considerably, and you spend a lot of time waiting for the libraries to load/install, due to the bottlenecks of having to retrieve and push data over the server back to your local host. See the following for instructions on how to create an .RProfile on your local machine:
Create a directory called C:\Users\xxxxxx\Documents\R\3.4 (or whatever R version you are using, and where you will store your local R packages- your directory location may be different than mine)
On R Console, type Sys.getenv("HOME") to get your home directory (this is where your .RProfile will be stored and R will always check there for packages- and this is on the network if packages are stored there)
Create a file called .Rprofile and place it in :\YOUR\HOME\DIRECTORY\ON_NETWORK (the directory you get after typing Sys.getenv("HOME") in R Console)
File contents of .Rprofile should be like this:
#search 2 places for packages- install new packages to first directory- load built-in packages from the second (this is from your base R package- will be different for some)
.libPaths(c("C:\Users\xxxxxx\Documents\R\3.4", "C:/Program Files/Microsoft/R Client/R_SERVER/library"))
message("*** Setting libPath to local hard drive ***")
#insert a sleep command at line 12 of the unpackPkgZip function. So, just after the package is unzipped.
trace(utils:::unpackPkgZip, quote(Sys.sleep(2)), at=12L, print=TRUE)
message("*** Add 2 second delay when installing packages, to accommodate virus scanner for R 3.4 (fixed in R 3.5+)***")
# fix problem with tcltk for sqldf package: https://github.com/ggrothendieck/sqldf#problem-involvling-tcltk
options(gsubfn.engine = "R")
message("*** Successfully loaded .Rprofile ***")
Restart R Studio and verify that you see that the messages above are displayed.
Now you can enjoy faster performance of your application on local host, vs. storing the packages on the network and slowing everything down.
I was struggling for a while with this as my work computer (with Windows 10) created the default user library on a network drive, which would slow down R and RStudio to an unusable state.
In case this helps someone, this is the easiest way I found, without requiring admin rights:
make sure the directory you want to install your packages into exists. If you want to respect the convention, use: C:\Users\username\R\win-library\rversion (for example, something like: C:\Users\janebloggs\R\win-library\3.6)
create a .Renviron file in your home directory (which might be on the network drive?), and in it, write one single line that defines the R_LIBS_USER variable to be your custom path:
R_LIBS_USER=C:\Users\janebloggs\R\win-library\3.6
(feel free to add comments too, with lines starting with #)
If a .Renviron file exists, R will read it at startup and use the variables as they are defined in there, before running the code in the .Rprofile. You can read about it in help(Startup).
Now it should be persistent between sessions!
After a couple of hours of trying to solve the issue in several ways, some of which are described here, for me (on Win 10) the option of creating a Renviron file worked, but a little different from what was written here above.
The task is to change the value of the variable R_LIBS_USER. To do this two steps needed:
Create the file named Renviron (without dot) in the folder \Program\etc\ (Program is the directory where R is installed--for example, for me it was C:\Program Files\R\R-4.0.0\etc)
Insert a line in Renviron with new path: R_LIBS_USER = "C:/R/Library"
After that, reboot R and use .libPaths() to confirm the default directory changed.
I think I tried all of the above and it didn't work for me. This worked, though:
In home directory, make a file called ".Renviron"
In that file, write:
.libPaths(new = "/my/path/to/libs")
Save and restart R if you had it open
I wrote a .spec file on RHEL and I am building RPM using rpmbuild. I need ideas on how to handle the situation below.
My RPM creates an empty logs directory when it installs first time within the installation folder like below
/opt/MyInstallation-1.0.0-1/some executables
/opt/MyInstallation-1.0.0-1/lib/carries shared objects(.so files)
/opt/MyInstallation-1.0.0-1/config/carries some XML and custom configuration files(.xml, etc)
/opt/MyInstallation-1.0.0-1/log--->This is where application writes logs
When my RPM upgrades MyInstallation-1.0.0-1, to MyInstallation-1.0.0-2 for example, I get everything right as I wanted.
But, my question is how to preserve log files written in MyInstallation-1.0.0-1? Or to precisely copy the log directory to MyInstallation-1.0.0-2.
I believe if you tag the directory as %config, it is expected that the user will have files in there, so it will leave it alone.
I found a solution or workaround to this by hit and trial method :)
I am using rpmbuild version 4.8.0 on RHEL 6.3 x86_64. I believe it will work on other distros as well.
If you install with one name only like "MyInstallation" rather than "MyInstallation-version number-RPM Build Number" and create "logs directory as a standard directory(no additional flags on it)[See Original Question for scenario] Whenever you upgrade, you normally don't touch logs directory. RPM will leave its contents as it is. All you have to do is to ensure that you keep the line below in the install section.
%install
install --directory $RPM_BUILD_ROOT%{_prefix}/%{name}/log
Here, prefix and name are macros. That has to do nothing with underlying concept.
Regarding config files, the following is a very precise table that will help you guarding your config files. Again, this rule can't be applied on logs our applications create.
http://www-uxsup.csx.cam.ac.uk/~jw35/docs/rpm_config.html
Thanks & Regards.
How do I completely wipe (remove) Julia from my system?
Unless you've made changes to the code in packages, you can delete the whole .julia directory when you get into trouble. Either via a file manager, or (on a Unix system) via the command line,
rm -rf ~/.julia
Tim's answer is good, however you can also be a bit more specific.
I usually do the following (since I'm using v0.5, the path has v0.5, however, that will depend on what version you are using):
rm -rf ~/.julia/lib/v0.5 ~/.julia/v0.5/<packagename>
Deleting the lib subdirectory gets rid of any precompiled code, which might be also in a bad state.