[slime-devel] CMUCL 20a startup issue
I promise to crawl back into my cave shortly... CMUCL 20a is barfing in swank-arglists when starting up SLIME from fasls. It loads fine on the initial compile pass but when it's just loading the swank-arglists fasl, it gets confused somewhere in here (contrib/swank-arglists.lisp): (in-package :swank) ... (eval-when (:compile-toplevel :load-toplevel :execute) (defparameter +lambda-list-keywords+ '(&provided &required &optional &rest &key &any))) (defmacro do-decoded-arglist (decoded-arglist &body clauses) (assert (loop for clause in clauses thereis (member (car clause) +lambda-list-keywords+))) (flet ((parse-clauses (clauses) (let* ((size (load-time-value (length +lambda-list-keywords+))) At first, I assumed this was some sort of bug in CMUCL having to do with package interning and (load-time-value...) although now that I've read the HyperSpec on (load-time-value...) that's less clear. The CLHS says that (l-t-v...) is evaluated in a "null lexical environment" which the glossary says is, "the lexical environment which has no bindings." And since the current package is bound to *package* what CMUCL is doing would seem to be correct. As an experiment, I tried adding explicit package qualification to all of the references to +lambda-list-keywords+ and CMUCL still signals the same error. In other words, CMUCL goes out of it's way to lose the package specifier in (l-t-v...). And yet this code is working in SBCL and Clozure... Can anyone explain what's broken where any maybe suggest a workaround or a fix? I'll be happy to go report this to CMUCL if need be. Thanks! Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER: the variable SWANK:: +LAMBDA-LIST-KEYWORDS+ is unbound. [Condition of type UNBOUND-VARIABLE] Restarts: 0: [CONTINUE] Return NIL from load of #P"/Users/ddp/.slime/fasl/ 2009-11-03/cmu-20a_(20a_uni...". 1: [ABORT] Return to SLIME's top level. 2: [ABORT] Return to Top-Level. Backtrace: 0: ("Load Time Value of (LENGTH +LAMBDA-LIST-KEYWORDS+)")[:TOP-LEVEL] 1: (LISP::FOP-FUNCALL) 2: (LISP::LOAD-GROUP #<Stream for file "/Users/ddp/.slime/fasl/ 2009-11-03/cmu-20a_(20a_unicode)-darwin-x86/contrib/swank- arglists.sse2f">) 3: (LISP::FASLOAD #<Stream for file "/Users/ddp/.slime/fasl/ 2009-11-03/cmu-20a_(20a_unicode)-darwin-x86/contrib/swank- arglists.sse2f">) 4: (LISP::INTERNAL-LOAD #P"/Users/ddp/.slime/fasl/2009-11-03/ cmu-20a_(20a_unicode)-darwin-x86/contrib/swank-arglists.sse2f" ..) 5: (LISP::INTERNAL-LOAD #P"/Users/ddp/.slime/fasl/2009-11-03/ cmu-20a_(20a_unicode)-darwin-x86/contrib/swank-arglists.sse2f" ..) 6: (LOAD #P"/Users/ddp/.slime/fasl/2009-11-03/cmu-20a_(20a_unicode)- darwin-x86/contrib/swank-arglists.sse2f" :VERBOSE NIL :PRINT ...) 7: (REQUIRE :SWANK-ARGLISTS #P"/Users/ddp/.slime/fasl/2009-11-03/ cmu-20a_(20a_unicode)-darwin-x86/contrib/swank-arglists.sse2f") 8: (SWANK:SWANK-REQUIRE (:SWANK-ASDF :SWANK-PACKAGE-FU :SWANK- FUZZY :SWANK-FANCY-INSPECTOR :SWANK-ARGLISTS) NIL) 9: (SWANK::EVAL-FOR-EMACS (SWANK:SWANK-REQUIRE '(:SWANK-ASDF :SWANK- PACKAGE-FU :SWANK-FUZZY :SWANK-FANCY-INSPECTOR :SWANK-ARGLISTS)) "COMMON-LISP-USER" 2) 10: (SWANK::PROCESS-REQUESTS T) 11: ("DEFUN HANDLE-REQUESTS") 12: ("DEFINTERFACE CALL-WITH-DEBUGGER-HOOK" #<Function SWANK:SWANK- DEBUGGER-HOOK {485FF171}> #<Closure Over Function "DEFUN HANDLE- REQUESTS" {489407B9}>) 13: (SWANK::CALL-WITH-BINDINGS NIL #<Closure Over Function "DEFUN CALL-WITH-CONNECTION" {48940819}>) 14: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {488D454D}> #<Closure Over Function "DEFUN HANDLE-REQUESTS" {489407B9}>) 15: (SWANK::HANDLE-REQUESTS #<SWANK::CONNECTION {488D454D}> T) 16: (SWANK::INVOKE-OR-QUEUE-INTERRUPT #<Closure Over Function "DEFUN PROCESS-IO-INTERRUPT" {48940251}>) 17: (SWANK::PROCESS-IO-INTERRUPT #<SWANK::CONNECTION {488D454D}>) 18: (SWANK-BACKEND::SIGIO-HANDLER #<unused-arg> #<unused-arg> #<unused-arg>) 19: ("OnLispStack+#x2F [#xB568] /usr/local/bin/lisp") 20: ("funcall3+#x32 [#xB362] /usr/local/bin/lisp") 21: ("interrupt_handle_now+#x105 [#x7145] /usr/local/bin/lisp") 22: ("_sigtramp+#x2B [#x90ABFB9B] /usr/lib/libSystem.B.dylib") 23: ("Foreign function call land") 24: (LISP::SUB-SERVE-EVENT 1 0) 25: (SYSTEM:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL) 26: (LISP::DO-INPUT #<Stream for Standard Input>) 27: ("PRECOMPILE-EF-SLOT ISO8859-1" #<Stream for Standard Input> NIL (LISP::*EOF*)) 28: (LISP::SYNONYM-IN #<Synonym Stream to SYSTEM:*STDIN*> NIL (LISP::*EOF*)) 29: (LISP::TWO-WAY-IN #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (LISP::*EOF*)) 30: (READ-CHAR #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (LISP::*EOF*) NIL) 31: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (:EOF) T) 32: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (:EOF) NIL) 33: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL 4 #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (:EOF) ...)[:EXTERNAL] 34: (LISP::READ-INTERNAL #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (:EOF) NIL) 35: (READ #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (:EOF) NIL) 36: (LISP::%TOP-LEVEL) 37: ((LABELS LISP::RESTART-LISP SAVE-LISP))
* Derrell Piper [2009-11-03 20:49+0100] writes:
I promise to crawl back into my cave shortly...
CMUCL 20a is barfing in swank-arglists when starting up SLIME from fasls. It loads fine on the initial compile pass but when it's just loading the swank-arglists fasl, it gets confused somewhere in here (contrib/swank-arglists.lisp):
(in-package :swank) ... (eval-when (:compile-toplevel :load-toplevel :execute) (defparameter +lambda-list-keywords+ '(&provided &required &optional &rest &key &any)))
(defmacro do-decoded-arglist (decoded-arglist &body clauses) (assert (loop for clause in clauses thereis (member (car clause) +lambda-list-keywords+))) (flet ((parse-clauses (clauses) (let* ((size (load-time-value (length +lambda-list-keywords+)))
At first, I assumed this was some sort of bug in CMUCL having to do with package interning and (load-time-value...) although now that I've read the HyperSpec on (load-time-value...) that's less clear. The CLHS says that (l-t-v...) is evaluated in a "null lexical environment" which the glossary says is, "the lexical environment which has no bindings." And since the current package is bound to *package* what CMUCL is doing would seem to be correct. As an experiment, I tried adding explicit package qualification to all of the references to +lambda-list-keywords+ and CMUCL still signals the same error. In other words, CMUCL goes out of it's way to lose the package specifier in (l-t-v...).
And yet this code is working in SBCL and Clozure... Can anyone explain what's broken where any maybe suggest a workaround or a fix? I'll be happy to go report this to CMUCL if need be. Thanks!
I think it's the CMUCL bug related to c::top-level-lambda-max. CMUCL reads that many toplevel forms and compiles them together as one block. Doing so should give the compiler a larger optimization window, but unfortunately CMUCL doesn't preserve the order of some load-time actions as it should. I don't know why load-time-value is used here. Maybe a mundane #. would do the job? Helmut
Derrell Piper <ddp@electric-loft.org> writes:
I promise to crawl back into my cave shortly...
CMUCL 20a is barfing in swank-arglists when starting up SLIME from fasls. It loads fine on the initial compile pass but when it's just loading the swank-arglists fasl, it gets confused somewhere in here (contrib/swank-arglists.lisp):
(in-package :swank) ... (eval-when (:compile-toplevel :load-toplevel :execute) (defparameter +lambda-list-keywords+ '(&provided &required &optional &rest &key &any)))
(defmacro do-decoded-arglist (decoded-arglist &body clauses) (assert (loop for clause in clauses thereis (member (car clause) +lambda-list-keywords+))) (flet ((parse-clauses (clauses) (let* ((size (load-time-value (length +lambda-list-keywords+)))
At first, I assumed this was some sort of bug in CMUCL having to do with package interning and (load-time-value...) although now that I've read the HyperSpec on (load-time-value...) that's less clear. The CLHS says that (l-t-v...) is evaluated in a "null lexical environment" which the glossary says is, "the lexical environment which has no bindings." And since the current package is bound to *package* what CMUCL is doing would seem to be correct. As an experiment, I tried adding explicit package qualification to all of the references to +lambda-list-keywords+ and CMUCL still signals the same error. In other words, CMUCL goes out of it's way to lose the package specifier in (l-t-v...).
And yet this code is working in SBCL and Clozure... Can anyone explain what's broken where any maybe suggest a workaround or a fix? I'll be happy to go report this to CMUCL if need be. Thanks!
I think that was a mistake on my part. Thanks for the report, -T.
Yup, that fixed it, thanks! On Nov 3, 2009, at 5:15 PM, Tobias C. Rittweiler wrote:
Derrell Piper <ddp@electric-loft.org> writes:
I promise to crawl back into my cave shortly...
CMUCL 20a is barfing in swank-arglists when starting up SLIME from fasls. It loads fine on the initial compile pass but when it's just loading the swank-arglists fasl, it gets confused somewhere in here (contrib/swank-arglists.lisp):
(in-package :swank) ... (eval-when (:compile-toplevel :load-toplevel :execute) (defparameter +lambda-list-keywords+ '(&provided &required &optional &rest &key &any)))
(defmacro do-decoded-arglist (decoded-arglist &body clauses) (assert (loop for clause in clauses thereis (member (car clause) +lambda-list-keywords+))) (flet ((parse-clauses (clauses) (let* ((size (load-time-value (length +lambda-list-keywords +)))
At first, I assumed this was some sort of bug in CMUCL having to do with package interning and (load-time-value...) although now that I've read the HyperSpec on (load-time-value...) that's less clear. The CLHS says that (l-t-v...) is evaluated in a "null lexical environment" which the glossary says is, "the lexical environment which has no bindings." And since the current package is bound to *package* what CMUCL is doing would seem to be correct. As an experiment, I tried adding explicit package qualification to all of the references to +lambda-list-keywords+ and CMUCL still signals the same error. In other words, CMUCL goes out of it's way to lose the package specifier in (l-t-v...).
And yet this code is working in SBCL and Clozure... Can anyone explain what's broken where any maybe suggest a workaround or a fix? I'll be happy to go report this to CMUCL if need be. Thanks!
I think that was a mistake on my part. Thanks for the report,
-T.
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
BTW, just to clarify the l-t-v semantics: all dynamic variable bindings in the global and dynamic environments at load time are available, even though the null lexical environment has no bindings. The null lexical environment just prevents you from mixing up load time and execution time like this: (let ((foo (print 10))) ; a lexical binding (load-time-value foo)) __Martin
On Tue, 3 Nov 2009 17:57:13 -0500, Derrell Piper said:
Yup, that fixed it, thanks!
On Nov 3, 2009, at 5:15 PM, Tobias C. Rittweiler wrote:
Derrell Piper <ddp@electric-loft.org> writes:
I promise to crawl back into my cave shortly...
CMUCL 20a is barfing in swank-arglists when starting up SLIME from fasls. It loads fine on the initial compile pass but when it's just loading the swank-arglists fasl, it gets confused somewhere in here (contrib/swank-arglists.lisp):
(in-package :swank) ... (eval-when (:compile-toplevel :load-toplevel :execute) (defparameter +lambda-list-keywords+ '(&provided &required &optional &rest &key &any)))
(defmacro do-decoded-arglist (decoded-arglist &body clauses) (assert (loop for clause in clauses thereis (member (car clause) +lambda-list-keywords+))) (flet ((parse-clauses (clauses) (let* ((size (load-time-value (length +lambda-list-keywords +)))
At first, I assumed this was some sort of bug in CMUCL having to do with package interning and (load-time-value...) although now that I've read the HyperSpec on (load-time-value...) that's less clear. The CLHS says that (l-t-v...) is evaluated in a "null lexical environment" which the glossary says is, "the lexical environment which has no bindings." And since the current package is bound to *package* what CMUCL is doing would seem to be correct. As an experiment, I tried adding explicit package qualification to all of the references to +lambda-list-keywords+ and CMUCL still signals the same error. In other words, CMUCL goes out of it's way to lose the package specifier in (l-t-v...).
And yet this code is working in SBCL and Clozure... Can anyone explain what's broken where any maybe suggest a workaround or a fix? I'll be happy to go report this to CMUCL if need be. Thanks!
I think that was a mistake on my part. Thanks for the report,
-T.
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Martin Simmons <martin@lispworks.com> writes:
BTW, just to clarify the l-t-v semantics: all dynamic variable bindings in the global and dynamic environments at load time are available, even though the null lexical environment has no bindings. The null lexical environment just prevents you from mixing up load time and execution time like this:
(let ((foo (print 10))) ; a lexical binding (load-time-value foo))
It's unfortunately not as easy as that because of: It is guaranteed that the evaluation of [L-V-T's] form will take place only once when the file is loaded, but the order of evaluation with respect to the evaluation of top level forms in the file is implementation-dependent. So L-V-T cannot portably access variables defined in other toplevel forms of the same file. -T.
participants (4)
-
Derrell Piper -
Helmut Eller -
Martin Simmons -
Tobias C. Rittweiler