asdf-install missing component - common-lisp

I'm having a weird issue with asdf-install.
* (require :asdf-install)
("ASDF-INSTALL")
* (asdf-install:install :split-sequence)
...
Installing /Users/zcai/.sbcl/SPLIT-SEQUENCE.asdf-install-tmp in /Users/zcai/.sbcl/site/,/Users/zcai/.sbcl/systems/
split-sequence/README.cCLan-install
split-sequence/split-sequence.asd
split-sequence/split-sequence.lisp
debugger invoked on a ASDF:MISSING-COMPONENT:
Component "split-sequence" not found
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [RETRY] Retry installation
1: [ABORT] Exit debugger, returning to top level.
((LAMBDA ()))
0]
The problem is that whatever package I'm trying to install, asdf-install will complain component with that package name is missing.
I'm not sure if this is a configuration problem or something else. I'm running 1.0.49 sbcl on OS X 10.6.
Any help would be appreciated.
Thank you.
UPDATE
I tried on a Ubuntu machine running sbcl 1.0.40. It does not have the same issue, maybe it's a bug of asdf that comes with sbcl 1.0.49?
UPDATE 2
I did a
(asdf-install:install :asdf-install)
Then it was able to install many packages without the earlier problem. But when I try to install :cffi, a dependency called "rf" case the same problem. Then I had to restart slime, and the installation will finish without a problem. Looks like it is something wrong with asdf-install then.

1- do NOT use ASDF-INSTALL. ASDF-INSTALL is obsolete and unmaintained.
2- Use Quicklisp.

Related

Fail to use quicklisp with clozure-cl

While using SBCL normally I want to try CCL for some testing and installed it via homebrew on my computer. That worked fine but I fail to use quicklisp with CCL. If I try to load quicklisp's setup.lisp I get the following error message:
➜ ~ ccl64
Clozure Common Lisp Version 1.11.6 DarwinX8664
For more information about CCL, please see http://ccl.clozure.com.
CCL is free software. It is distributed under the terms of the Apache
Licence, Version 2.0.
? (require 'asdf)
ASDF
("uiop" "UIOP" "asdf" "ASDF")
? (load "~/quicklisp/setup.lisp")
> Error: There is no package named "ASDF/SYSTEM-REGISTRY" .
> While executing: CCL::%FASL-NVPACKAGE, in process listener(1).
> Type :GO to continue, :POP to abort, :R for a list of available restarts.
> If continued: Retry finding package with name "ASDF/SYSTEM-REGISTRY".
> Type :? for other options.
1 > :POP
I couldn't find a simple solution searching the web. CCL comes with ASDF as (require 'ASDF) is working. In quicklisp's documentation I couldn't find anything about extra efforts to use it with two lisp implementations in parallel.
If I check ASDF's version as suggested here I get "3.1.5" as installed version, which should be quite recent.
Is there anything obvious I am missing?
I think I found it: I had some old data in my ~/.cache directory from another attempt to install ccl. After deleting it, I can load quicklisp's setup.lisp without any error.
Please advice If I should delete my question or leave it here to prevent others from repeating my errors.
Please note that various Lisps have some startup files. Some of them are by default:
SBCL: ~/.sbclrc
CLISP: ~/.clisprc.lisp
Clozure: ~/.ccl-init.lisp
From the documentation of CCL:
By default, Clozure CL will look for a file named ccl-init.lisp in your home directory, and load it upon startup. On Unix systems, it will also look for .ccl-init.lisp.
CCL uses an ordinary lisp file called ccl-init.lisp which on unix systems is usually put on your home path. So you can add the following lines in that file (on my Ubuntu machine it's path is /home/me/.ccl-init.lisp) which instructs CCL to load quicklisp upon startup:
#-quicklisp
(let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp"
(user-homedir-pathname))))
(when (probe-file quicklisp-init)
(load quicklisp-init)))
This is enough for enabling your CCL to communicate with quicklisp.

How to properly save Common Lisp image using SBCL?

If I want to create a Lisp-image of my program, how do I do it properly? Are there any prerequisites? And doesn't it play nicely with QUICKLISP?
Right now, if I start SBCL (with just QUICKLISP pre-loaded) and save the image:
(save-lisp-and-die "core")
And then try to start SBCL again with this image
sbcl --core core
And then try to do:
(ql:quickload :cl-yaclyaml)
I get the following:
To load "cl-yaclyaml":
Load 1 ASDF system:
cl-yaclyaml
; Loading "cl-yaclyaml"
.......
debugger invoked on a SB-INT:EXTENSION-FAILURE in thread
#<THREAD "main thread" RUNNING {100322C613}>:
Don't know how to REQUIRE sb-sprof.
See also:
The SBCL Manual, Variable *MODULE-PROVIDER-FUNCTIONS*
The SBCL Manual, Function REQUIRE
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [RETRY ] Retry completing load for #<REQUIRE-SYSTEM "sb-sprof">.
1: [ACCEPT ] Continue, treating completing load for #<REQUIRE-SYSTEM "sb-sprof"> as having been successful.
2: Retry ASDF operation.
3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration.
4: [ABORT ] Give up on "cl-yaclyaml"
5: Exit debugger, returning to top level.
(SB-IMPL::REQUIRE-ERROR "Don't know how to ~S ~A." REQUIRE "sb-sprof")
0]
Alternatively, if I try:
(require 'sb-sprof)
when sbcl is started with saved core, I get the same error. If sbcl is started just as sbcl there is no error reported.
In fact, pre-loading QUICKLISP is not a problem: the same problem happens if sbcl is called initially with sbcl --no-userinit --no-sysinit.
Am I doing it wrong?
PS. If I use roswell, ros -L sbcl-bin -m core run somehow doesn't pick up the image (tested by declaring variable *A* before saving and not seeing it once restarted).
PS2. So far what it looks like is that sbcl does not provide extension modules (SB-SPROF, SB-POSIX, etc.) unless they are explicitly required prior saving the image.
Thanks for the help from #jkiiski here is the full explanation and solution:
SBCL uses extra modules (SB-SPROF, SB-POSIX and others) that are not always loaded into the image. These module reside in contrib directory located either where SBCL_HOME environment variable pointing (if it is set) or where the image resides (for example, in /usr/local/lib/sbcl/).
When an image is saved in another location and if SBCL_HOME is not set, SBCL won't be able to find contrib, hence the errors that I saw.
Setting SBCL_HOME to point to contrib location (or copying contrib to image location or new image to contrib location) solves the problem.
Finally, about roswell: roswell parameter -m searches for images in a specific location. For SBCL (sbcl-bin) it would be something like ~/.roswell/impls/x86-64/linux/sbcl-bin/1.3.7/dump/. Secondly, the image name for SBCL must have the form <name>.core. And to start it, use: ros -m <name> -L sbcl-bin run. (Quick edit: better use ros dump for saving images using roswell as it was pointed out to me)
If you want to create executables, you could try the following:
(sb-ext:save-lisp-and-die
"core"
:compression t
;; this is the main function:
:toplevel (lambda ()
(print "hell world")
0)
:executable t)
With this you should be able to call QUICKLOAD as you wish. Maybe you want to checkout my extension to CL-PROJECT for creating executables: https://github.com/ritschmaster/cl-project

Error in fetch(key) : lazy-load database

I don't know what is going on, everything was working great but suddenly I started to have this error message on the documentation:
Error in fetch(key) : lazy-load database '......descopl.rdb' is
corrupt
I removed almost all my code and build again then publish to Github, but when I use the other laptop to download the package, the package is being downloaded and loaded but I can't call any of the functions, and the documentation states that error.
I don't know what caused the problem, I am using roxygen to generate the documentation.
https://github.com/WilliamKinaan/descopl
It seems that the error arises when the package cannot be decompressed by R (as #rawr established, it is corrupt). This solutions have worked for me:
1) Check for possible errors in the creation of the .Rdb files
2) Try restarting your R session (e.g. .rs.restartR() if in RStudio)
3) The package might have been installed in your computer (even though it does not work). Remove it using ?remove.packages()
I have had this problem with roxygen2 as well. Couldn't see any problem with any of my functions. In the end deleting the .rdb file and then getting roxygen2 to rebuild it seemed to solve the problem.
I think the explanation for what is causing this is here.
It's related to devtools.
Per #Zfunk
cd ~/Rlibs/descopl/help
rm *.rdb
Restart R. Look at the help for the package again. Fixed!
I received this error after re-installing a library whilst another R session was running.
Simply restarting the existing R session(s) solved for me (i.e. running .rs.restartR() to restart the sessions)
If you are using R-studio:
1) ctrl+shift+f10 to restart r session
2) tools -> Check for package updates -> update all packages
3) library(ggmap)
Problem is solved.
Basically all answers require restarting R to resolve the issue, but I found myself in an environment where I really didn't want to restart R.
I am posting here a somewhat hack-ish solution suggested by Jim Hester in a bug report about the lazy-load corruption issue.
The gist of it is that the package may have some vestigial S3 methods listed in session's .__S3MethodsTable__. environment. I don't have a very systematic way of identifying which S3 methods in that environment come from where, but I think a good place to start is the print methods, and looking for S3method registrations in the package's NAMESPACE.
You can then remove those S3 methods from the .__S3MethodsTable__. environment and try again, e.g.
rm(list="print.object", envir = get(".__S3MethodsTable__.", envir = baseenv()))
You may also need to unload some DLLs if some new messages come up like
no such symbol glue_ in package /usr/local/lib/R/site-library/glue/libs/glue.so
You can check getLoadedDLLs() to see which such files are loaded in your session. In the case of glue here, the following resolved the issue:
library.dynam.unload('glue', '/usr/local/lib/R/site-library/glue')
I got this error on RStudio on mac OS - updating all the packages and restarting r session did the trick.

Running command had status 1

I've tried to run command in R 2.15.2
rsaga.geoprocessor(lib="ta_channels", module=0, param=list(ELEVATION="DEMflt.sgrd", CHNLNTWRK=paste("channels", i, ".sgrd", sep=""), CHNLROUTE="channel_route.sgrd", SHAPES="channels.shp", INIT_GRID="DEMflt.sgrd", DIV_CELLS=3, MINLEN=40), show.output.on.console=FALSE)
and I'm constantly getting this warning:
Warning message:
running command '"C:/Users/Nenad/Documents/R/win-library/2.15/RSAGA/SAGA-GIS/saga_cmd.exe" ta_preprocessor 2 -DEM "DEM1.sgrd" -RESULT "DEMflt.sgrd" -MINSLOPE "0.05"' had status 1
I use windows 8 and also tried to ran R as admin.
Any idea what is the problem? Thanks!
Idk how actual it is, but I've been struggling with "had status 1" warning a lot. Especially it got really annoying when I tried to use seasonal package to conduct the X13-ARIMA-SEATS seasonal decomposition of time series. The seasonal::seas command just didn't work, because in the code of this command there is a stop condition when running a certain stuff with cmd.exe returns non-zero status. While, as it was mentioned before, 'status 1' doesn't prevent command execution, in case of seasonal package it does.
The problem in my case was caused by some mistake in Windows Registry (Win 10), that in turn caused warning System cannot find the path specified when launching CMD.exe or PowerShell, which caused warning inside R as well. So to fix it:
Press Win+R -> regedit
In HKEY_CURRENT_USER\SOFTWARE\Microsoft\Command Processor folder clean the value of Autorun record (it should be empty)
Do the same for Autorun in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor
After these actions annoying warning with "has status 1" has gone and seasonal::seas started to work perfectly.
Hope it will be usefull for somebody.
Running system commands from R can be really tricky. In my experience, as long as the exit code is not 127 then the command did run, and you could use the intern=TRUE switch in the system command for a more verbose output. If you run the command again, the warning message could contain a errmsg attribute as well for some more info. hth

Unable to load sdl-gfx in quicklisp

I've been installing lispbuilder-sdl family with quicklisp and encountered error in sdl-gfx:
CL-USER> (ql:quickload "lispbuilder-sdl-gfx")
To load "lispbuilder-sdl-gfx":
Load 1 ASDF system:
lispbuilder-sdl-gfx
; Loading "lispbuilder-sdl-gfx"
...........;
; compilation unit aborted
; caught 1 fatal ERROR condition
Unable to load any of the alternatives:
("libSDL_gfx.dylib" (:FRAMEWORK "SDL_gfx"))
[Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR]
I use slime+emacs+SBCL under macosx 10.6. I've installed SDL.framework from this link:
http://thirdcog.eu/apps/frameworks#glew
a file called sdl_with_friends.zip and put things under /Library/Frameworks. However it still complains about cannot find framework.
Any idea on this?
The easiest way to install lispbuilder-sdl on Mac OSX is to fire up SBCL and use Quicklisp:
(ql:quickload "lispbuilder-sdl")
It will probably fail, but you can then compile the OS-X specific helper library located in "~quicklisp/dists/quicklisp/software/lispbuilder-20110619-svn/lispbuilder-sdl/cocoahelper"; just cd to this directory and type "make"
To verify that worked, try this:
(ql:quickload "lispbuilder-sdl-examples")
(lispbuilder-sdl-examples:bezier)
Another common gotcha is when you are using Emacs / SLIME. The cocoa bits must run on the primary thread, so you have to invoke things like this:
#+darwin #+sb-thread
(let ((thread (first (last (sb-thread:list-all-threads)))))
(sb-thread:interrupt-thread thread #'(lambda () (ql:quickload "lispbuilder-sdl-examples")))
(sb-thread:interrupt-thread thread #'(lambda () (lispbuilder-sdl-examples:bezier))))
The error is complaining that it can't load the dynamic library for SDL. I'm sorry - I don't know much about the directory layout on macs (which appears to be where you're working), so I can't exactly tell you how to fix this. But somewhere you should have installed a file called libSDL_gfx.dylib (probably this extension) and the error message means that CFFI is failing to find it.
using homebrew you can brew install sdl_gfx

Resources