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!
Related
I am working on ubuntu 18.10. want to recompile several of my libraries:
zlib, jasper, libpng, hdf5, netcdf
Even with
make distclean
I see that the old lib and include files still remain. Can I assume that a recompilation replaces these files, or can I remove them with sudo apt-get purge/remove ?
I am not sure whether removing them manually is safe, or will remove all of them and.or may remove other unrelated files.
I will appreciate some guidance
Calling make distclean will clean up enough that you will get a fresh compile when doing make afterwards.
The additional target maintainer-clean is available which may remove even more files, but you really shouldn't need to use it.
I assume if you have kept all the source folders and built your libraries within those source folders, then make distclean, if really properly enabled, will clean all the compiled stuff and you can re-build everything.
It is highly possible that make distclean does not clean the installed stuff, meaning if make install was executed and all the built executables/libraries/header were also linked/copied to the system path e.g. /usr/bin, /usr/local/ ... or whatever directories are used by the system.
Nevertheless, if you re-build everything and if again (after successful re-compile/re-build) execute make install, new version of the binaries/libraries/ will overwrite the old ones.
I'm having serious issues with Codelight. It has been working for days now, maybe even weeks but after today when I took my project to school to work on it there something happened. My workspace is in a onedrive folder so that I can work on it wherever I am. I have reinstalled codelight and reinstalled MinGW and set it up according to my school's instructions but right now I can't build anything at all (see attached image). I have been looking at other threads but none of them have helped so far. Error
What do you think happened?
Edit: I seem to have fixed the issue. When you let codelite search for a compiler, as it does the first time you launch it, you mess up the directories of things completely. So for example the directory for the C compiler should be $(CodeLiteDir)/tools/gcc-arm/bin/arm-none-eabi-gcc.exe instead of C:\MinGW or wherever it may be installed. Also, we use a patched version of codelite with 'added debugging support' for the md407 so you really don't want to update codelite. There were more issues, for example the C compiler options for my project, so when I built the project it complained about all sorts of things and the cursor wouldn't show up so debugging was impossible, but I managed to fix that too.
In conclusion: this was not fun to fix and codelite is sensitive.
I use Dev-C++ I got similiar 'Mingw32-make.exe' errors. When installing Mingw you will notice there is another directory 'c:\Mingw32\MSYS\1.0\bin'. Within MSYS this directory is global and it has some very important binary files like its own 'make.exe' file. 'Mingw32-make.exe' uses files from this directory. Because the IDE will not know about this directory you will need to include this in your system/environment path because outside of MSYS this directory is not global and 'ming32-make.exe' will not be able to access those binary files.
Regardless of your compiler if your 'make' is Mingw32 that path must be set.
After switching to a new Mac (macOS Sierra) and re-cloning all of my GitHub repositories, I began to encounter a new problem. Whenever I make changes and save an R script, and run:
git status
## Untracked files:
## (use "git add <file>..." to include in what will be committed)
## .DS_Store
## .Rhistory
.DS_Store and .Rhistory appear.
Question: Is there a way to stop and/or ignore (e.g. via .gitignore, see below) these files when committing R scripts to GitHub?
I understand similar questions may have been asked, I decided to still raise this question because I really want to make sure that I get the setting right at the first place, especially if others have encountered similar problems before. If you have a way and/or references of how to solve this highly specific problem--which may require a combination of bash Terminal, R, as well as the operating system
The fastest and simplest way is to add .DS_Store and .Rhistory to your global gitignore file.
Here is how to do it, in a nutshell: open or create (if doesn't exist yet) ~/.gitignore_global and add .DS_Store and .Rhistory on two new lines.
If your repository already includes any unwanted files, use git rm to get rid of them (link).
I have found several relevant references that can lead to a potential solution:
Mac OS X v10.4 and later: How to prevent .DS_Store file creation over network connections, which simply asks user to run the line below in Terminal to stop generating .DS_Store files:
defaults write com.apple.desktopservices DSDontWriteNetworkStores true
r - Disabling saving history. This earlier post provides instruction on how to disable creation of .Rhistory files on Windows.
Remove .DS_Store files from a Git repository using .gitignore. I suppose the same could be done to .Rhistory
Still, if you have a better solution, please share with the community!
After calling (ql:quickload "system-name"), and QuickLisp finishes downloading and installing the system, where on earth does it put it?
I tried looking in my project folder, but it wasn't there, and I couldn't find it in ~/quicklisp either.
So where exactly does it save the system? If it does so at all, that is.
Normally when you install quicklisp like this http://www.quicklisp.org/beta/#installation you should have this folder in your home directory.
/home/yourusername/quicklisp
and then you can find your installed libraries in
/home/yourusername/quicklisp/dists/quicklisp/software
and also you can add local asd file system in
/home/youusername/quicklisp/local-projects
maybe you install it when you were a superuser, to find this I think that you must use the shell command find to find the folder like in my fedora computer I did. here is the sample
sudo find / -name quicklisp
answer
Swipe your finger across the fingerprint reader
/home/anquegi/quicklisp
/home/anquegi/quicklisp/quicklisp
/home/anquegi/quicklisp/dists/quicklisp
/home/anquegi/.cache/common-lisp/abcl-1.3.1-fasl42-linux-x64/home/anquegi/quicklisp
/home/anquegi/.cache/common-lisp/abcl-1.3.1-fasl42-linux-x64/home/anquegi/quicklisp/quicklisp
/home/anquegi/.cache/common-lisp/sbcl-1.2.4-1.fc21-linux-x64/home/anquegi/quicklisp
/home/anquegi/.cache/common-lisp/sbcl-1.2.4-1.fc21-linux-x64/home/anquegi/quicklisp/quicklisp
/home/anquegi/.cache/common-lisp/sbcl-1.2.4-1.fc21-linux-x64/home/anquegi/quicklisp/dists/quicklisp
/home/anquegi/lib/lisp/quicklisp
find: ‘/run/user/1000/gvfs’: S’ha denegat el permís
It will be in a directory similar to the following example:
/home/electric/quicklisp/dists/quicklisp/software/lparallel-20141106-git
To pick that apart: the Quicklisp client is designed so that users can create and add their own software repositories. Quicklisp calls these repositories dists. Quicklisp provides its own dist, which is also named quicklisp. In addition to the software in a dist, quicklisp also stores the dist's metadata and zipped software archives in the dist's directory. Separate from dists, the toplevel quicklisp directory also holds quicklisp's source, a place to put local-projects, and etc.
That's how you end up with the initially redundant looking quicklisp/dists/quicklisp/software/.
Also, (ql:where-is-system 'system-name) will return the system's location.
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.