I have a weird mix of errors.
I was using CL21, I was in my package, and I wanted to install lparallel. Not possible:
(ql:quickload :lparallel)
To load "lparallel":
Load 1 ASDF system:
lparallel
; Loading "lparallel"
;
; caught ERROR:
; DYNAMIC-EXTENT on a weird thing: (CL21.CORE.FUNCTION:FUNCTION #:BODY-FN1)
;
; compilation unit aborted
; caught 2 fatal ERROR conditions
; caught 1 ERROR condition
; Evaluation aborted on #<UIOP/LISP-BUILD:COMPILE-FILE-ERROR {1008956C13}>.
I can reproduce it in a new session but it's a bit weird: if I quickload lparallel in cl-user, it complains on not finding the symbol CL21.CORE.FUNCTION, even if I didn't do nothing with CL21 yet:
The name "CL21.CORE.FUNCTION" does not designate any package.
So I ql:quickload CL21 and then on retrying to load lparallel. I get the first error.
But, I tried in Portacle for a fresh image and… I couldn't reproduce this.
Any idea ? Is that an issue with cl21, lparallel, quicklisp or asdf??
cl21 seems to replace the standard reader macro #' with its own version that isn't compatible with lparallel. When you tried to load lparallel in a fresh image, ASDF will load it from the .fasl-files that were compiled with cl21 loaded, so you must either delete those files or force recompilation with
(asdf:operate 'asdf:load-op :lparallel :force t)
Loading cl21 after lparallel is compiled with the standard language shouldn't cause the same problem.
Related
I'm new to Julia and I want to use COBRA Package.
For adding COBRA I use command :
Pkg.add("COBRA")
But when running, I get these errors:
INFO: Building WinRPM
WARNING: skipping repodata/repomd.xml, not in cache -- call WinRPM.update() to download
WARNING: skipping repodata/repomd.xml, not in cache -- call WinRPM.update() to download
INFO: Downloading https://cache.julialang.org/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Leap_42.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270086
WARNING: Retry 1/5 downloading: https://cache.julialang.org/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Leap_42.2/repodata/repomd.xml
until:
WARNING: Unknown download failure, error code: 2148270086
WARNING: Retry 5/5 downloading: https://cache.julialang.org/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Leap_42.2/repodata/repomd.xml
WARNING: received error 0 while downloading
https://cache.julialang.org/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Leap_42.2/repodata/repomd.xml
After these errors, I have checked the link and I've found out the source is not there, anymore.
So then I ran this command as said above:
WinRPM.update()
But it has thrown this error:
ERROR: UndefVarError: WinRPM not defined
Please Help me to add COBRA to Julia. I'm using version 0.6.4 because Cobra does not work on the next versions.(Windows 10)
Any help would be appreciated.
The problem, as you've mentioned, is that the original sources used by the package aren't valid URLs anymore. The proper way to solve this is to open a pull request with the package to change the URLs (which I've now done here ). As a stopgap measure, here's a hacky way to work around this issue for now:
Do a Pkg.add("WinRPM"). This might trigger the same warnings as above, ignore these.
Next, using WinRPM to load the package we added
Now, the source URLs are read from the sources.list file (linked above) into a global WinRPM.sources variable. We're going to edit this variable's contents to point to new working URLs. (This is generally a terrible idea, to directly poke into the internals of a module and change things.)
julia> WinRPM.sources[:] = replace.(WinRPM.sources, "Leap_42.3" => "Leap_15.3")
2-element Vector{String}:
"https://cache.julialang.org/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Leap_15.3"
"https://cache.julialang.org/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_Leap_15.3"
A WinRPM.update() should now work, and download things into a local cache.
I'm using version 0.6.4 because Cobra does not work on the next versions.
I hope you mean Julia 1.6.4 here, or version 0.6.4 of something else in the stack. If you mean Julia version 0.6.4, you might face further problems down the road and find it hard to get support for such an old version.
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.
Up to now in my Lisp adventures I've just been pasting functions as written in a code editor into the REPL to run them, but I now have a program of sufficient size to build on that it will be convenient to use (load "filename.lisp") for the first time in my workflow.
Must I start using packages and/or namespacing to achieve this?
I find that when I use load, as above, I get
** - Continuable Error
DEFUN/DEFMACRO(CLASS): #<PACKAGE CLOS> is locked
If you continue (by typing 'continue'): Ignore the lock and proceed
The following restarts are also available:
SKIP :R1 skip (DEFMACRO CLASS # ...)
RETRY :R2 retry (DEFMACRO CLASS # ...)
STOP :R3 stop loading file /Users/m/cl/ansi-cl/ch17-objects/177d-new-full.lisp
ABORT :R4 Abort main loop
My .lisp file contains a macro called class, so I understand the error, sort of.
The thing is, when I paste the contents of the file directly into the REPL, I get no such error.
What's causing the difference in behaviour?
Is it packages, namespaces or something else?
I can indeed just type continue, and the file will load, but I'd like to understand what is happening here; what's the cause of this "Continuable error", and how should I deal with it if at all?
Package locking in CLISP is explained in the manual.
Symbol class is an ANSI CL symbol, so it cannot name any user-defined entity, and thus your program is not conforming, as explained in 11.1.2.1.2 Constraints on the COMMON-LISP Package for Conforming Programs.
You should rename your macro.
The lack of the error in the REPL is a bug in homebrew clisp.
CLISP as distributed with ubuntu works correctly.
When I build CLISP from sources on Mac, it works correctly too.
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
Here's the scenario: I run compc on a source directory to recompile an already existing library after some changes, which completes successfully. Then I remove the library (the .swc file) and re-compile, which causes many errors to be thrown.
Nothing changed in the interim - clearly this should have either succeeded both times or failed both times.
libs/pv3ddebug $ compc -library-path+=.. -source-path=./src -compiler.optimize -include-sources+=./src -output ../pv3ddebug.swc
Loading configuration file /Users/bill/flex_sdk_3/frameworks/flex-config.xml
/Users/bill/lg/vision/libs/pv3ddebug.swc (152944 bytes)
/libs/pv3ddebug $ rm ../pv3ddebug.swc
/libs/pv3ddebug $ compc -library-path+=.. -source-path=./src -compiler.optimize -include-sources+=./src -output ../pv3ddebug.swc
Loading configuration file /Users/bill/flex_sdk_3/frameworks/flex-config.xml
/Users/bill/lg/vision/libs/pv3ddebug/src/com/phenomblue/pv3ddebug/PV3DDebug.as(45): col: 34 Error: Type was not found or was not a compile-time constant: AdvancedView.
public function PV3DDebug(view:AdvancedView)
^
... more errors follow
I think I've found out why the errors are happening, and can correct them, but I'm disturbed that the first compile didn't fail.
I have a theory:
Library A, which pv3ddebug depends on, was correct
pv3ddebug was compiled successfully (and it correctly)
Library A was brought into a state that would fail to compile with pv3ddebug
pv3ddebug was compiled successfully, incorrectly, because compc didn't notice that A was updated to a failing state
deleting pv3ddebug and then recompiling caused compc to try and compile with the new A, and so the compilation failed.
My questions to you: is step 4 a bug? Is this caching behavior I should have expected, or can change with a compiler switch? Is there something going on that my theory doesn't explain?
You could try -incremental=false. This is supposed to be the default for the command line compiler, but what you're describing sounds like it's enabled.