New at this, sure could use a pointer. I'm not able to get the code to build consistently. It works only after a failure. So I have to do it twice to get it to go. Sure would like to know what is wrong here.
These are the directories:
/home/LE/sbcl/LE.asd ;holds the definition, as shown below /home/LE/sbcl/src ;holds the lisp source files for my project
The system is Debian, udpated today. quicklisp is installed.
These are the commands I type:
(require :asdf) (pushnew (truename ".") asdf:*central-registry* :test #'equal) (asdf:load-system :LE) (require :LE) (use-package 'LE)
in a fresh environment this fails, and dumps me in the debugger, asdf:load-system tells me:
"Component :LE not found:
Then I exit the debugger, and run it a second time and it works. Not sure, may need quotes the first time, a colon the second, i.e. it is quirky.
I have tried a lot of variations of the above, pretty much every example I've been able to find, some have "LE" instead of :LE everywhere.
Here is the value of asdf:*central-registry* after the push:
* asdf:*central-registry*
(#P"/home/LE/sbcl/" #P"/home/mordecai/quicklisp/quicklisp/")
Here is the asdf file that is located in /home/LE/sbcl:
(in-package :asdf-user)
(defsystem #:LE :name "LE" :version "0.1" :author "Thomas W. Lynch thomas.lynch@reasoningtechnology.com" :description "Lynch's extensions" :depends-on ("local-time") ;; :serial t :components((:module "src" :components ( (:file "package") (:file "fundamental" :depends-on ("package")) (:file "test" :depends-on ("fundamental")) (:file "string" :depends-on ("test")) (:file "functions" :depends-on ("test")) (:file "list-0" :depends-on ("functions")) ;; (:file "list-L" :depends-on ("list-0")) ))))
- asdf:*central-registry*
(#P"/home/LE/sbcl/" #P"/home/mordecai/quicklisp/quicklisp/")
i'd just put my code under ~/quicklisp/local-projects/ and forget about ASDF configuration until it's again needed for something. you can also use symlinks.
also, IIRC asdf:*central-registry* is obsoleted.
Yeah, I read that also. and tried putting the .asd file in that directory and got the same message. I also tried under quicklisp/local-projects which I gathered to be the preferred place, and it didn't see it there either. I also tried linking the project directory in those places, it still doesn't find it. .. I've noticed that sbcl updates haven't been 'held back' on Debian recently, so I'm reinstalling everything to get the most up to date versions.
On Mon, Jan 18, 2016 at 3:28 PM, Attila Lendvai attila@lendvai.name wrote:
- asdf:*central-registry*
(#P"/home/LE/sbcl/" #P"/home/mordecai/quicklisp/quicklisp/")
i'd just put my code under ~/quicklisp/local-projects/ and forget about ASDF configuration until it's again needed for something. you can also use symlinks.
also, IIRC asdf:*central-registry* is obsoleted.
-- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The first thing you have to do if you want to raise nice kids, is you have to talk to them like they are people instead of talking to them like they're property.” — Frank Zappa (1940–1993), 'The Howard Stern Show' (1987)
On 1/18/16 Jan 18 -9:28 AM, Attila Lendvai wrote:
- asdf:*central-registry*
(#P"/home/LE/sbcl/" #P"/home/mordecai/quicklisp/quicklisp/")
i'd just put my code under ~/quicklisp/local-projects/ and forget about ASDF configuration until it's again needed for something. you can also use symlinks.
also, IIRC asdf:*central-registry* is obsoleted.
I'm even the maintainer and I still use ASDF:*CENTRAL-REGISTRY*.
The new DSL and Faré's very efficient search methods provide great value if you are searching a large tree of files.
They are also opaque and difficult to debug.
If you have only a few directories in your search tree, IMO, you are better off just sticking to ASDF:*CENTRAL-REGISTRY*
If you want to understand why ASDF can't find your system, the answer is usually just a (PPRINT ASDF:*CENTRAL-REGISTRY*) away. And the inefficiency won't kill you.
I just wrote a trivial tree searcher I could make publicly available. Key advantage: it's dead simple, and you can use TRACE to see if it's doing what you want.
Also, it's easy to write code to manipulate your central registry in lisp, on the fly. Typing the DSL into the REPL isn't my cup of tea.
YMMV -- in particular if you have a very large set of libraries, as I have said above -- the DSL and caching can be a huge win. But for many of us, it will be overkill, and come with a high cost in lost ability to debug. Stumbling through the many function pointers, hash tables, etc., is hard work!
As long as I am maintainer, *CENTRAL-REGISTRY* will stay.
Cheers, r
Yes, Robert, the problem was the upper case name. Everything was upper case "LE". I have now changed it so that everything is lower case "le" and it works, and appears to consistently work (quirky behavior has gone away). This is the first LISP program that has forced me to use lower case ;-) Given this is my first application of asdf I would never have figured this out. Thank you. I hope this will be classed as a bug.
For what it is worth, IMHO, at first blush, the *CENTRAL-REGISTRY* approach seems better as all the project code remains in the project. With the other approach one strangely puts (or links) the local project build file under a remote directory unrelated to the project.
On Mon, Jan 18, 2016 at 4:11 PM, Robert Goldman rpgoldman@sift.net wrote:
On 1/18/16 Jan 18 -9:28 AM, Attila Lendvai wrote:
- asdf:*central-registry*
(#P"/home/LE/sbcl/" #P"/home/mordecai/quicklisp/quicklisp/")
i'd just put my code under ~/quicklisp/local-projects/ and forget about ASDF configuration until it's again needed for something. you can also use symlinks.
also, IIRC asdf:*central-registry* is obsoleted.
I'm even the maintainer and I still use ASDF:*CENTRAL-REGISTRY*.
The new DSL and Faré's very efficient search methods provide great value if you are searching a large tree of files.
They are also opaque and difficult to debug.
If you have only a few directories in your search tree, IMO, you are better off just sticking to ASDF:*CENTRAL-REGISTRY*
If you want to understand why ASDF can't find your system, the answer is usually just a (PPRINT ASDF:*CENTRAL-REGISTRY*) away. And the inefficiency won't kill you.
I just wrote a trivial tree searcher I could make publicly available. Key advantage: it's dead simple, and you can use TRACE to see if it's doing what you want.
Also, it's easy to write code to manipulate your central registry in lisp, on the fly. Typing the DSL into the REPL isn't my cup of tea.
YMMV -- in particular if you have a very large set of libraries, as I have said above -- the DSL and caching can be a huge win. But for many of us, it will be overkill, and come with a high cost in lost ability to debug. Stumbling through the many function pointers, hash tables, etc., is hard work!
As long as I am maintainer, *CENTRAL-REGISTRY* will stay.
Cheers, r
On 2016-01-19 02:56 CET, Thomas Lynch thomas.lynch@reasoningtechnology.com wrote:
For what it is worth, IMHO, at first blush, the *CENTRAL-REGISTRY* approach seems better as all the project code remains in the project. With the other approach one strangely puts (or links) the local project build file under a remote directory unrelated to the project.
If you plan to have more than one project, you could also consider putting them in ~/common-lisp, as that directory is automagically picked up by asdf, as described in
~/.config/common-lisp/source-registry.conf.d/
and implemented at
https://gitlab.common-lisp.net/asdf/asdf/blob/master/source-registry.lisp#L1...
For me, that's more than enough, but should you have more elaborate needs, you can check the many options of configuring the locations to find systems:
https://common-lisp.net/project/asdf/asdf.html#Configuring-ASDF-to-find-your...
HTH
Kambiz
On 1/18/16 Jan 18 -5:30 AM, Thomas Lynch wrote:
New at this, sure could use a pointer. I'm not able to get the code to build consistently. It works only after a failure. So I have to do it twice to get it to go. Sure would like to know what is wrong here.
I can't swear to it without doing more checks, but note that the canonical case for ASDF system names is *lower-case*.
That means that :LE is interpreted as "le". "LE" however, will be interepreted as "LE".
From the manual (defsystem grammar):
If a symbol is given [as system name -rpg], it will be translated into a string, and downcased in the process. The downcasing of symbols is unconventional, but was selected after some consideration. Observations suggest that the type of systems we want to support either have lowercase as customary case (Unix, Mac, windows) or silently convert lowercase to uppercase (lpns), so this makes more sense than attempting to use ':case :common' as argument to 'make-pathname', which is reported not to work on some implementations.
Short answer: just don't do this. Stick to lower-case system names.
These are the directories:
/home/LE/sbcl/LE.asd ;holds the definition, as shown below /home/LE/sbcl/src ;holds the lisp source files for my project
The system is Debian, udpated today. quicklisp is installed.
These are the commands I type:
(require :asdf) (pushnew (truename ".") asdf:*central-registry* :test #'equal) (asdf:load-system :LE) (require :LE) (use-package 'LE)
in a fresh environment this fails, and dumps me in the debugger, asdf:load-system tells me:
"Component :LE not found:
Then I exit the debugger, and run it a second time and it works. Not sure, may need quotes the first time, a colon the second, i.e. it is quirky.
I have tried a lot of variations of the above, pretty much every example I've been able to find, some have "LE" instead of :LE everywhere.
Here is the value of asdf:*central-registry* after the push:
* asdf:*central-registry* (#P"/home/LE/sbcl/" #P"/home/mordecai/quicklisp/quicklisp/")
Here is the asdf file that is located in /home/LE/sbcl:
(in-package :asdf-user) (defsystem #:LE :name "LE" :version "0.1" :author "Thomas W. Lynch <thomas.lynch@reasoningtechnology.com <mailto:thomas.lynch@reasoningtechnology.com>>" :description "Lynch's extensions" :depends-on ("local-time") ;; :serial t :components((:module "src" :components ( (:file "package") (:file "fundamental" :depends-on ("package")) (:file "test" :depends-on ("fundamental")) (:file "string" :depends-on ("test")) (:file "functions" :depends-on ("test")) (:file "list-0" :depends-on ("functions")) ;; (:file "list-L" :depends-on ("list-0")) ))))