asdf-devel January 2016

asdf-devel@common-lisp.net

10 participants
15 discussions

bug: after erring on undefined component type, system is reported to load successfully
by 73budden . 10 Jan '16

10 Jan '16

Version 3.1.5, Example system definition: (defsystem :s3 :components ((cl-user::cons "file-name-does-not-matter") )) ;; eof I try to load it, it says: "Error while trying to load definition for system s3 from pathname c:/clcon/lp/test/s3.asd: don't recognize component type CONS" Then I try to load it another time, it says: T

2 3

user-homedir-pathname on cmucl
by Raymond Toy 09 Jan '16

09 Jan '16

Not sure how this ever worked with cmucl, but user-homedir-pathname on cmucl returns #p"home:", where "home:" is a search-list. In some cases, it looks like asdf is trying to create the cache directory and end up with a path like P"home:.cache/common-lisp/cmu-21a__21a_unicode_-macosx-x86/**/*.*.~*~" but this confuses other parts of asdf and cmucl when trying to run pathname-match-p. Perhaps the best thing is to make asdf us a custom user-homedir-pathname like what is done with other lisps. An appropriate version would be (defun user-homedir-pathname () (first (ext:search-list (cl:user-homedir-pathname)))) -- Ray

2 13

I believe that load-system is described incorrectly in the manual
by 73budden . 08 Jan '16

08 Jan '16

Quote from the manual: "But for code that you are actively developing, debugging, or otherwise modifying, you should use load-system, so ASDF will pick on your modifications and transitively re-build the modified files and everything that depends on them. " What does "everything that depends on them" mean? I have sys1.asd: (asdf:defsystem :sys1 :serial t :components ((:file "sys1-file1"))) ; EOF and sys2.asd (asdf:defsystem :sys2 :serial t :depends-on (:sys1) :components ((:file "sys2-file2"))) ; EOF I do (asdf:load-system :sys2), then I touch sys1-file1.lisp, then I do (asdf:load-system :sys1) :sys2 does not get recompiled. This is what I always knew and expected to see, but, according to manual, it should have been recompiled, as :sys2 depends on :sys1, and, hence, from the modified sys1-file1.lisp. Now I don't know is this a "misbug" in asdf or a defeciency in the manual. If this is a misbug, another question arises: is there a "canonical" way to reload all systems that are currently loaded into the image and sources of which have changed since last load?

2 1

uiop parse-native-namestring portability?
by Jared C. Davis 08 Jan '16

08 Jan '16

Hi, Should I be able to expect the following to behave consistently across Lisps? (file-namestring (uiop:parse-native-namestring ".")) I find that: - CCL and SBCL produce "." - Allegro produces NIL - CMUCL signals an error in LISP::UNPARSE-UNIX-FILE If I just look at: (uiop:parse-native-namestring ".") I get: Allegro: #P"./" CCL: #P"." SBCL: #P"." CMUCL: #P(:NAME "." :TYPE :UNSPECIFIC) Cheers, Jared -- Jared C. Davis <jared(a)cs.utexas.edu> 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/

4 8

Issues with new testing scripts
by Robert Goldman 03 Jan '16

03 Jan '16

I'm having two issues with the new testing scripts: 1. The testing code is bleeding quicklisp into context: make test ./make.sh l='' L='' u='' U='' v='' s='' t='' test > Error: System "cl-scripting" not found > While executing: (:INTERNAL QUICKLISP-CLIENT::RECURSE QUICKLISP-CLIENT::COMPUTE-LOAD-STRATEGY), in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Try again > Type :? for other options. 1 > I *definitely* did not ask to be using quicklisp when testing. This error arises inside (LOAD-SYS "asdf-tools"), which is redirected to use quicklisp: (defun load-sys (system) (if (featurep :quicklisp) (let ((*standard-output* (make-broadcast-stream))) ;; be quiet (symbol-call :ql :quickload system)) (load-system system :verbose nil))) This is done by tools/load-asdf.lisp AFAICT, this is done UNCONDITIONALLY BY LOAD-AND-CONFIGURE-ASDF This should not be. The user should get quicklisp only upon request: we added the dependencies to ext/ in order to make the ASDF distribution free-standing and avoid the quicklisp requirement. In my case, I use quicklisp only sometimes, and never yet with CCL, so having the ASDF test script go poking around for a QL installation and firing it up without asking me was problematic. Particularly problematic was that there's no (apparent) way to STOP the ASDF scripts from doing this. For now I am going to push a modification that comments out TRY-LOAD-QUICKLISP from LOAD-AND-CONFIGURE-ASDF. I have no objection to a patch that provides an *explicit option* to load from QL, but it must be an option, and it must not be the default. Frankly, even then I'm not excited about it. I don't want to have bugreports to ASDF that are caused by issues in Quicklisp. I'd rather people stick to using the dependencies in our submodules. 2. This was just a nuisance: three new submodules have been added, and "git submodule init" must be re-run when that happens. I have no idea why the git maintainers thought that a call to git submodule update should quietly fail to update un-initialized submodules (fail to update yes, QUIETLY fail to update, no). But going forward we need to trumpet any changes to the submodules because of this attribute of git.... Cheers, r

4 17

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel January 2016