I was a happy user of Dexador. Suddenly, a simple dex:get<url> throws me a
quri.parser::parse-scheme-string is undefined
error.
Trying (dex:get url):
0: ("undefined function")
1: (quri.parser::parse-uri-string #<unavailable argument> :start #<unavailable argument> :end #<unavailable argument>)
2: (quri.uri:uri "http://1337x.to/sort-search/sintel/seeders/desc/1/" :start 0 :end nil)
3: (dexador.backend.usocket:request #<unavailable argument> #<unavailable &REST argument> :method #<unused argument> :version #<unused argument> :content #<unavailable argument> :headers #<unavailable ar.
It seems related to my environment. I think it popped out after I downgraded my QL version (because of a Slime error).
edit: I once accepted this error on the debugger, it doesn't pop-up anymore.
It's weird: neither Dexador nor Quri were modified recently. It used to work.
Also, I greped Dexador and Quri, in my QL's local dist projects, to find this function, and it only appears once in Quri. It is not even a defined function, so how could it even work ? (given the package uses cl, quri.error and quri.util) https://github.com/fukamachi/quri/blob/83f3b8612be826b602f3584acac1b82691a141e6/src/parser.lisp#L96
I deleted the fasl files found in my project.
Anyway, how would you approach this problem ?
I still don't want to upgrade Quicklisp, Slime didn't release a new version.
edit: I upgraded QL, then deleted ~/quicklisp/ and re-installed it, deleted all ~/.cache/common-lisp: the same.
thanks.
SBCL Debian 1.2.4 (installed 1.4.13, couldn't load my project with another ironclad error).
Quicklisp dist "2018-04-30".
I also asked in an issue https://github.com/fukamachi/dexador/issues/61#issuecomment-433672052
The macro used format to intern new symbols, and I set *print-case* to :downcase in my .sbclrc.
There's a fix: https://github.com/fukamachi/quri/pull/24
Deleting the fasl cached in ~/.cache/common-lisp/sbcl-xx/quri/ and quickloading quri was then enough to have the function back.
Related
I'm trying to run a program under CCL, so that when the program finishes running for any reason, it should exit back to the operating system. Currently using this command line (on Windows):
\ccl\wx86cl -l test.lisp -e (quit)
This exits when the program successfully runs to normal completion, but if there is an error e.g. out of memory, it ends up in the debugger. How do you tell Clozure to also exit when there is an error?
Not only you want to catch all errors, but you also want to prevent going into the debugger when INVOKE-DEBUGGER is called. You can set *DEBUGGER-HOOK* to a function that quits on unhandled errors.
$ ./bin/ccl/lx86cl64
Clozure Common Lisp Version 1.11.5/v1.11.5 (LinuxX8664)
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.
? *debugger-hook*
NIL
? (setf *debugger-hook*
(lambda (error hook)
(declare (ignore hook))
(format *error-output* "Crash: ~a" error)
(quit)))
#<Anonymous Function #x302000998C3F>
Now, test it with an unhandled error:
? (error "Oh no")
Crash: Oh no
Then, you are back to the shell.
Notice that BREAK always enters the debugger, because it binds *debugger-hook* to NIL (this is on purpose, for debugging).
I'm trying to run an executable with an Hunchentoot server and I'm getting (after an unusual high CPU usage):
<INFO> [17:55:14] weblocks/server server.lisp (start) -
Starting weblocks WEBLOCKS/SERVER::PORT: 40001
WEBLOCKS/SERVER::SERVER-TYPE: :HUNCHENTOOT DEBUG: T
debugger invoked on a SB-INT:EXTENSION-FAILURE in thread
#<THREAD "main thread" RUNNING {1008C1EA13}>:
Don't know how to REQUIRE sb-cltl2.
Do you have any idea what's going on ? It works correctly on Slime where I use the start function.
(sbcl manual: http://www.sbcl.org/manual/#Customization-Hooks-for-Users)
In the main entry point, I try to capture the running thread so that I keep the server running on the foreground (my notes). This pattern worked with another clack-based web framework.
(defun start ()
(weblocks/debug:on)
(weblocks/server:start :port *port*))
(defun main ()
(defvar *port* (find-port:find-port))
(start)
(handler-case (bt:join-thread (find-if (lambda (th)
(search "hunchentoot" (bt:thread-name th)))
(bt:all-threads)))
(#+sbcl sb-sys:interactive-interrupt
#+ccl ccl:interrupt-signal-condition
#+clisp system::simple-interrupt-condition
#+ecl ext:interactive-interrupt
#+allegro excl:interrupt-signal
() (progn
(format *error-output* "Aborting.~&")
(uiop:quit 1))
;; for others, unhandled errors (we might want to do the same).
(error (c) (format t "Woops, an unknown error occured:~&~a~&" c)))))
Or any indication of what could be the cause ?
Thanks again.
(I'm using 40ants' weblocks:reblocks branch)
SBCL Debian 1.2.4
edit I tried
export SBCL_HOME=/usr/local/lib/sbcl/
I build with
build:
$(LISP) --quit \
--eval '(ql:quickload "foo")' \
--eval '(require :sb-cltl2)' \
--eval '(asdf:make :foo)'
=>
fatal error encountered in SBCL pid 25248(tid 140737353910016):
can't load .core for different runtime, sorry
Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>
The following environment failed:
export SBCL_HOME=/usr/local/lib/sbcl/
The error message tells us the following:
can't load .core for different runtime, sorry
Apparently the SBCL you ran used the given SBCL_HOME to find its core file, but failed due to the core being generated by different version SBCL.
A quick look at SBCL's source (starting from require) shows that the underlying function #'SB-INT:SBCL-HOMEDIR-PATHNAME is called to determine the installation path.
It looks like the one installed from the Debian package was installed in /usr/lib/sbcl/. The core file was easily found when starting Slime. You also had another version of SBCL in ~/.roswell/, but I guess you also ran ros install which installed it under /usr/local/lib/sbcl (/usr/local/ is for software that is not managed by the system).
Starting the roswell one when setting SBCL_HOME to the directory of the Debian one provoked the error about the incompatible core file (I guess).
What remains suprising is that (SB-INT:SBCL-HOMEDIR-PATHNAME) returns nil when starting your main function.
Some days ago I updated SBCL to 1.2.1 and I thought it couldn't hurt to update the quick lisp dist/client as well.
WRONG!
After firing up slime in Emacs, I got this error:
; caught ERROR:
; READ error during COMPILE-FILE:
;
; Symbol "CODE-TRACE-TABLE-OFFSET-SLOT" not found in the SB-VM package.
;
; Line: 1507, Column: 70, File-Position: 60197
;
; Stream: #<SB-SYS:FD-STREAM
; for "file /Users/fyi/quicklisp/dists/quicklisp/software/slime-2.7/swank-sbcl.lisp"
; {1008B07E43}>
;
; compilation unit aborted
; caught 1 fatal ERROR condition
; caught 1 ERROR condition
; printed 1 note
;;
;; Error while compiling /Users/fyi/quicklisp/dists/quicklisp/software/slime-2.7/swank-sbcl.lisp:
;; COMPILE-FILE returned NIL.
;; Aborting.
If you're using the quicklisp-slime-helper, so as I, the path to slime comes form the ~/quicklisp/dists/quicklisp/installed/systems/swank.txt file. Slime 2.8 should fix that error, but there is no quicklisp distribution that contains slime 2.8.
Coming down to my actual question. Is there a way to specify a library location outside of a quicklisp distribution? Or will I have to wait unit the next distribution has been made available and is there a guaranty a library will be updated in the next distribution?
I am sure I'm missing something, but the whole distribution stuff seems to me more of a hindrance than a help.
The next Quicklisp dist update is coming July 12 or 13. It will include a new SLIME that is compatible with SBCL 1.2.1. In the meantime, the easiest fix is to install SBCL 1.2.0.
Another option is to comment out the quicklisp-slime-helper lines in ~/.emacs and install slime according to its own procedure.
I am working some lisp code on sbcl in order to run function in mode daemon.
The problem is when I use the function sb-thred:make-thread, for instance as follow:
(sb-thread:make-thread (lambda () (progn (sleep 1) (when t (print "background action")))))
I get the following error message:
Not supported in unithread builds. [Condition of type SIMPLE-ERROR]
What is wrong ? ... thanks for help.
SBCL has threads disabled by default on Mac OS X. To check if SBCL is build with threads run in the repl
(member :sb-thread *features*)
If not, compile it from source (using your current SBCL). From the INSTALL
sh make.sh --with-sb-thread
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.