package-inferred-system noob-user confusion
Greetings, I am a common-lisp noob. I am not a programmer noob, nor a build system noob. I have carefully studied fare's asdf manual, pages 25-26 in the pdf and backwards through the reverse dependencies of the terms used, about the package-inferred-system. I have a problem that I've whittled down to a very small snippet. I'm using SBCL 2.4.10.117-507e7ae05 and its native ASDF, but also tested against ASDF repo head (ln -s into ~/common-lisp, verified in the repl). My question is why this system, located in file "./hello.asd", containing: ***************************************************************** (asdf:defsystem "hello" :class :package-inferred-system :depends-on ("hello/src/main")) ***************************************************************** paired with the system/package file "./src/main.lisp", containing: ****************************************************************** (uiop:define-package :hello/src/main ;; (:use :alexandria) ;; XXXRLC This line fails: "The variable MAIN ;; is unbound". I have no idea why. Backtrace provides no clues ;; (to me). Load the library in the repl matters not. Elide that ;; line and (asdf:load-system "hello") => T and then CL-USER> ;; (hello/src/main:main) => urg \n "urg" as expected. (:export #:main)) (in-package :hello/src/main) (defun main () (write-line "urg")) ******************************************************************* fails as described in the comment. Sure I would like the answer but the more interesting question is how could I debug this failure? I slogged through the late '90s debugging complex C++ template programming errors. Pages and pages of output. I don't mind doing it again. But I don't know where to start with this ASDF build system. Thank you for any suggestions, obviously the answer must be trivial. All the best, Russell L. Carter
Will you please post a backtrace from SBCL for this. I'm not at all sure I understand what you mean by "this line fails." What did you do to trigger the error? `(asdf:load-system "hello")` ? On 8 Jan 2025, at 17:37, Russell L. Carter wrote:
Greetings,
I am a common-lisp noob. I am not a programmer noob, nor a build system noob.
I have carefully studied fare's asdf manual, pages 25-26 in the pdf and backwards through the reverse dependencies of the terms used, about the package-inferred-system. I have a problem that I've whittled down to a very small snippet.
I'm using SBCL 2.4.10.117-507e7ae05 and its native ASDF, but also tested against ASDF repo head (ln -s into ~/common-lisp, verified in the repl).
My question is why this system, located in file "./hello.asd", containing:
***************************************************************** (asdf:defsystem "hello" :class :package-inferred-system :depends-on ("hello/src/main")) *****************************************************************
paired with the system/package file "./src/main.lisp", containing:
****************************************************************** (uiop:define-package :hello/src/main ;; (:use :alexandria) ;; XXXRLC This line fails: "The variable MAIN ;; is unbound". I have no idea why. Backtrace provides no clues ;; (to me). Load the library in the repl matters not. Elide that ;; line and (asdf:load-system "hello") => T and then CL-USER> ;; (hello/src/main:main) => urg \n "urg" as expected. (:export #:main))
(in-package :hello/src/main) (defun main () (write-line "urg")) *******************************************************************
fails as described in the comment. Sure I would like the answer but the more interesting question is how could I debug this failure?
I slogged through the late '90s debugging complex C++ template programming errors. Pages and pages of output. I don't mind doing it again. But I don't know where to start with this ASDF build system.
Thank you for any suggestions, obviously the answer must be trivial.
All the best, Russell L. Carter
Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC) 319 N. First Ave., Suite 400 Minneapolis, MN 55401 Google Voice: (612) 326-3934 Cell: (612) 384-3454 Email: rpgoldman@SIFT.net
I apologize. Here is the backtrace, and the repl interaction that triggered it, after: The variable MAIN is unbound. [Condition of type COMMON-LISP:UNBOUND-VARIABLE] Restarts: 0: [CONTINUE] Retry using MAIN. 1: [USE-VALUE] Use specified value. 2: [STORE-VALUE] Set specified value and use it. 3: [TRY-RECOMPILING] Recompile lisp and try loading it again 4: [RETRY] Retry loading FASL for #<CL-SOURCE-FILE "hello/src/main" "lisp">. 5: [ACCEPT] Continue, treating loading FASL for #<CL-SOURCE-FILE "hello/src/main" "lisp"> as having been successful. 6: [RETRY] Retry ASDF operation. 7: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration. 8: [RETRY] Retry ASDF operation. 9: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration. 10: [RETRY] Retry SLY mREPL evaluation request. 11: [*ABORT] Return to SLY's top level. 12: [ABORT] abort thread (#<THREAD tid=1942451 "sly-channel-1-mrepl-remote-1" RUNNING {1000BD0003}>) Backtrace: 0: ("top level form") [toplevel] 1: (SB-FASL::LOAD-FASL-GROUP #S(SB-FASL::FASL-INPUT :STREAM #<SB-SYS:FD-STREAM for "file /mnt/sata/02/home/rcarter/.cache/common-lisp/sbcl-2.4.10.117-507e7ae05-linux-x64/mnt/sata/02/home/rcarter/common-l.. 2: ((COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN SB-FASL::LOAD-AS-FASL)) 3: (SB-IMPL::CALL-WITH-LOADER-PACKAGE-NAMES #<FUNCTION (COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN SB-FASL::LOAD-AS-FASL) {10029D233B}>) 4: (SB-FASL::LOAD-AS-FASL #<SB-SYS:FD-STREAM for "file /mnt/sata/02/home/rcarter/.cache/common-lisp/sbcl-2.4.10.117-507e7ae05-linux-x64/mnt/sata/02/home/rcarter/common-lisp/sandbox/clip/v6/src/main.fasl".. 5: ((COMMON-LISP:LABELS SB-FASL::LOAD-STREAM-1 :IN COMMON-LISP:LOAD) #<SB-SYS:FD-STREAM for "file /mnt/sata/02/home/rcarter/.cache/common-lisp/sbcl-2.4.10.117-507e7ae05-linux-x64/mnt/sata/02/home/rcarter.. 6: (SB-FASL::CALL-WITH-LOAD-BINDINGS #<FUNCTION (COMMON-LISP:LABELS SB-FASL::LOAD-STREAM-1 :IN COMMON-LISP:LOAD) {7FC3CF014C3B}> #<SB-SYS:FD-STREAM for "file /mnt/sata/02/home/rcarter/.cache/common-lisp/.. 7: (COMMON-LISP:LOAD #P"/mnt/sata/02/home/rcarter/.cache/common-lisp/sbcl-2.4.10.117-507e7ae05-linux-x64/mnt/sata/02/home/rcarter/common-lisp/sandbox/clip/v6/src/main.fasl" :VERBOSE COMMON-LISP:NIL :PRIN.. 8: (UIOP/UTILITY:CALL-WITH-MUFFLED-CONDITIONS #<FUNCTION (COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN UIOP/LISP-BUILD:LOAD*) {10029C50CB}> ("Overwriting already existing readtable ~S." #(#:FINALIZERS-OFF-WARN.. 9: ((SB-PCL::EMF ASDF/ACTION:PERFORM) #<unused argument> #<unused argument> #<ASDF/LISP-ACTION:LOAD-OP > #<ASDF/LISP-ACTION:CL-SOURCE-FILE "hello/src/main" "lisp">) 10: ((COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN ASDF/ACTION:CALL-WHILE-VISITING-ACTION)) 11: ((:METHOD ASDF/ACTION:PERFORM-WITH-RESTARTS (ASDF/LISP-ACTION:LOAD-OP ASDF/LISP-ACTION:CL-SOURCE-FILE)) #<ASDF/LISP-ACTION:LOAD-OP > #<ASDF/LISP-ACTION:CL-SOURCE-FILE "hello/src/main" "lisp">) [fast-m.. 12: ((:METHOD ASDF/ACTION:PERFORM-WITH-RESTARTS :AROUND (COMMON-LISP:T COMMON-LISP:T)) #<ASDF/LISP-ACTION:LOAD-OP > #<ASDF/LISP-ACTION:CL-SOURCE-FILE "hello/src/main" "lisp">) [fast-method] 13: ((:METHOD ASDF/PLAN:PERFORM-PLAN (COMMON-LISP:T)) #<ASDF/PLAN:SEQUENTIAL-PLAN {1002888C03}>) [fast-method] 14: ((COMMON-LISP:FLET SB-C::WITH-IT :IN SB-C::%WITH-COMPILATION-UNIT)) 15: ((:METHOD ASDF/PLAN:PERFORM-PLAN :AROUND (COMMON-LISP:T)) #<ASDF/PLAN:SEQUENTIAL-PLAN {1002888C03}>) [fast-method] 16: ((:METHOD ASDF/OPERATE:OPERATE (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)) #<ASDF/LISP-ACTION:LOAD-OP > #<ASDF/PACKAGE-INFERRED-SYSTEM:PACKAGE-INFERRED-SYSTEM "hello"> :PLAN-CLASS COMMON-LISP.. 17: ((SB-PCL::EMF ASDF/OPERATE:OPERATE) #<unused argument> #<unused argument> #<ASDF/LISP-ACTION:LOAD-OP > #<ASDF/PACKAGE-INFERRED-SYSTEM:PACKAGE-INFERRED-SYSTEM "hello">) 18: ((COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN ASDF/OPERATE:OPERATE)) 19: ((:METHOD ASDF/OPERATE:OPERATE :AROUND (COMMON-LISP:T COMMON-LISP:T)) #<ASDF/LISP-ACTION:LOAD-OP > #<ASDF/PACKAGE-INFERRED-SYSTEM:PACKAGE-INFERRED-SYSTEM "hello">) [fast-method] 20: ((SB-PCL::EMF ASDF/OPERATE:OPERATE) #<unused argument> #<unused argument> ASDF/LISP-ACTION:LOAD-OP "hello") 21: ((COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN ASDF/OPERATE:OPERATE)) 22: ((:METHOD ASDF/OPERATE:OPERATE :AROUND (COMMON-LISP:T COMMON-LISP:T)) ASDF/LISP-ACTION:LOAD-OP "hello") [fast-method] 23: (ASDF/SESSION:CALL-WITH-ASDF-SESSION #<FUNCTION (COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN ASDF/OPERATE:OPERATE) {100288327B}> :OVERRIDE COMMON-LISP:T :KEY COMMON-LISP:NIL :OVERRIDE-CACHE COMMON-LISP:T :.. 24: ((COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN ASDF/OPERATE:OPERATE)) 25: (ASDF/SESSION:CALL-WITH-ASDF-SESSION #<FUNCTION (COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN ASDF/OPERATE:OPERATE) {100287054B}> :OVERRIDE COMMON-LISP:NIL :KEY COMMON-LISP:NIL :OVERRIDE-CACHE COMMON-LISP:N.. 26: ((:METHOD ASDF/OPERATE:OPERATE :AROUND (COMMON-LISP:T COMMON-LISP:T)) ASDF/LISP-ACTION:LOAD-OP "hello") [fast-method] 27: (ASDF/OPERATE:LOAD-SYSTEM "hello") 28: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF/OPERATE:LOAD-SYSTEM "hello") #<NULL-LEXENV>) 29: (COMMON-LISP:EVAL (ASDF/OPERATE:LOAD-SYSTEM "hello")) 30: ((COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN SLYNK-MREPL::MREPL-EVAL-1)) 31: (SLYNK::CALL-WITH-RETRY-RESTART "Retry SLY mREPL evaluation request." #<FUNCTION (COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN SLYNK-MREPL::MREPL-EVAL-1) {10027BFACB}>) 32: ((COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN SLYNK-MREPL::MREPL-EVAL-1)) 33: ((COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN SLYNK::CALL-WITH-LISTENER)) 34: (SLYNK::CALL-WITH-BINDINGS ((COMMON-LISP:*PACKAGE* . #<COMMON-LISP:PACKAGE "COMMON-LISP-USER">) (COMMON-LISP:*DEFAULT-PATHNAME-DEFAULTS* . #P"/mnt/sata/02/home/rcarter/common-lisp/sandbox/clip/v6/src/.. 35: (SLYNK-MREPL::MREPL-EVAL-1 #<SLYNK-MREPL::MREPL mrepl-1-1> "(asdf:load-system \"hello\")") 36: (SLYNK-MREPL::MREPL-EVAL #<SLYNK-MREPL::MREPL mrepl-1-1> "(asdf:load-system \"hello\")") 37: (SLYNK:PROCESS-REQUESTS COMMON-LISP:NIL) 38: ((COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN SLYNK::SPAWN-CHANNEL-THREAD)) 39: ((COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN SLYNK::SPAWN-CHANNEL-THREAD)) 40: (SLYNK-SBCL::CALL-WITH-BREAK-HOOK #<FUNCTION SLYNK:SLYNK-DEBUGGER-HOOK> #<FUNCTION (COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN SLYNK::SPAWN-CHANNEL-THREAD) {10031E000B}>) 41: ((COMMON-LISP:FLET SLYNK-BACKEND:CALL-WITH-DEBUGGER-HOOK :IN "/mnt/sata/02/home/rcarter/.config/emacs/elpa/sly-20240809.2119/slynk/backend/sbcl.lisp") #<FUNCTION SLYNK:SLYNK-DEBUGGER-HOOK> #<FUNCTION .. 42: ((COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN SLYNK::CALL-WITH-LISTENER)) 43: (SLYNK::CALL-WITH-BINDINGS ((COMMON-LISP:*PACKAGE* . #<COMMON-LISP:PACKAGE "COMMON-LISP-USER">) (COMMON-LISP:*DEFAULT-PATHNAME-DEFAULTS* . #P"/mnt/sata/02/home/rcarter/common-lisp/sandbox/clip/v6/src/.. 44: ((COMMON-LISP:LAMBDA COMMON-LISP:NIL :IN SLYNK::SPAWN-CHANNEL-THREAD)) 45: ((COMMON-LISP:FLET SB-UNIX::BODY :IN SB-THREAD::RUN)) 46: ((COMMON-LISP:FLET "WITHOUT-INTERRUPTS-BODY-" :IN SB-THREAD::RUN)) 47: ((COMMON-LISP:FLET SB-UNIX::BODY :IN SB-THREAD::RUN)) 48: ((COMMON-LISP:FLET "WITHOUT-INTERRUPTS-BODY-" :IN SB-THREAD::RUN)) 49: (SB-THREAD::RUN) 50: ("foreign function: call_into_lisp_") 51: ("foreign function: funcall1") Triggered by: CL-USER> (asdf:load-system "hello") ; compiling file "/mnt/sata/02/home/rcarter/common-lisp/sandbox/clip/v6/src/main.lisp" (written 08 JAN 2025 07:38:22 PM): ; wrote /mnt/sata/02/home/rcarter/.cache/common-lisp/sbcl-2.4.10.117-507e7ae05-linux-x64/mnt/sata/02/home/rcarter/common-lisp/sandbox/clip/v6/src/main-tmp1CXFJSK9.fasl ; compilation finished in 0:00:00.000 ; Debugger entered on #<UNBOUND-VARIABLE MAIN {10029D3033}> [1] CL-USER> I would be grateful if anyone could point out where I should start looking in the above output, next time. Teach a person to fish... All the best, Russell On 1/8/25 6:58 PM, Robert Goldman wrote:
Will you please post a backtrace from SBCL for this. I'm not at all sure I understand what you mean by "this line fails."
What did you do to trigger the error?
|(asdf:load-system "hello")|
?
On 8 Jan 2025, at 17:37, Russell L. Carter wrote:
Greetings,
I am a common-lisp noob. I am not a programmer noob, nor a build system noob.
I have carefully studied fare's asdf manual, pages 25-26 in the pdf and backwards through the reverse dependencies of the terms used, about the package-inferred-system. I have a problem that I've whittled down to a very small snippet.
I'm using SBCL 2.4.10.117-507e7ae05 and its native ASDF, but also tested against ASDF repo head (ln -s into ~/common-lisp, verified in the repl).
My question is why this system, located in file "./hello.asd", containing:
------------------------------------------------------------------------
(asdf:defsystem "hello" :class :package-inferred-system :depends-on ("hello/src/main"))
------------------------------------------------------------------------
paired with the system/package file "./src/main.lisp", containing:
------------------------------------------------------------------------
(uiop:define-package :hello/src/main ;; (:use :alexandria) ;; XXXRLC This line fails: "The variable MAIN ;; is unbound". I have no idea why. Backtrace provides no clues ;; (to me). Load the library in the repl matters not. Elide that ;; line and (asdf:load-system "hello") => T and then CL-USER> ;; (hello/src/main:main) => urg \n "urg" as expected. (:export #:main))
(in-package :hello/src/main) (defun main () (write-line "urg"))
------------------------------------------------------------------------
fails as described in the comment. Sure I would like the answer but the more interesting question is how could I debug this failure?
I slogged through the late '90s debugging complex C++ template programming errors. Pages and pages of output. I don't mind doing it again. But I don't know where to start with this ASDF build system.
Thank you for any suggestions, obviously the answer must be trivial.
All the best, Russell L. Carter
Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC)
319 N. First Ave., Suite 400 Minneapolis, MN 55401
Google Voice: (612) 326-3934 Cell: (612) 384-3454 Email: rpgoldman@SIFT.net <mailto:rpgoldman@SIFT.net>
For the record, I can reproduce the behavior noted in the comments -- (asdf:load-system "hello") succeeds if (:use :alexandria) is omitted, and fails with "Variable MAIN is unbound" otherwise. I am working with SBCL. It appears that the .lisp was successfully compiled, and the error occurs when trying to load the resulting .fasl. After some tinkering, I think the problem is that the symbols DEFUN and WRITE-LINE aren't being resolved to symbols in the symbol package COMMON-LISP. I can get the example to work, with (:use :alexandria), by either writing cl:defun and cl:write-line in the code, or saying (:use :common-lisp) in the package definition. I don't know offhand why the symbols aren't resolved in the presence of (:use :alexandria), no doubt there's a simple explanation. Hope this helps, Robert On Wed, Jan 8, 2025 at 3:58 PM Robert Goldman <rpgoldman@sift.info> wrote:
Will you please post a backtrace from SBCL for this. I'm not at all sure I understand what you mean by "this line fails."
What did you do to trigger the error?
(asdf:load-system "hello")
?
On 8 Jan 2025, at 17:37, Russell L. Carter wrote:
Greetings,
I am a common-lisp noob. I am not a programmer noob, nor a build system noob.
I have carefully studied fare's asdf manual, pages 25-26 in the pdf and backwards through the reverse dependencies of the terms used, about the package-inferred-system. I have a problem that I've whittled down to a very small snippet.
I'm using SBCL 2.4.10.117-507e7ae05 and its native ASDF, but also tested against ASDF repo head (ln -s into ~/common-lisp, verified in the repl).
My question is why this system, located in file "./hello.asd", containing:
________________________________
(asdf:defsystem "hello" :class :package-inferred-system :depends-on ("hello/src/main"))
________________________________
paired with the system/package file "./src/main.lisp", containing:
________________________________
(uiop:define-package :hello/src/main ;; (:use :alexandria) ;; XXXRLC This line fails: "The variable MAIN ;; is unbound". I have no idea why. Backtrace provides no clues ;; (to me). Load the library in the repl matters not. Elide that ;; line and (asdf:load-system "hello") => T and then CL-USER> ;; (hello/src/main:main) => urg \n "urg" as expected. (:export #:main))
(in-package :hello/src/main) (defun main () (write-line "urg"))
________________________________
fails as described in the comment. Sure I would like the answer but the more interesting question is how could I debug this failure?
I slogged through the late '90s debugging complex C++ template programming errors. Pages and pages of output. I don't mind doing it again. But I don't know where to start with this ASDF build system.
Thank you for any suggestions, obviously the answer must be trivial.
All the best, Russell L. Carter
Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC)
319 N. First Ave., Suite 400 Minneapolis, MN 55401
Google Voice: (612) 326-3934 Cell: (612) 384-3454 Email: rpgoldman@SIFT.net
My memories are dim, but I believe it's a case of absence of :use argument being the same as (:use :common-lisp) but if you have an explicit :use argument, you need to explicitly include :common-lisp in the list for it to be included. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org “The only saving grace of government is that they’re incompetent, because if they could do what they really want, it would be horrible for all of us” On Thu, Jan 9, 2025 at 6:58 AM Robert Dodier <robert.dodier@gmail.com> wrote:
For the record, I can reproduce the behavior noted in the comments -- (asdf:load-system "hello") succeeds if (:use :alexandria) is omitted, and fails with "Variable MAIN is unbound" otherwise. I am working with SBCL.
It appears that the .lisp was successfully compiled, and the error occurs when trying to load the resulting .fasl.
After some tinkering, I think the problem is that the symbols DEFUN and WRITE-LINE aren't being resolved to symbols in the symbol package COMMON-LISP. I can get the example to work, with (:use :alexandria), by either writing cl:defun and cl:write-line in the code, or saying (:use :common-lisp) in the package definition.
I don't know offhand why the symbols aren't resolved in the presence of (:use :alexandria), no doubt there's a simple explanation.
Hope this helps,
Robert
On Wed, Jan 8, 2025 at 3:58 PM Robert Goldman <rpgoldman@sift.info> wrote:
Will you please post a backtrace from SBCL for this. I'm not at all sure I understand what you mean by "this line fails."
What did you do to trigger the error?
(asdf:load-system "hello")
?
On 8 Jan 2025, at 17:37, Russell L. Carter wrote:
Greetings,
I am a common-lisp noob. I am not a programmer noob, nor a build system noob.
I have carefully studied fare's asdf manual, pages 25-26 in the pdf and backwards through the reverse dependencies of the terms used, about the package-inferred-system. I have a problem that I've whittled down to a very small snippet.
I'm using SBCL 2.4.10.117-507e7ae05 and its native ASDF, but also tested against ASDF repo head (ln -s into ~/common-lisp, verified in the repl).
My question is why this system, located in file "./hello.asd", containing:
________________________________
(asdf:defsystem "hello" :class :package-inferred-system :depends-on ("hello/src/main"))
________________________________
paired with the system/package file "./src/main.lisp", containing:
________________________________
(uiop:define-package :hello/src/main ;; (:use :alexandria) ;; XXXRLC This line fails: "The variable MAIN ;; is unbound". I have no idea why. Backtrace provides no clues ;; (to me). Load the library in the repl matters not. Elide that ;; line and (asdf:load-system "hello") => T and then CL-USER> ;; (hello/src/main:main) => urg \n "urg" as expected. (:export #:main))
(in-package :hello/src/main) (defun main () (write-line "urg"))
________________________________
fails as described in the comment. Sure I would like the answer but the more interesting question is how could I debug this failure?
I slogged through the late '90s debugging complex C++ template programming errors. Pages and pages of output. I don't mind doing it again. But I don't know where to start with this ASDF build system.
Thank you for any suggestions, obviously the answer must be trivial.
All the best, Russell L. Carter
Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC)
319 N. First Ave., Suite 400 Minneapolis, MN 55401
Google Voice: (612) 326-3934 Cell: (612) 384-3454 Email: rpgoldman@SIFT.net
Thanks everyone for the help, but as the noob here perhaps it is of interest to the experts to see how I saw the situation, and what might help. When I write a form like: (defun main () (write-line "urg")) and the loader error diagnostic is "The variable MAIN is unbound" without any evidence in the backtrace of what is going on, my intuition from 40 years of programming in 23+ languages does not leap to ah, missing "use :cl". If here the error message had complained about either "defun" or "write-line", I would have gone huh, seem to be missing some fundamental stuff, try adding ":use :cl". If it was C or C++ say, the analogy might be: void myfunc() { printf("urg\n"); } and the linker not complaining about printf, but rather myfunc not being defined, when I somehow neglected to link against libc. That's a quite a misdirection... and it did cause me to spend (cough) some time before I broke down and disturbed this list. Finally I'll note that the only examples I've seen, and I actually did suck down the repo for lisp-interface-library, *do not show :use :cl*. For instance have a look at the code snippets from the ASDF.pdf manual on page 26. There are two there, and neither has a use :cl or :common-lisp or whatever. To fix this is trivial. Add in a :use :cl in those code snippets, and perhaps add "be sure to add :use :cl if you :use any other systems" in the docs for uiop:define-package. Finally I am extremely heartened that I didn't get dumped on here, I appreciate it a lot and I am extremely excited to get down to work building stuff in CL. All the best, Russell ps: I have waded through many of the colossal build systems out in the wild, and I know what I want when I'm setting up a project. ASDF looks just *fine* compared to cmake, for instance. That's why I'm so deep in the weeds so soon. On 1/9/25 4:38 AM, Faré wrote:
My memories are dim, but I believe it's a case of absence of :use argument being the same as (:use :common-lisp) but if you have an explicit :use argument, you need to explicitly include :common-lisp in the list for it to be included.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org “The only saving grace of government is that they’re incompetent, because if they could do what they really want, it would be horrible for all of us”
On Thu, Jan 9, 2025 at 6:58 AM Robert Dodier <robert.dodier@gmail.com> wrote:
For the record, I can reproduce the behavior noted in the comments -- (asdf:load-system "hello") succeeds if (:use :alexandria) is omitted, and fails with "Variable MAIN is unbound" otherwise. I am working with SBCL.
It appears that the .lisp was successfully compiled, and the error occurs when trying to load the resulting .fasl.
After some tinkering, I think the problem is that the symbols DEFUN and WRITE-LINE aren't being resolved to symbols in the symbol package COMMON-LISP. I can get the example to work, with (:use :alexandria), by either writing cl:defun and cl:write-line in the code, or saying (:use :common-lisp) in the package definition.
I don't know offhand why the symbols aren't resolved in the presence of (:use :alexandria), no doubt there's a simple explanation.
Hope this helps,
Robert
On Wed, Jan 8, 2025 at 3:58 PM Robert Goldman <rpgoldman@sift.info> wrote:
Will you please post a backtrace from SBCL for this. I'm not at all sure I understand what you mean by "this line fails."
What did you do to trigger the error?
(asdf:load-system "hello")
?
On 8 Jan 2025, at 17:37, Russell L. Carter wrote:
Greetings,
I am a common-lisp noob. I am not a programmer noob, nor a build system noob.
I have carefully studied fare's asdf manual, pages 25-26 in the pdf and backwards through the reverse dependencies of the terms used, about the package-inferred-system. I have a problem that I've whittled down to a very small snippet.
I'm using SBCL 2.4.10.117-507e7ae05 and its native ASDF, but also tested against ASDF repo head (ln -s into ~/common-lisp, verified in the repl).
My question is why this system, located in file "./hello.asd", containing:
________________________________
(asdf:defsystem "hello" :class :package-inferred-system :depends-on ("hello/src/main"))
________________________________
paired with the system/package file "./src/main.lisp", containing:
________________________________
(uiop:define-package :hello/src/main ;; (:use :alexandria) ;; XXXRLC This line fails: "The variable MAIN ;; is unbound". I have no idea why. Backtrace provides no clues ;; (to me). Load the library in the repl matters not. Elide that ;; line and (asdf:load-system "hello") => T and then CL-USER> ;; (hello/src/main:main) => urg \n "urg" as expected. (:export #:main))
(in-package :hello/src/main) (defun main () (write-line "urg"))
________________________________
fails as described in the comment. Sure I would like the answer but the more interesting question is how could I debug this failure?
I slogged through the late '90s debugging complex C++ template programming errors. Pages and pages of output. I don't mind doing it again. But I don't know where to start with this ASDF build system.
Thank you for any suggestions, obviously the answer must be trivial.
All the best, Russell L. Carter
Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC)
319 N. First Ave., Suite 400 Minneapolis, MN 55401
Google Voice: (612) 326-3934 Cell: (612) 384-3454 Email: rpgoldman@SIFT.net
Russell, I share your frustration; Common Lisp has a lot of idiosyncrasies and also a lot of really interesting, useful ideas, so it's both a wonderful and terrible environment for writing code, and, given its history, that will continue to be the case indefinitely. My advice is just take the idiosyncrasies in stride, and work with the hand you (well, all of us) have been dealt. I know this isn't a satisfying conclusion. Specifically about the :uses bit in the package definition, from combing the CLHS I see that an explicit :uses declaration supersedes the default, so, assuming that UIOP:DEFINE-PACKAGE doesn't change the interpretation of :uses (although that wouldn't be entirely out of the question), that seems to explain the observed behavior. (I also saw in CLHS that the :uses default is explicitly implementation-dependent, so, while :uses :common-lisp is nice, one cannot actually rely on it ... Oh well!) FWIW Robert Dodier
Thanks for the kind words, Robert. I completely agree! I was a heavy C++ *template* programmer back in the '90s, you want a hostile developer environment haha I think that takes the cake. But we were chasing performance. I learned c++ at NASA Ames NAS in the early '90s using g++. Rough. NAS then was already a paid-for GNU open source shop. I quit C++ last year because of FAANG assholes manipulations in the standard and some of the *shoulda* cool things like senders/stdexec. And I was a heavy cmake user for about 15 years, before "modern" cmake idioms. Ew gross. Common-Lisp is a breath of fresh air compared to that, a dream. If my problem here had been in any of the languages I'm already expert in I would have just read the source code, but I'm a little intimidated by experts wielding CL macros right now. I *will* get good at them though, might work myself through Let over Lambda, though I get the admonitions not to overdo it. This :use issue was just a little corner case issue, mostly documentation parsed by a noob, no big deal at all, and definitely not off putting. I find the fact that C-L has been standardized for decades and is still absolutely relevant just awesome. Thanks for all the help. Cheers, Russell On 1/9/25 2:44 PM, Robert Dodier wrote:
Russell, I share your frustration; Common Lisp has a lot of idiosyncrasies and also a lot of really interesting, useful ideas, so it's both a wonderful and terrible environment for writing code, and, given its history, that will continue to be the case indefinitely.
My advice is just take the idiosyncrasies in stride, and work with the hand you (well, all of us) have been dealt. I know this isn't a satisfying conclusion.
Specifically about the :uses bit in the package definition, from combing the CLHS I see that an explicit :uses declaration supersedes the default, so, assuming that UIOP:DEFINE-PACKAGE doesn't change the interpretation of :uses (although that wouldn't be entirely out of the question), that seems to explain the observed behavior.
(I also saw in CLHS that the :uses default is explicitly implementation-dependent, so, while :uses :common-lisp is nice, one cannot actually rely on it ... Oh well!)
FWIW
Robert Dodier
On Thu, Jan 9, 2025, 10:16 Russell L. Carter <rcarter@pinyon.org> wrote:
Finally I'll note that the only examples I've seen, and I actually did suck down the repo for lisp-interface-library, *do not show :use :cl*. For instance have a look at the code snippets from the ASDF.pdf manual on page 26. There are two there, and neither has a use :cl or :common-lisp or whatever.
To fix this is trivial. Add in a :use :cl in those code snippets, and perhaps add "be sure to add :use :cl if you :use any other systems" in the docs for uiop:define-package.
Are you frustrated enough to locate and fix all the misleading documentation? I admit I'm fully responsible for getting it wrong, but I have ceased being active in Common Lisp or as an ASDF developer long ago. (These days: Gerbil Scheme, and... some Haskell recently.) The current maintainers and future documentation readers will thank you. git grep -i define-package should help you. Regards, -#f
I will do this tomorrow. Russell On 1/9/25 4:56 PM, Faré wrote:
On Thu, Jan 9, 2025, 10:16 Russell L. Carter <rcarter@pinyon.org <mailto:rcarter@pinyon.org>> wrote:
Finally I'll note that the only examples I've seen, and I actually did suck down the repo for lisp-interface-library, *do not show :use :cl*. For instance have a look at the code snippets from the ASDF.pdf manual on page 26. There are two there, and neither has a use :cl or :common-lisp or whatever.
To fix this is trivial. Add in a :use :cl in those code snippets, and perhaps add "be sure to add :use :cl if you :use any other systems" in the docs for uiop:define-package.
Are you frustrated enough to locate and fix all the misleading documentation? I admit I'm fully responsible for getting it wrong, but I have ceased being active in Common Lisp or as an ASDF developer long ago. (These days: Gerbil Scheme, and... some Haskell recently.) The current maintainers and future documentation readers will thank you.
git grep -i define-package should help you.
Regards, -#f
Thank you! A patch will be very welcome. On 9 Jan 2025, at 16:01, Russell L. Carter wrote:
I will do this tomorrow.
Russell
On 1/9/25 4:56 PM, Faré wrote:
On Thu, Jan 9, 2025, 10:16 Russell L. Carter <rcarter@pinyon.org <mailto:rcarter@pinyon.org>> wrote:
Finally I'll note that the only examples I've seen, and I actually did suck down the repo for lisp-interface-library, *do not show :use :cl*. For instance have a look at the code snippets from the ASDF.pdf manual on page 26. There are two there, and neither has a use :cl or :common-lisp or whatever.
To fix this is trivial. Add in a :use :cl in those code snippets, and perhaps add "be sure to add :use :cl if you :use any other systems" in the docs for uiop:define-package.
Are you frustrated enough to locate and fix all the misleading documentation? I admit I'm fully responsible for getting it wrong, but I have ceased being active in Common Lisp or as an ASDF developer long ago. (These days: Gerbil Scheme, and... some Haskell recently.) The current maintainers and future documentation readers will thank you.
git grep -i define-package should help you.
Regards, -#f
Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC) 319 N. First Ave., Suite 400 Minneapolis, MN 55401 Google Voice: (612) 326-3934 Cell: (612) 384-3454 Email: rpgoldman@SIFT.net
Hi Robert, I decided against modifying the UIOP doc because although the existing wording is quite concise it is also correct, AFAICT. Any edits I could conceive would alter the style and as a maker of many words myself I am loathe to do that. I'm also open to any style nitpicks in this tiny patch. I'm not interested in being different from existing code conventions, etc. --- doc/asdf.texinfo | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/asdf.texinfo b/doc/asdf.texinfo index cc3aa287..5da42b32 100644 --- a/doc/asdf.texinfo +++ b/doc/asdf.texinfo @@ -2131,7 +2131,7 @@ ASDF will compute dependencies from the @example (uiop:define-package :my-lib/interface/order - (:use :closer-common-lisp + (:use :cl :closer-common-lisp :my-lib/interface/definition :my-lib/interface/base) (:mix :fare-utils :uiop :alexandria) @@ -2152,7 +2152,7 @@ context. For example: @example (uiop:define-package :my-lib/interface/all (:nicknames :my-lib-interface) - (:use :closer-common-lisp) + (:use :cl :closer-common-lisp) (:mix :fare-utils :uiop :alexandria) (:use-reexport :my-lib/interface/definition -- 2.45.2 On 1/9/25 5:38 PM, Robert Goldman wrote:
Thank you! A patch will be very welcome.
On 9 Jan 2025, at 16:01, Russell L. Carter wrote:
I will do this tomorrow.
Russell
On 1/9/25 4:56 PM, Faré wrote:
On Thu, Jan 9, 2025, 10:16 Russell L. Carter <rcarter@pinyon.org <mailto:rcarter@pinyon.org> mailto:rcarter@pinyon.org <mailto:rcarter@pinyon.org>> wrote:
|Finally I'll note that the only examples I've seen, and I actually did suck down the repo for lisp-interface-library, *do not show :use :cl*. For instance have a look at the code snippets from the ASDF.pdf manual on page 26. There are two there, and neither has a use :cl or :common-lisp or whatever. To fix this is trivial. Add in a :use :cl in those code snippets, and perhaps add "be sure to add :use :cl if you :use any other systems" in the docs for uiop:define-package. |
Are you frustrated enough to locate and fix all the misleading documentation? I admit I'm fully responsible for getting it wrong, but I have ceased being active in Common Lisp or as an ASDF developer long ago. (These days: Gerbil Scheme, and... some Haskell recently.) The current maintainers and future documentation readers will thank you.
git grep -i define-package should help you.
Regards, -#f
Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC)
319 N. First Ave., Suite 400 Minneapolis, MN 55401
Google Voice: (612) 326-3934 Cell: (612) 384-3454 Email: rpgoldman@SIFT.net <mailto:rpgoldman@SIFT.net>
There's a problem with this patch that highlights a problem with the example. The problem is that the package `:closer-common-lisp` is a new package that exports all the external symbols in `:closer-mop` (a portability layer for the meta object protocol) *and* all the external symbols of `:common-lisp`. So adding `:cl` to the `:use` list in this example does nothing. I *think* a better fix for this example would be to replace `(:use :closer-common-lisp)` with `(:use :cl :closer-mop)` everywhere. On 10 Jan 2025, at 11:49, Russell L. Carter wrote:
Hi Robert, I decided against modifying the UIOP doc because although the existing wording is quite concise it is also correct, AFAICT. Any edits I could conceive would alter the style and as a maker of many words myself I am loathe to do that.
I'm also open to any style nitpicks in this tiny patch. I'm not interested in being different from existing code conventions, etc.
--- doc/asdf.texinfo | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/asdf.texinfo b/doc/asdf.texinfo index cc3aa287..5da42b32 100644 --- a/doc/asdf.texinfo +++ b/doc/asdf.texinfo @@ -2131,7 +2131,7 @@ ASDF will compute dependencies from the
@example (uiop:define-package :my-lib/interface/order - (:use :closer-common-lisp + (:use :cl :closer-common-lisp :my-lib/interface/definition :my-lib/interface/base) (:mix :fare-utils :uiop :alexandria) @@ -2152,7 +2152,7 @@ context. For example: @example (uiop:define-package :my-lib/interface/all (:nicknames :my-lib-interface) - (:use :closer-common-lisp) + (:use :cl :closer-common-lisp) (:mix :fare-utils :uiop :alexandria) (:use-reexport :my-lib/interface/definition -- 2.45.2
On 1/9/25 5:38 PM, Robert Goldman wrote:
Thank you! A patch will be very welcome.
On 9 Jan 2025, at 16:01, Russell L. Carter wrote:
I will do this tomorrow.
Russell
On 1/9/25 4:56 PM, Faré wrote:
On Thu, Jan 9, 2025, 10:16 Russell L. Carter <rcarter@pinyon.org <mailto:rcarter@pinyon.org> mailto:rcarter@pinyon.org <mailto:rcarter@pinyon.org>> wrote:
|Finally I'll note that the only examples I've seen, and I actually did suck down the repo for lisp-interface-library, *do not show :use :cl*. For instance have a look at the code snippets from the ASDF.pdf manual on page 26. There are two there, and neither has a use :cl or :common-lisp or whatever. To fix this is trivial. Add in a :use :cl in those code snippets, and perhaps add "be sure to add :use :cl if you :use any other systems" in the docs for uiop:define-package. |
Are you frustrated enough to locate and fix all the misleading documentation? I admit I'm fully responsible for getting it wrong, but I have ceased being active in Common Lisp or as an ASDF developer long ago. (These days: Gerbil Scheme, and... some Haskell recently.) The current maintainers and future documentation readers will thank you.
git grep -i define-package should help you.
Regards, -#f
It would seem so if I'm reading the macrolet define-closer-common-lisp-package correctly: https://github.com/pcostanza/closer-mop/blob/master/closer-mop-packages.lisp Since the example is supposed to be expository rather than a a professional code snippet I see no problem with your suggestion. An expert would factor that in, I would think, and people like me wouldn't know the difference. Russell On 1/10/25 1:18 PM, Robert Goldman wrote:
There's a problem with this patch that highlights a problem with the example.
The problem is that the package |:closer-common-lisp| is a new package that exports all the external symbols in |:closer-mop| (a portability layer for the meta object protocol) /and/ all the external symbols of |:common-lisp|. So adding |:cl| to the |:use| list in this example does nothing.
I /think/ a better fix for this example would be to replace | (:use :closer-common-lisp)| with |(:use :cl :closer-mop)| everywhere.
On 10 Jan 2025, at 11:49, Russell L. Carter wrote:
Hi Robert, I decided against modifying the UIOP doc because although the existing wording is quite concise it is also correct, AFAICT. Any edits I could conceive would alter the style and as a maker of many words myself I am loathe to do that.
I'm also open to any style nitpicks in this tiny patch. I'm not interested in being different from existing code conventions, etc.
------------------------------------------------------------------------
doc/asdf.texinfo | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/asdf.texinfo b/doc/asdf.texinfo index cc3aa287..5da42b32 100644 --- a/doc/asdf.texinfo +++ b/doc/asdf.texinfo @@ -2131,7 +2131,7 @@ ASDF will compute dependencies from the
@example (uiop:define-package :my-lib/interface/order
* (:use :closer-common-lisp
* (:use :cl :closer-common-lisp :my-lib/interface/definition :my-lib/interface/base) (:mix :fare-utils :uiop :alexandria)
@@ -2152,7 +2152,7 @@ context. For example: @example (uiop:define-package :my-lib/interface/all (:nicknames :my-lib-interface)
* (:use :closer-common-lisp)
* (:use :cl :closer-common-lisp) (:mix :fare-utils :uiop :alexandria) (:use-reexport :my-lib/interface/definition
-- 2.45.2
On 1/9/25 5:38 PM, Robert Goldman wrote:
Thank you! A patch will be very welcome.
On 9 Jan 2025, at 16:01, Russell L. Carter wrote:
|I will do this tomorrow. Russell On 1/9/25 4:56 PM, Faré wrote: On Thu, Jan 9, 2025, 10:16 Russell L. Carter <rcarter@pinyon.org <mailto:rcarter@pinyon.org> mailto:rcarter@pinyon.org <mailto:rcarter@pinyon.org>> wrote: |Finally I'll note that the only examples I've seen, and I actually did suck down the repo for lisp-interface-library, *do not show :use :cl*. For instance have a look at the code snippets from the ASDF.pdf manual on page 26. There are two there, and neither has a use :cl or :common-lisp or whatever. To fix this is trivial. Add in a :use :cl in those code snippets, and perhaps add "be sure to add :use :cl if you :use any other systems" in the docs for uiop:define-package. | Are you frustrated enough to locate and fix all the misleading documentation? I admit I'm fully responsible for getting it wrong, but I have ceased being active in Common Lisp or as an ASDF developer long ago. (These days: Gerbil Scheme, and... some Haskell recently.) The current maintainers and future documentation readers will thank you. git grep -i define-package should help you. Regards, -#f |
--- doc/asdf.texinfo | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/asdf.texinfo b/doc/asdf.texinfo index cc3aa287..f0e6dd64 100644 --- a/doc/asdf.texinfo +++ b/doc/asdf.texinfo @@ -2131,7 +2131,7 @@ ASDF will compute dependencies from the @example (uiop:define-package :my-lib/interface/order - (:use :closer-common-lisp + (:use :cl :closer-mop) :my-lib/interface/definition :my-lib/interface/base) (:mix :fare-utils :uiop :alexandria) @@ -2152,7 +2152,7 @@ context. For example: @example (uiop:define-package :my-lib/interface/all (:nicknames :my-lib-interface) - (:use :closer-common-lisp) + (:use :cl :closer-mop) (:mix :fare-utils :uiop :alexandria) (:use-reexport :my-lib/interface/definition -- 2.45.2 On 1/10/25 2:21 PM, Russell L. Carter wrote:
It would seem so if I'm reading the macrolet define-closer-common-lisp-package correctly:
https://github.com/pcostanza/closer-mop/blob/master/closer-mop- packages.lisp
Since the example is supposed to be expository rather than a a professional code snippet I see no problem with your suggestion. An expert would factor that in, I would think, and people like me wouldn't know the difference.
Russell
On 1/10/25 1:18 PM, Robert Goldman wrote:
There's a problem with this patch that highlights a problem with the example.
The problem is that the package |:closer-common-lisp| is a new package that exports all the external symbols in |:closer-mop| (a portability layer for the meta object protocol) /and/ all the external symbols of |:common-lisp|. So adding |:cl| to the |:use| list in this example does nothing.
I /think/ a better fix for this example would be to replace | (:use :closer-common-lisp)| with |(:use :cl :closer-mop)| everywhere.
On 10 Jan 2025, at 11:49, Russell L. Carter wrote:
Hi Robert, I decided against modifying the UIOP doc because although the existing wording is quite concise it is also correct, AFAICT. Any edits I could conceive would alter the style and as a maker of many words myself I am loathe to do that.
I'm also open to any style nitpicks in this tiny patch. I'm not interested in being different from existing code conventions, etc.
------------------------------------------------------------------------
doc/asdf.texinfo | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/asdf.texinfo b/doc/asdf.texinfo index cc3aa287..5da42b32 100644 --- a/doc/asdf.texinfo +++ b/doc/asdf.texinfo @@ -2131,7 +2131,7 @@ ASDF will compute dependencies from the
@example (uiop:define-package :my-lib/interface/order
* (:use :closer-common-lisp
* (:use :cl :closer-common-lisp :my-lib/interface/definition :my-lib/interface/base) (:mix :fare-utils :uiop :alexandria)
@@ -2152,7 +2152,7 @@ context. For example: @example (uiop:define-package :my-lib/interface/all (:nicknames :my-lib-interface)
* (:use :closer-common-lisp)
* (:use :cl :closer-common-lisp) (:mix :fare-utils :uiop :alexandria) (:use-reexport :my-lib/interface/definition
-- 2.45.2
On 1/9/25 5:38 PM, Robert Goldman wrote:
Thank you! A patch will be very welcome.
On 9 Jan 2025, at 16:01, Russell L. Carter wrote:
|I will do this tomorrow. Russell On 1/9/25 4:56 PM, Faré wrote: On Thu, Jan 9, 2025, 10:16 Russell L. Carter <rcarter@pinyon.org <mailto:rcarter@pinyon.org> mailto:rcarter@pinyon.org <mailto:rcarter@pinyon.org>> wrote: |Finally I'll note that the only examples I've seen, and I actually did suck down the repo for lisp-interface-library, *do not show :use :cl*. For instance have a look at the code snippets from the ASDF.pdf manual on page 26. There are two there, and neither has a use :cl or :common-lisp or whatever. To fix this is trivial. Add in a :use :cl in those code snippets, and perhaps add "be sure to add :use :cl if you :use any other systems" in the docs for uiop:define-package. | Are you frustrated enough to locate and fix all the misleading documentation? I admit I'm fully responsible for getting it wrong, but I have ceased being active in Common Lisp or as an ASDF developer long ago. (These days: Gerbil Scheme, and... some Haskell recently.) The current maintainers and future documentation readers will thank you. git grep -i define-package should help you. Regards, -#f |
Thanks for the patch. See https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/240 On 10 Jan 2025, at 13:56, Russell L. Carter wrote:
--- doc/asdf.texinfo | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/asdf.texinfo b/doc/asdf.texinfo index cc3aa287..f0e6dd64 100644 --- a/doc/asdf.texinfo +++ b/doc/asdf.texinfo @@ -2131,7 +2131,7 @@ ASDF will compute dependencies from the
@example (uiop:define-package :my-lib/interface/order - (:use :closer-common-lisp + (:use :cl :closer-mop) :my-lib/interface/definition :my-lib/interface/base) (:mix :fare-utils :uiop :alexandria) @@ -2152,7 +2152,7 @@ context. For example: @example (uiop:define-package :my-lib/interface/all (:nicknames :my-lib-interface) - (:use :closer-common-lisp) + (:use :cl :closer-mop) (:mix :fare-utils :uiop :alexandria) (:use-reexport :my-lib/interface/definition -- 2.45.2
On 1/10/25 2:21 PM, Russell L. Carter wrote:
It would seem so if I'm reading the macrolet define-closer-common-lisp-package correctly:
https://github.com/pcostanza/closer-mop/blob/master/closer-mop- packages.lisp
Since the example is supposed to be expository rather than a a professional code snippet I see no problem with your suggestion. An expert would factor that in, I would think, and people like me wouldn't know the difference.
Russell
On 1/10/25 1:18 PM, Robert Goldman wrote:
There's a problem with this patch that highlights a problem with the example.
The problem is that the package |:closer-common-lisp| is a new package that exports all the external symbols in |:closer-mop| (a portability layer for the meta object protocol) /and/ all the external symbols of |:common-lisp|. So adding |:cl| to the |:use| list in this example does nothing.
I /think/ a better fix for this example would be to replace | (:use :closer-common-lisp)| with |(:use :cl :closer-mop)| everywhere.
On 10 Jan 2025, at 11:49, Russell L. Carter wrote:
Hi Robert, I decided against modifying the UIOP doc because although the existing wording is quite concise it is also correct, AFAICT. Any edits I could conceive would alter the style and as a maker of many words myself I am loathe to do that.
I'm also open to any style nitpicks in this tiny patch. I'm not interested in being different from existing code conventions, etc.
------------------------------------------------------------------------
doc/asdf.texinfo | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/asdf.texinfo b/doc/asdf.texinfo index cc3aa287..5da42b32 100644 --- a/doc/asdf.texinfo +++ b/doc/asdf.texinfo @@ -2131,7 +2131,7 @@ ASDF will compute dependencies from the
@example (uiop:define-package :my-lib/interface/order
* (:use :closer-common-lisp
* (:use :cl :closer-common-lisp :my-lib/interface/definition :my-lib/interface/base) (:mix :fare-utils :uiop :alexandria)
@@ -2152,7 +2152,7 @@ context. For example: @example (uiop:define-package :my-lib/interface/all (:nicknames :my-lib-interface)
* (:use :closer-common-lisp)
* (:use :cl :closer-common-lisp) (:mix :fare-utils :uiop :alexandria) (:use-reexport :my-lib/interface/definition
-- 2.45.2
On 1/9/25 5:38 PM, Robert Goldman wrote:
Thank you! A patch will be very welcome.
On 9 Jan 2025, at 16:01, Russell L. Carter wrote:
|I will do this tomorrow. Russell On 1/9/25 4:56 PM, Faré wrote: On Thu, Jan 9, 2025, 10:16 Russell L. Carter <rcarter@pinyon.org <mailto:rcarter@pinyon.org> mailto:rcarter@pinyon.org <mailto:rcarter@pinyon.org>> wrote: |Finally I'll note that the only examples I've seen, and I actually did suck down the repo for lisp-interface-library, *do not show :use :cl*. For instance have a look at the code snippets from the ASDF.pdf manual on page 26. There are two there, and neither has a use :cl or :common-lisp or whatever. To fix this is trivial. Add in a :use :cl in those code snippets, and perhaps add "be sure to add :use :cl if you :use any other systems" in the docs for uiop:define-package. | Are you frustrated enough to locate and fix all the misleading documentation? I admit I'm fully responsible for getting it wrong, but I have ceased being active in Common Lisp or as an ASDF developer long ago. (These days: Gerbil Scheme, and... some Haskell recently.) The current maintainers and future documentation readers will thank you. git grep -i define-package should help you. Regards, -#f |
Hello! IIUC, the problem here is not with ASDF but with the package definition (I could be wrong about the reason because I can't really test it in the exact same setup at the moment). Specifically, when defining a package, if there is no :use clause, an implementation-dependent default is used, which almost always includes the "CL" ("COMMON-LISP") package. However, when you are specifying (:use :alexandria), the default is no longer used, and thus the "CL" package is not being used. Thus DEFUN no longer refers to the macro CL:DEFUN, but to the symbol HELLO/SRC/MAIN::DEFUN, which has no function or macro associated. And so the function definition is instead treated as a function call, and while evaluating the first "argument", it signals an error that the variable MAIN is unbound (doesn't exist). Dunno what exactly can go right or wrong when debugging an issue like that, but IIRC errors that happen during the compiling/loading of a system seem to be harder to read/notice than usual because by default they are intercepted and reported by ASDF, which afterwards signals a more generic error. You could probably check the ASDF:*COMPILE-FILE-FAILURE-BEHAVIOUR* variable for controlling that (shortly describes in the manual, section 10.2). Best regards, Alexander Fedorov. On Thu, Jan 9, 2025, 00:37 Russell L. Carter <rcarter@pinyon.org> wrote:
Greetings,
I am a common-lisp noob. I am not a programmer noob, nor a build system noob.
I have carefully studied fare's asdf manual, pages 25-26 in the pdf and backwards through the reverse dependencies of the terms used, about the package-inferred-system. I have a problem that I've whittled down to a very small snippet.
I'm using SBCL 2.4.10.117-507e7ae05 and its native ASDF, but also tested against ASDF repo head (ln -s into ~/common-lisp, verified in the repl).
My question is why this system, located in file "./hello.asd", containing:
***************************************************************** (asdf:defsystem "hello" :class :package-inferred-system :depends-on ("hello/src/main")) *****************************************************************
paired with the system/package file "./src/main.lisp", containing:
****************************************************************** (uiop:define-package :hello/src/main ;; (:use :alexandria) ;; XXXRLC This line fails: "The variable MAIN ;; is unbound". I have no idea why. Backtrace provides no clues ;; (to me). Load the library in the repl matters not. Elide that ;; line and (asdf:load-system "hello") => T and then CL-USER> ;; (hello/src/main:main) => urg \n "urg" as expected. (:export #:main))
(in-package :hello/src/main) (defun main () (write-line "urg")) *******************************************************************
fails as described in the comment. Sure I would like the answer but the more interesting question is how could I debug this failure?
I slogged through the late '90s debugging complex C++ template programming errors. Pages and pages of output. I don't mind doing it again. But I don't know where to start with this ASDF build system.
Thank you for any suggestions, obviously the answer must be trivial.
All the best, Russell L. Carter
Bingo! Thank you very much. I regret that I hadn't thought to try that, it's obvious in hindsight. I was led astray I think by fare's very concise wording in the UIOP manual 2 UIOP/Package uiop.pdf page2: [...] cl:defpackage. use -- as per cl:defpackage, but if neither use, use-reexport, mix, nor mix-reexport is supplied, then it is equivalent to specifying (:use :common- lisp). This is unlike cl:defpackage for which the behavior of a form without use is implementation-dependent. recycle -- Recycle the package’s exported symbols [...] Anyway I thank you all for your patience, and boy do I look forward to making some progress in shoving C++ onto the ash-heap of (my) history and moving forward into sanity. All the best, Russell On 1/8/25 7:05 PM, Alexander Fedorov wrote:
Hello!
IIUC, the problem here is not with ASDF but with the package definition (I could be wrong about the reason because I can't really test it in the exact same setup at the moment). Specifically, when defining a package, if there is no :use clause, an implementation-dependent default is used, which almost always includes the "CL" ("COMMON-LISP") package. However, when you are specifying (:use :alexandria), the default is no longer used, and thus the "CL" package is not being used. Thus DEFUN no longer refers to the macro CL:DEFUN, but to the symbol HELLO/SRC/MAIN::DEFUN, which has no function or macro associated. And so the function definition is instead treated as a function call, and while evaluating the first "argument", it signals an error that the variable MAIN is unbound (doesn't exist).
Dunno what exactly can go right or wrong when debugging an issue like that, but IIRC errors that happen during the compiling/loading of a system seem to be harder to read/notice than usual because by default they are intercepted and reported by ASDF, which afterwards signals a more generic error. You could probably check the ASDF:*COMPILE-FILE- FAILURE-BEHAVIOUR* variable for controlling that (shortly describes in the manual, section 10.2).
Best regards, Alexander Fedorov.
On Thu, Jan 9, 2025, 00:37 Russell L. Carter <rcarter@pinyon.org <mailto:rcarter@pinyon.org>> wrote:
Greetings,
I am a common-lisp noob. I am not a programmer noob, nor a build system noob.
I have carefully studied fare's asdf manual, pages 25-26 in the pdf and backwards through the reverse dependencies of the terms used, about the package-inferred-system. I have a problem that I've whittled down to a very small snippet.
I'm using SBCL 2.4.10.117-507e7ae05 and its native ASDF, but also tested against ASDF repo head (ln -s into ~/common-lisp, verified in the repl).
My question is why this system, located in file "./hello.asd", containing:
***************************************************************** (asdf:defsystem "hello" :class :package-inferred-system :depends-on ("hello/src/main")) *****************************************************************
paired with the system/package file "./src/main.lisp", containing:
****************************************************************** (uiop:define-package :hello/src/main ;; (:use :alexandria) ;; XXXRLC This line fails: "The variable MAIN ;; is unbound". I have no idea why. Backtrace provides no clues ;; (to me). Load the library in the repl matters not. Elide that ;; line and (asdf:load-system "hello") => T and then CL-USER> ;; (hello/src/main:main) => urg \n "urg" as expected. (:export #:main))
(in-package :hello/src/main) (defun main () (write-line "urg")) *******************************************************************
fails as described in the comment. Sure I would like the answer but the more interesting question is how could I debug this failure?
I slogged through the late '90s debugging complex C++ template programming errors. Pages and pages of output. I don't mind doing it again. But I don't know where to start with this ASDF build system.
Thank you for any suggestions, obviously the answer must be trivial.
All the best, Russell L. Carter
participants (5)
-
Alexander Fedorov -
Faré -
Robert Dodier -
Robert Goldman -
Russell L. Carter