What's your general approach when quickload fails? I guess I'd like to know the line that provoked the problem, but all I'm given is a backtrace with a reference to a bytecompiled-function. How should I proceed to determine which package, file and form causes the problem?
Update
My environment is ECL in Emacs. The backtrace is provided by the SLIME debugger.
Quicklisp uses ASDF (which usually comes preinstalled), you can try to use it directly to get more detailed error. See manual.
Put (or symlink) your system in one of the standard locations, as subdirectory for example "foo" under
~/common-lisp/ or
~/.local/share/common-lisp/source/.
Try to load it
(asdf:load-system :foo)
Related
When I create a new project with quickprojects, and then load it with asdf:load-system, everything works fine.
But when I come back to emacs after it has been closed and a run (asdf:load-system "system-name"), I get an error:
Component "next" not found
[Condition of type ASDF/FIND-COMPONENT:MISSING-COMPONENT]
I understood the package system to be like a project management system where I can load a package from the repl when I choose.
Which mistake am I making?
In quickproject.lisp, there is the following line:
(pushnew *default-pathname-defaults* asdf:*central-registry*
:test 'equal)
Which is the reason why the system can be loaded: the path to your new project is pushed into ASDF's *central-registry*, which acts like the PATH environment variable in POSIX to indicate where to look for systems.
This change is not persisted and the next time you start Lisp, the variable is set to its default value and the path is not set. I think Quickproject should at least warn that this is happening because it is not very intuitive1
Usually you should add your projects in a path that is visible by ASDF, as explained in 4.1 Configuring ASDF to find your systems. Pushing to *central-registry* works but is old style: 4.2 Configuring ASDF to find your systems — old style.
When using Quicklisp you can also define your projects in ~/quicklisp/local-projects/ (either directly or by using symlinks), which is a place that Quicklisp makes also visible by ASDF.
You can temporarily bind *default-pathname-defaults* to one of these known locations when creating your projects, so that it can be found again when restarting your environment:
(let ((*default-pathname-defaults*
(merge-pathnames "quicklisp/local-projects/"
(user-homedir-pathname)))
(quickproject:make-project "test-project"))
1. To Quickproject's defense, this is explained in the second sentence of the documentation:
Quickproject provides a quick way to make a Common Lisp project. After creating a project, it extends the ASDF registry so the project may be immediately loaded.
I've been playing around with Quicklisp lately, and have this minor problem working with scripts with Shebangs.
Setup
I did the following:
Downloaded quicklisp with curl https://beta.quicklisp.org/quicklisp.lisp -o /tmp/quicklisp.lisp
Installed it with (quicklisp-quickstart:install) while having /tmp/quicklisp loaded in the environment.
Added Quicklisp to init file using (ql:add-to-init-file)
Problem
For a script that needs Quicklisp (specifically ASDF), I can run it with sbcl --load ~/quicklisp/setup.lisp --script start.lisp just fine. However, when I run it as a standalone script with the Shebang /usr/bin/env sbcl --script, it fails with an error saying that it isn't able to find things like UIOP, etc. unless I place the below two lines in the script itself:
(load "~/quicklisp/setup.lisp")
(ql:quickload "asdf")
You can find my stupid experiment here, and the script in question here.
PS: Any pointers would be really helpful.
PPS: I'm sure it's a stupid mistake on my end, forgive me.
In that case you need:
(require :asdf)
TBH, I don't know exactly why. --script equals to --no-sysinit --no-userinit --disable-debugger --end-toplevel-options, so it's a lot we ignore. (thus loading quicklisp's setup.lisp seems required too, because it won't be loaded by your .sbclrc, which is where Quicklisp adds this little snippet)
It's a setting I have needed in other environments, such as a CI.
I would use roswell - which makes standalone scripts available which use Common Lisp code.
I described setting up roswell here. It is super easy.
I describe there system-wide installation of roswell or also how to locally install roswell in ubuntu, mac and windows.
Or you could also directly lookup on roswell's site.
Using roswell would have the advantage that you can use any roswell-installable Common Lisp implementations, which are:
Candidates impls for installation are:
abcl-bin
allegro
ccl-bin
clasp-bin
clasp
clisp
cmu-bin
ecl
mkcl
sbcl-bin
sbcl
sbcl-source
not only sbcl alone.
And roswell allows scripts which are call-able directly from the shell while written in Common Lisp.
From inside roswell $ ros ... commands , quicklisp is available. So $ ros install xxx uses usually quicklisp to install xxx.
Using roswell, you can make any Common Lisp program callable from the bash by a single command - including your script - written in common lisp.
Look at e.g. here:
https://roswell.github.io/Roswell-as-a-Scripting-Environment.html
I am trying to install Julia on Atom. What I made already is that I installed Julia in this folder :
E:\Program files\Users\Zeedo\AppData\Local\Julia-0.6.3
and I installed Atom. Then, I also installed language-Julia package.
Now, when I want to run a code, I get this error:
Julia could not be started.
We tried to launch Julia from:
julia
This path can be changed in the settings.
Details:
'"julia"' is not recognized as an internal or external command,
operable program or batch file.
So, I don't know where should I give the Julia address to the Atom.Or, if you know something that I am doing wrong, please let me know.
Thanks :)
Atom cannot run code by default, so that error message must be being thrown by a community package you've installed. Searching shows me the package is most likely atom-julia-client. And the error seems to be because it can't find the Julia binary it needs to run the program.
First, you should make sure you can run the julia command from the command line directly, which you can check by running julia --version. If this doesn't work, then you need to add the Julia binary to your path.
If the above didn't work, try go to Settings -> Packages -> julia-client. In here, the first setting is Julia Path, which is defaulted to julia (like in the error). Change this to an absolute path, directly to the binary (or to the folder containing the binary; try both if the first doesn't work).
FYI, the language-julia package just gives you syntax highlighting and snippets, and doesn't actually need any Julia stuff to work.
Sometimes, I write code to a file solely for the purpose of checking whether it compiles -- with no interest in the generated binaries.
For example, if I am doing a learning exercise and want to produce some error or see if certain code compiles without error, I'd like to see the ordinary compile output printed to the terminal but without generating the *.hi or *.o files that occur by running ghc <myprogram>.hs.
I sometimes effectively do this using runhaskell, but that is not ideal -- it requires a main function, and actually runs the program whereas I am just looking for a compilation check.
Is there some way to suppress generation when running GHC, only displaying the ordinary compilation errors and warnings?
One of the answers to this question suggested the answer that I'm looking for: ghc option -fno-code.
I.e., compile but don't generate binaries with:
$ ghc -fno-code <myprogram>.hs
In the same spirit to the purpose of the question and in addition to the working answer by #mherzl, my answer below:
while true;do
inotifywait -e modify myprogram.hs
ghc -fno-code myprogram.hs
done
This only works on Linux systems having the inotifywait tool. It blocks an detects if the file is modified.
I meet the following error. Any clue?
CL-USER> (require "asdf")
NIL
But the page https://common-lisp.net/project/asdf/asdf.html#Loading-ASDF said
The recommended way to load ASDF is via:
(require "asdf")
All actively maintained Lisp implementations now include a copy of ASDF 3 that you can load this way using Common Lisp’s require function.1
The specification for PROVIDE, REQUIRE says that the return value of require is implementation-dependant, but that it should signal an error if a module fails to be loaded. In your case, the NIL return value is not an error, but an indication that the operation succeeded.
Try (asdf:make "optima"), for example. Your environment should recognize the ASDF:MAKE symbol, but it might fail to load the :optima system. See Quicklisp to download and install systems.
By the way, you rarely need to require asdf (you don't need to do it in SBCL nor in CCL, at least). To be sure, you might want to restart your Lisp environment and see if the ASDF package exists.