I just typed a declaration for "indexed-row" that got interpreted as "indexxed-row" (with the extra x).
I'm running tmux on bash, on Ubuntu 12.04. This is Clojure 1.3 and the Leinegan REPL.
Where along the pipeline did it go wrong?
(user=> (def indexed-row row)
#'user/indexxed-row
user=> indexed-row
CompilerException java.lang.RuntimeException: Unable to resolve symbol: indexed-row in this context, compiling:(NO_SOURCE_PATH:0:0)
This is just so strange that I had to double-take to see it.
Related
I am trying to get Common Lisp running on my Windows 10 machine and I have run into a problem with getting ASDF/(ql:quickload "...") to load a project. I generated the given project with the following command (after creating a C:\Users\ig88t\src\lisp folder):
(ql:quickload "quickproject")
(quickproject:make-project "~/src/lisp/swatchblade/" :depends-on '(vecto hunchentoot))
Which correctly generates the project and I can view the source at ~/src/lisp/swatchblade.
But I am unable to load it via
(ql:quickload "swatchblade")
Instead of loading, I get an error saying
System "swatchblade" not found [Condition of type
QUICKLISP-CLIENT:SYSTEM-NOT-FOUND]
I am going by two manuals, one that Xach wrote and another tailored for Windows. Xach recommends ~/.config/common-lisp/source-registry.conf.d/projects.conf whereas the second recommends ~/.config/common-lisp/source-registry.conf.d/asdf.conf. I am currently using the version Xach wrote as it has worked for me on Linux.
Going by the manual for ASDF it seems that ~/AppData/Local/ is where I should store .config/common-lisp/source-registry.conf.d/projects.conf. I have tried storing it at ~/AppData/Local/config/... as well as ~/AppData/Local/.config/... to no avail. I noticed that Clozure CL installs some quicklisp data in ~/AppData/Local/common-lisp, so I tried putting the source-registry.conf.d folder there as in ~/AppData/Local/common-lisp/source-registry.conf.d/projects.conf as well but it didn't work.
I have tried a lot of different variations of placing the folder in different places but I have not managed to figure out the right one. I would really appreciate any help/suggestions by anyone using Common Lisp and Quicklisp on Windows.
I am using Clozure CL, 1.11.5, and the wx86cl64 binary which comes with ASDF version 3.1.5 in case that matters.
--- edit ---
After talking with Xach about this issue, I tried:
(quickproject:make-project "~/quicklisp/local-projects/swatch"
:depends-on '(vecto hunchentoot))
and then ran:
(ql:register-local-projects)
but upon running:
(ql:quickload "swatch")
it failed yet again with:
System "swatch" not found [Condition of type
QUICKLISP-CLIENT:SYSTEM-NOT-FOUND]
He said it might be related to this PR for quickproject.
--- edit #2 ---
I recently tried using SBCL and things seemed to be working. I could create projects using quickproject and load them. Note that I am unable to load projects created with quickproject under CCL. However, when I restart slime/emacs, I am unable to load any projects previously created under SBCL.
; SLIME 2.20
CL-USER> (ql:quickload "quickproject")
To load "quickproject":
Load 1 ASDF system:
quickproject
; Loading "quickproject"
("quickproject")
CL-USER> (quickproject:make-project "~/quicklisp/local-projects/test/"
:depends-on '(vecto))
"test"
CL-USER> (ql:quickload "test")
To load "test":
Load 1 ASDF system:
test
; Loading "test"
[package test]
("test")
CL-USER>
--- intermission... restarting slime ---
; SLIME 2.20
CL-USER> (ql:quickload "test")
; Evaluation aborted on #<QUICKLISP-CLIENT:SYSTEM-NOT-FOUND {10034555B3}>.
CL-USER>
So I have no clue what could be causing the issue or how to resolve it, but it appears that creating/loading projects never works under Clozure CL and to works only within the current session in SBCL.
--- edit #3 ---
It seems I was wrong about SBCL. It seems that when I run
(quickproject:make-project "~/quicklisp/local-projects/test/"
:depends-on '(vecto))
It creates a folder in C:\Users\ig88t\AppData\Roaming\quicklisp\local-projects and not in C:\Users\ig88t\quicklisp\local-projects. It can load projects created within the current session as I said earlier, but is unable to find them in a new session.
(asdf::user-source-registry :direction :output)
How do I build a standalone executable in SBCL? I've tried
; SLIME 2.20
CL-USER> (defun hullo ()
(format t "hullo"))
HULLO
CL-USER> (sb-ext:save-lisp-and-die "hullo" :toplevel #'hullo :executable t)
but that just produces the following error.
Cannot save core with multiple threads running.
Interactive thread (of current session):
#<THREAD "main thread" RUNNING {10019563F3}>
Other threads:
#<THREAD "Swank Sentinel" RUNNING {100329E073}>,
#<THREAD "control-thread" RUNNING {1003423A13}>,
#<THREAD "reader-thread" RUNNING {1003428043}>,
#<THREAD "swank-indentation-cache-thread" RUNNING
{1003428153}>,
#<THREAD "auto-flush-thread" RUNNING {1004047DA3}>,
#<THREAD "repl-thread" RUNNING {1004047FA3}>
[Condition of type SB-IMPL::SAVE-WITH-MULTIPLE-THREADS-ERROR]
What am I doing wrong?
What you are doing wrong is trying to save an image while multiple threads are running. Unlike many errors in Lisp the error message explains exactly what the problem is.
If you look up the function in the sbcl manual here then you find that indeed one may not save an image with multiple threads running. The extra threads come from swank (the CL half of SLIME). The manual says that you may add functions to *save-hooks* which destroy excess threads and functions to *init-hooks* to restore threads.
One way around all this is to not save the image when it is running through slime but instead to start sbcl directly at a terminal (note: no readline support), load your program and save from there.
Working with slime is different. In theory there is a SWANK-BACKEND:SAVE-IMAGE function but I’m not sure if that works. Also as saving an image kills the process you may want to fork (SB-POSIX:FORK) first, unless you are on Windows. But forking causes problems due to not being well specified and file descriptor issues (i.e. if you try fork->close swank connection->save and die then you may find that the connection in the parent process is closed (or worse, corrupted by appearing open but being closed at some lower level)). One can read about such things online. Note that due to the way sbcl threads are implemented, forking clones only the thread that forks and the other threads are not cloned. Thus forking and then saving should work but may cause problems when running the executable due to partial slime state.
You may be interested in buildapp.
If you want to be able to use slime with your saved application you can load swank and start listening on a socket or port (maybe with some command line argument) and then in Emacs you may connect to that swank backend with slime.
You have to run save-lisp-and-die from a new sbcl, not from Slime. Dan Robertson explains more.
It is cumbersome the first time, but you can put it in a Makefile and re-use it. Don't forget to load your dependencies.
build:
sbcl --load cl-torrents.asd \
--eval '(ql:quickload :torrents)' \
--eval '(use-package :torrents)' \ # not mandatory
--eval "(sb-ext:save-lisp-and-die #p\"torrents\" :toplevel #'main :executable t)"
The quickload implies Quicklisp is already loaded, which may be the case if you installed Quicklisp on your machine, because then your ~/.sbclr contains quicklisp loading script ((load quicklisp-init)).
However sb-ext is not portable across implementations. asdf:make is the cross-platform equivalent. Add this in your .asd system definition:
:build-operation "program-op" ;; leave as is
:build-pathname "<binary-name>"
:entry-point "<my-package:main-function>"
and then call asdf:make to build the executable.
You can have a look at buildapp (mentioned above), a still popular app to do just that, for SBCL and CCL. It is in Debian. http://lisp-lang.org/wiki/article/buildapp An example usage looks like
buildapp --output myapp \
--asdf-path . \
--asdf-tree ~/quicklisp/dists \
--load-system my-app \
--entry my-app:main
But see also Roswell, a more general purpose tool, also supposed to build executables, but it is less documented. https://roswell.github.io/
If you want to build an executable on a CI system (like Gitlab CI), you may appreciate a lisp Docker image which has already SBCL, others lisps and Quicklisp installed, and if you want to parse command line arguments, see https://lispcookbook.github.io/cl-cookbook/testing.html#gitlab-ci and (my) tutorial: https://vindarel.github.io/cl-torrents/tutorial.html#org8567d07
I am trying to make leiningen work. I am using Windows 7. When I run in the command window
C:\lein new app my-app
I get the following error. Does anyone know what this means and where the error is occuring?
There is an explanation of the error message here but I did not understand if there is a fix or what causes the error.
C:\Users\a\work>lein new app my-app
java.lang.UnsupportedOperationException: nth not supported on this type: Symbol
at clojure.lang.RT.nthFrom(RT.java:857)
at clojure.lang.RT.nth(RT.java:807)
at leiningen.core.project$dep_key.invoke(project.clj:175)
at leiningen.core.project$reduce_dep_step.invoke(project.clj:183)
at clojure.lang.ArrayChunk.reduce(ArrayChunk.java:58)
at clojure.core.protocols$fn__6041.invoke(protocols.clj:98)
at clojure.core.protocols$fn__6005$G__6000__6014.invoke(protocols.clj:19
)
at clojure.core.protocols$seq_reduce.invoke(protocols.clj:31)
at clojure.core.protocols$fn__6024.invoke(protocols.clj:60)
at clojure.core.protocols$fn__5979$G__5974__5992.invoke(protocols.clj:13
)
at clojure.core$reduce.invoke(core.clj:6177)
at leiningen.core.project$meta_merge.invoke(project.clj:391)
at clojure.core$merge_with$merge_entry__4279.invoke(core.clj:2698)
at clojure.core$reduce1.invoke(core.clj:896)
at clojure.core$merge_with$merge2__4281.invoke(core.clj:2701)
at clojure.core$reduce1.invoke(core.clj:896)
at clojure.core$reduce1.invoke(core.clj:887)
at clojure.core$merge_with.doInvoke(core.clj:2702)
at clojure.lang.RestFn.invoke(RestFn.java:439)
at leiningen.core.project$meta_merge.invoke(project.clj:395)
at leiningen.core.project$apply_profiles$fn__1009.invoke(project.clj:417
)
at clojure.lang.ArrayChunk.reduce(ArrayChunk.java:58)
at clojure.core.protocols$fn__6041.invoke(protocols.clj:98)
at clojure.core.protocols$fn__6005$G__6000__6014.invoke(protocols.clj:19
)
at clojure.core.protocols$seq_reduce.invoke(protocols.clj:31)
at clojure.core.protocols$fn__6026.invoke(protocols.clj:54)
at clojure.core.protocols$fn__5979$G__5974__5992.invoke(protocols.clj:13
)
at clojure.core$reduce.invoke(core.clj:6177)
at leiningen.core.project$apply_profiles.invoke(project.clj:415)
at leiningen.core.project$init_profiles.doInvoke(project.clj:603)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at leiningen.core.main$_main$fn__1332.invoke(main.clj:257)
at leiningen.core.main$_main.doInvoke(main.clj:252)
at clojure.lang.RestFn.invoke(RestFn.java:436)
at clojure.lang.Var.invoke(Var.java:423)
at clojure.lang.AFn.applyToHelper(AFn.java:167)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.core$apply.invoke(core.clj:617)
at clojure.main$main_opt.invoke(main.clj:335)
at clojure.main$main.doInvoke(main.clj:440)
at clojure.lang.RestFn.invoke(RestFn.java:482)
at clojure.lang.Var.invoke(Var.java:431)
at clojure.lang.AFn.applyToHelper(AFn.java:178)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.main.main(main.java:37)
C:\Users\a\work
As requested, here's my comment transferred into an answer. I suggested reinstalling Leiningen because apparently a broken Leiningen installation was the source of the problem.
As a little background explanation, I'm using Leiningen on both Linux and Windows, and I've made the experience myself that the primary method for installing Leiningen recommended on its homepage, the lein resp. lein.bat script, just works, whereas the alternative
installation methods (Linux package managers, Windows installer) often produce broken installations.
I think it's highly unlikely that this is essentially a leiningen error, since I can reproduce it without leiningen being involved in any way:
user=> (let [[foo bar] :froboz] (list foo bar))
UnsupportedOperationException nth not supported on this type: Keyword clojure.lang.RT.nthFrom (RT.java:857)
I spent the afternoon trying to get the ritz-swank package to work with emacs and Clojure. (Googling the error message and much more gave no useful leads.) I hope somebody can give me some pointers that'll get me up and running.
The error is Symbol's value as variable is void: slime-ritz.
According to http://www.delorie.com/gnu/docs/elisp-manual-21/elisp_142.html:
"If you have never given a symbol any value as a global variable, we say that that symbol's global value is void. In other words, the symbol's value cell does not have any Lisp object in it. If you try to evaluate the symbol, you get a void-variable error rather than a value.... A void variable does not have any value."
I tried to find the value of slime-ritz, using Emacs 'describe-variable' (C-h v), but it didn't return anything. Doing an appropos search on "ritz" turned up nothing, but searching for "slime" returned bunches of functions (so I assume that the slime package is present).
My installation procedure
I followed the instructions in the Install section of https://github.com/pallet/ritz/tree/develop/swank (the pallet/ritz project page), starting from scratch twice to make sure I was doing things right. Here is the sequence of my last attempt:
Began with a system containing neither Emacs nor a ~/.emacs.d directory.
Installed Emacs 24.2, the latest available Mac OS X version (from http://emacsformacosx.com/)
Installed Emacs Prelude through a curl command (see http://batsov.com/prelude/)
Downloaded (as the project page said to) specific versions of slime and slime-ritz
Installed both of them manually using M-x package-install-file
Exited and relaunched emacs, just in case....
Installed lein-ritz as per the page's instructions and successfully got:
Greggs-Mac-Pro:combolock gr$ lein ritz
user=> Swank server listening on local port 51521
M-x slime-connect (which is supposed to make the connection from Emacs to the Swank server) returned the error Symbol's value as variable is void: slime-ritz in the Emacs minibuffer.
Diagnostic data
Running M-x package-activated-list produced the following list of loaded packages:
(ace-jump-mode ack-and-a-half elisp-slime-nav exec-path-from-shell expand-region flycheck gist gh guru-mode helm-projectile helm logito magithub magit melpa paredit pcache projectile dash rainbow-delimiters rainbow-mode s slime slime-ritz solarized-theme undo-tree volatile-highlights yasnippet zenburn-theme)
Running M-x package-list-packages listed the following packages as installed:
ace-jump-mode 20121104....
ack-and-a-half 20130204....
dash 20130223....
elisp-slime-nav 20130127....
exec-path-from-... 20121108.945
expand-region 20130223....
flycheck 20130223....
gh 20121231.208
gist 20121231.212
guru-mode 20121016....
helm 20130223....
helm-projectile 20130131....
logito 20120225....
magit 20130222....
magithub 20121130....
melpa 20120202....
paredit 20110508....
pcache 20120408....
projectile 20130220....
rainbow-delimiters 20120428.45
rainbow-mode 0.6
s 20130216....
slime 20101113.1 <-- manually installed, from sources
slime-ritz 0.6.0 <-- specified by pallet/ritz page
solarized-theme 20130215....
undo-tree 20130119.926
volatile-highli... 20120215.9
yasnippet 20130218....
zenburn-theme 20130215....
I noticed that clojure-mode wasn't present, so I added that, but step 8, above, gave the same error message.
Some shot-in-the-dark questions
1) Do I need to install pallet?
2) Do I need to install any other package from the ritz family (https://github.com/pallet/ritz)?
I'm really looking forward to using ritz-swank--it looks really powerful! (Thanks to Hugo Duncan for all the hard work!)
Emacs Predule ships nrepl.el instead of swank-clojure. You need to install nrepl-ritz instead of swank-ritz. Swank-clojure is a dead project, that's no longer supported in clojure-mode 2.0.0 (the one that comes with Predule).
I'd like to start Emacs on Mac OS X.
When I run 'emacs' comamnd in terminal, I got the error;
signal(error ("Unknown keyword :risky"))
error("Unknown keyword %s" :risky)
custom-handle-keyword(package-load-list :risky t custom-variable)
...
..
What is the 'risky'?
I just install 'Starter Kit'.
How I solve this problem?
===== UPDATE
This error only occure in Built-in Emacs on Mac OSX Terminal.
In GUI Emacs(GNU), It works.
Here is full trace of error.
Debugger entered--Lisp error: (error "Cannot return from the debugger in an error")
signal(error ("Unknown keyword :risky"))
error("Unknown keyword %s" :risky)
custom-handle-keyword(package-load-list :risky t custom-variable)
custom-declare-variable(package-load-list (quote (all)) "List of packages for `package-initialize' to load.\nEach el$
(defcustom package-load-list (quote (all)) "List of packages for `package-initialize' to load.\nEach element in this$
eval-buffer(#> nil "/Users/rushcut/.emacs.d/package.el" nil t) ; Reading at buffer position 9123
load-with-code-conversion("/Users/rushcut/.emacs.d/package.el" "/Users/rushcut/.emacs.d/package.el" nil t)
require(package)
eval-buffer(# nil "/Users/rushcut/.emacs.d/init.el" nil t) ; Reading at buffer position 1099
load-with-code-conversion("/Users/rushcut/.emacs.d/init.el" "/Users/rushcut/.emacs.d/init.el" t t)
load("/Users/rushcut/.emacs.d/init" t t)
#[nil "^H\205\276^# \306=\203^Q^#\307^H\310Q\202A^# \311=\2033^#\312\307\313\314#\203#^#\315\202A^#\312\307\313\31$
command-line()
normal-top-level()
===== FINALLY
Install emacs 23.2.
Everything works fine.
Remove the starter kit, start fresh.
As harpo commented, to debug your actual problem, try starting Emacs with --debug-init, which should provide a stack trace showing what line caused the problem.
But really, get rid of the starter kit.
If you want to start using Emacs, check out all the other questions folks have asked about beginning Emacs and try some of the tips for beginners folks have already given. Of particular interest is a question about starting with Ergo Emacs, which is essentially the same thing as starting off with the Starter Kit.
UPDATE
From your stack trace, it looks as though the version of custom that the starter kit expects is newer than the version shipped with the Emacs you're using on the Mac. The risky is a keyword for defcustom, which was added in Emacs 23.1 (see NEWS.23.1). So, either upgrade your Mac's Emacs, download a newer version of custom (may not be possible at this point), or remove the starter kit by commenting out (require 'package) in your .init.el.