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.
Related
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!
I use a cluster (OS is Linux) which does not have R. I would like to install R in my personal folders so that I can just do
Rscript example.R arg1 arg2
How should I install R on this cluster knowing that I don't have admin rights?
How can I then manage the packages?
I'm not sure this is on-topic, but: all you really have to do is
download the R source tarball from CRAN; unpack it somewhere in your file space
create an r-build directory at the same level of the hierarchy (not technically necessary, but it's better practice to keep the source and build directories separate)
create an installation directory (say ~/r_install) somewhere sensible within your file space
cd to the source directory; tools/rsync-recommended
cd to the build directory
../[srcdir]/configure --prefix=~/r_install
make (to build the binaries)
make install (to move everything where it belongs; not technically necessary, as you can run R from the build directory)
Where this may get hairy is with all of the system requirements for R (LaTeX, Java, bzip2, etc. etc. ...) it is theoretically possible to download all this stuff and install it in your own file space, but it starts to get sufficiently tedious that it will be easier to beg your sysadmin to install at least the dependencies for you ...
as #Hack-R points out the basics of this answer are already present on Unix & Linux stackexchange, although my answer is a little more detailed ...
I have a computer behind a very restrictive proxy server it only allows me to surf the web and download programs it does not allow programs like the Atom text editor to download it's packages.
My question is how do I install them using only browser based downloads?
It is certainly possible:
Find the package you want to install, for example the activate-power-mode package.
Click on the Repo button to go to the GitHub repository.
Click Releases towards the top of the UI, then click on the most recent release, 0.4.1 in this case.
Download the source code release in either Zip or GZip depending on your platform.
Extract the content of the archive to a known permanent location, I have chosen:
C:\Source\Atom
Run the following command from your terminal / command prompt (make sure to include quotes around the path):
apm link "C:\Source\Atom\activate-power-mode-0.4.1"
Restart or Reload Ctrl-Alt-R Atom and the package will now be installed.
You can alternatively extract the package directly to your ~/.atom/packages folder however you will have to rename the folder to exactly match the name of the package, additionally uninstalling the package from Atom will delete the files which could be annoying if it is an accidental deletion.
Because of package dependencies a safest bet is this:
Install package normally on connected computer
Copy contents from your ~/.atom/packages
Paste contents to ~/.atom/packages on offline computer
Restart Atom
At least this worked for me like a charm.
The answer of Richard Slater is informative and the answer of Andriy Buday could look less professional. But, in my case, the answer of Andriy Buday was also very important.
I tried to install two packages atom-beautify and prettier-atom by following the answer of Richard Slater and had some problems of not being able to find some modules. It was not only me who had these problems. Consider checking the following links.
The issue of "cannot find module event-kit"
https://github.com/Glavin001/atom-beautify/issues/1734
https://github.com/Glavin001/atom-beautify/issues/1366#issuecomment-269716306
When I decompressed a file (atom-beautify-0.30.3.tar.gz) I received from GitHub respository, I could find out directories like appveyor, docs, and examples. But I could not find out a directory named node_modules which was present when I installed this package atom-beautify using Atom Editor online.
To check if the absence of directory node_modules is the only problem, I went through the following steps.
Start Atom Editor.
Install atom-beautify using Atom Editor online like the answer of Andriy Buday suggests.
Close Atom Editor.
Move atom-beautify directory from ~/.atom/packages (that was %HOMEDIRECTORY%%HOMEPATH%.atom\packages in my case because I used cmd on Windows 10) to somewhere else.
Decompress atom-beautify-0.30.3.tar.gz and move or copy atom-beautify-0.30.3 directory from this decompressed result into %HOMEDIRECTORY%%HOMEPATH%.atom\packages as the answer of Andriy Buday suggests.
Rename directory %HOMEDIRECTORY%%HOMEPATH%.atom\packages\atom-beautify-0.30.3 to %HOMEDIRECTORY%%HOMEPATH%.atom\packages\atom-beautify as the answer of Richard Slater suggests.
Move or copy node_modules directory from the directory moved at step 4 into %HOMEDIRECTORY%%HOMEPATH%.atom\packages\atom-beautify.
Start Atom Editor.
I found that no error message appeared and that package atom-beautify worked properly, thus I am thinking that absence of node_modules directory was the only problem of the file atom-beautify-0.30.3.tar.gz I received from GitHub repository.
I am afraid if it is normal that directory node_modules is not contained in the file atom-beautify-0.30.3.tar.gz downloaded from GitHub repository because of any rules I do not know yet, like placing directories like node_modules somewhere else. If there really are such rules and somebody tells me about such rules by adding an answer or a comment here, I will appreciate it a lot.
I am not sure if it is same with all other packages, but I found that it was same at least with package prettier-atom.
I wish it helps somebody.
+++++++++++++++++++++++++++
I found why the directory node_modules was not contained in atom-beautify-0.30.3.tar.gz.
I checked answers of the following link.
How can I manually download packages for atom editor and install them (manually)?
Answer by D3181 included a link to a page of http://discuss.atom.io/ (I could get a helpful answer by Alchiadus from the link) and suggested running apm install in the package's directory. If it is necessary to use a file downloaded from GitHub repository like atom-beautify-0.30.3.tar.gz, it is necessary to run apm install in the package's directory before copying or moving into %HOMEDIRECTORY%%HOMEPATH%\.atom\package (~/.atom/package in case of *nix) of the offline computer.
Decompress the file downloaded from GitHub repository like atom-beautify-0.30.3.tar.gz.
Go into the directory like atom-beautify-0.30.3 of the decompressed result.
Run apm install on an online computer. (If the directory of apm.cmd is not in PATH, run {directory of apm.cmd}\apm.cmd install.)
Rename directory like atom-beautify-0.30.3 to the correct name of the package like atom-beautify.
Move directory with the correct name of the package like atom-beautify into %HOMEDIRECTORY%%HOMEPATH%\.atom\packages of the offline computer.
Run Atom Editor on the offline computer and check if the package works properly.
It seems normal that the directory node_modules is not included the the compressed file downloaded from GitHub repository.
I downloaded GNAT ADA GPL 2014 and now trying to install on my Mac.
The directions below are the ones I am following, but I do not know where to look to find the file called doinstall. I might still need some help after finding it, but can anyone help me out here?
Navigate to the directory that contains a file called: doinstall
Enter: sudo mkdir /usr/local/gnat
Enter: sudo ./doinstall
Update your path as needed for your shell
You should have downloaded gnat-gpl-2014-x86_64-darwin-bin.tar.gz.
Go to some temporary directory (I use ~/tmp):
cd ~/tmp
Unpack the download, which creates a directory gnat-gpl-2014-x86_64-darwin-bin containing the binary distribution to be installed:
tar zxvf ~/Downloads/gnat-gpl-2014-x86_64-darwin-bin.tar.gz
Enter that directory, which contains (amongst others) doinstall:
cd gnat-gpl-2014-x86_64-darwin-bin
Execute doinstall to enter the installation dialog:
sudo ./doinstall
Remove the unpacked download:
cd ..
rm -rf gnat-gpl-2014-x86_64-darwin-bin
Now you can update PATH as needed for your shell.
What Simon Wright said is correct, but if you're running on Yosemite there's an extra problem: for some obscure reason, Adacore GNAT is broken on Yosemite. You have to make it think it's compiling for Mavericks:
export MACOSX_DEPLOYMENT_TARGET=10.9 # Yosemite workaround
That can go in a few different places, but I put it near the top of the /usr/local/gnat/bin/gps script so it doesn't interfere with the xcodebuild environment.
Also, I found GTKAda to be nearly impossible to install from source; if you download the XNAdaLib-GPL package from http://sourceforge.net/projects/gnuada/ you can install that and get everything you need without having to wade through Adacore's mess. (You may want to use the Adacore version of Glade for GUI design though; for some reason the Sourceforge package's version is localized in French and I'm not sure if it can be switched to English.)
Finally, since this is a bit duct-tape-and-baling-wire, I would recommend not shipping any production mission-critical code with this environment; either roll back to Mavericks or wait for GNAT 2015.
I'm using quicklisp as the package management tool for SBCL.
However, sometimes I found it's not very convenient to install a package to the HOME directory of current user by ql:quickload. (For example, if I use (ql:quickload "xmls") to install xmls, other users can't use it.)
What's worse, I'd like to run the lisp code as a script. So when I use the package installed by quicklisp, I need to add the absolute path of that package uncomfortably, such as:
#!/usr/bin/sbcl --script
(require 'xmls "..../quicklisp/dists/quicklisp/software/xmls-1.4/xmls")
If I use (require 'xmls), the compiler will not work because it cannot find that package if I use the --script options.
Does anyone knows how to solve the problem so that I can use --script and require(no need to add absolute path) at the same time？
I don't know of a good solution to this problem. The solution I use is to not write scripts with Common Lisp; I usually write applications that I use interactively from CL sessions. When I do want to run things from the command-line, I use buildapp for it, and use ql:write-asdf-manifest-file to create a file to pass to --manifest-file for buildapp.
I sometimes wish there was a better solution, but it'll probably take some work by someone (hopefully not me).
I just do sudo sbcl and this way it'll be installed for every user on my PC - it's OK, because it's my home PC, so there's no danger.
One thing I could think of is maybe symlinking the directory where ql installs stuff to something that is easier to access, like $HOME/packages -> .../quicklisp/software or something?