- asdf-devel - mailman3.common-lisp.net

[asdf-devel] One failure on ASDF 3.1.0.70 on Allegro/Windows
by Dave Cooper 08 Apr '15

08 Apr '15

Sorry to be late to the party again with Windows testing... So far I'm seeing a consistent failure for every Allegro variant on Windows for test-sysdef-asdf. Here is the error: These two expressions fail comparison with equal: (asdf-test::system-lisp-files :uiop) evaluates to ("uiop\\package.lisp" "uiop\\common-lisp.lisp" "uiop\\utility.lisp" "uiop\\os.lisp" "uiop\\pathname.lisp" "uiop\\filesystem.lisp" "uiop\\stream.lisp" "uiop\\image.lisp" "uiop\\run-program.lisp" "uiop\\lisp-build.lisp" "uiop\\configuration.lisp" "uiop\\backward-driver.lisp" "uiop\\driver.lisp") (asdf-test::makefile-lisp-files "driver-files") evaluates to ("uiop/package.lisp" "uiop/common-lisp.lisp" "uiop/utility.lisp" "uiop/os.lisp" "uiop/pathname.lisp" "uiop/filesystem.lisp" "uiop/stream.lisp" "uiop/image.lisp" "uiop/run-program.lisp" "uiop/lisp-build.lisp" "uiop/configuration.lisp" "uiop/backward-driver.lisp" "uiop/driver.lisp") Script failed -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

7 27

[asdf-devel] Releasing asdf 3.1.1 ?
by Faré 08 Apr '15

08 Apr '15

Dear Robert, do you think we can release this year? All tests pass for me on Linux, and I believe all tests were passing for Dave Cooper on Windows. There has been very light development this past month, with no intent for further development ahead, but notable new features and bug fixes since the last release in October. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A student who changes the course of history is probably taking an exam.

5 21

Test failure: CCL 1.9 on Mac OSX
by Robert Goldman 08 Apr '15

08 Apr '15

Just pulled and ran all the tests, and CCL 1.9 fails test-utilities on Mac OSX: TEST ABORTED: These two expressions fail comparison with EQUAL: NIL evaluates to NIL (FISHY-ASDF-EXPORTED-SYMBOLS) evaluates to (ASDF/OPERATION:ORIGINAL-INITARGS) cheers, r

2 2

Re: [asdf-devel] Port of ASDF 3.1.0.94 to MKCL
by Jean-Claude Beaudoin 08 Apr '15

08 Apr '15

On Mon, Mar 17, 2014 at 2:47 PM, Robert P. Goldman <rpgoldman(a)sift.info>wrote: > Jean-Claude Beaudoin wrote: > > > > > > > > On Mon, Mar 17, 2014 at 12:48 PM, Robert P. Goldman <rpgoldman(a)sift.info > > <mailto:rpgoldman@sift.info>> wrote: > > > > Random minor question: > > > > In bundle.lisp why the replacement of 'defsystem with > > 'asdf/defsystem:defsystem? Did something go wrong for you with the > > former? > > > > > > The "defsystem" symbol was interned in the wrong package, being read at > > that point of the code into package "asdf/bundle". Package "asdf/bundle" > > does > > not use package "asdf/defsystem". All this resulting into a failure to > > properly > > expand the defsystem macro. > > So, in other words, the bundle code was buggy before, right? You are quite right yourself. > I wonder > why we didn't see this.... What piece of your code exercised this? I'd > like to know so we can test. > The bundle facility is a central part of the MKCL build process. A large part of what MKCL puts in its "contrib" sub-directory is built using it. > > > > > > > > > > Other than that, I didn't see anything in the diff. > > > > > > I hope that you mean that you didn't see anything *wrong* in the diff. > > You are quite right! > > I'll merge to master and tag this afternoon. > > Thanks, > R > > > P.S.: I took the liberty to CC the asdf-devel list since your initial "defsystem" question had too, I left the CC out of my reply by simply not paying enough attention to which reply button I clicked.on.

2 8

Re: [asdf-devel] Releasing asdf 3.1.1 ?
by Faré 08 Apr '15

08 Apr '15

OK, so I've run complete tests of ASDF 3.1.0.34 on Linux x64 with ASDF_TEST_LISPS="ccl clisp sbcl cmucl allegro allegromodern lispworks ecl_bytecodes ecl abcl xcl gcl" I got one unexpected failure, excepted failures: cmucl upgrade total failure https://bugs.launchpad.net/asdf/+bug/1209272 3 failures in gcl (gcl bugs, Camm needs to get back to me). The unexpected failure was ecl's test-bundle: due to misconfiguration in test-asdf.asd, the explicit secondary definitions of test-asdf/dll-test was now overridden by package-system, which was causing asdf/package-system to fail ungracefully because the file had no defpackage form. Failing with end-of-file error rather than giving a user-meaningful error message was a bug. package-system now yields a user-readable error in such cases, with test cases added to the test suite. And the configuration error in test-asdf is now fixed. I'm re-running all the tests with ASDF 3.1.0.35. Looking good so far. Please keep testing in view of a release 3.1.1. PS: Regarding the previously mentioned Quicklisp bugs, see https://github.com/quicklisp/quicklisp-controller/issues/7 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Reason isn't about not having prejudices, it's about having (appropriate) postjudices. — Faré

2 5

[asdf-devel] asdf/bundle and ECL prologue / epilogue
by Faré 08 Apr '15

08 Apr '15

Is anyone at all using asdf-bundle with ECL? It looks like the prologue and epilogue support were casualties of some operation canonicalization. Also, the way the flags are or aren't propagated to sub-operations is misdesigned. Finally, it seems like prologue and epilogue ought to be part of the system, not of the operation — and they are possibly superseded by ASDF3's image support. If anyone is using these features, please contact me ASAP. Otherwise, I'm going to commit into asdf/bundle whatever I believe makes sense. (Bug found through thorough testing of cl-launch.) And of course, please fix that bug that breaks building a program in recent ECL: https://sourceforge.net/p/ecls/bugs/285/ —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Politicians are like diapers: they must be changed often. And for the same reasons. [Also, adults don't need either of them. — Faré]

3 6

[asdf-devel] Loading pre-compiled fasls
by Yellow Dog 08 Apr '15

08 Apr '15

Hi, I was wondering if I could ask for some advice. I'm currently working with lisp-zmq which uses grovel to create the CFFI declarations. This is fine and works great on my development box, but I would prefer not to require that other developers in my organization also run grovel. As such, I would like to be able to check in the files that were generated by grovel and have these automatically loaded in other environments. This already works! However, my problem is that in our environment, ASDF compiles fasls into a default user output path and then loads them (something like ~/.cache/common-lisp/...). I will not have any control over the content at this location prior to loading the lisp-zmq system for the first time, and so there isn't really anywhere that I can automatically deploy the pre-generated grovel files. My questions are: * Is there any way to specify using defsystem that a local fasl should be used? * Are there any suggestions that anybody can give me to solve my problem. Perhaps I should precompile the lisp-zmq system and load that instead. I'd rather not change any of the behavior on anybody's development environment, so (asdf:disable-output-translations) isn't an option. I'd like to have this self contained as much as possible. Many Thanks, Kevin

3 4

[asdf-devel] Advanced Configuration
by FAU 08 Apr '15

08 Apr '15

Hello. I'd like to find out if I can do this with ASDF. Lets say I have a lisp file like this: ;;; foo.lisp (defpackage :foo (:use :cl) (:export :foo)) (in-package :foo) (defun foo () #+foo1.0 :foo1.0 #+foo1.1 :foo1.1 ) ;;; foo.lisp ends here The system definition file: ;;; foo.asd (asdf:defsystem :foo :components ((:file "foo"))) ;;; foo.asd ends here As you can see the behaviour of the fn foo depends on version request features (which, lets say, represents the API version and not the software package version) which must be pushed on *features* before the system is compiled (or loaded). I'd like to have ASDF reject any operation on system foo if there's not an appropriate API version request feature present for it and notify the user in some way. I'd like to keep multiple fasls for different API versions in the cache. (One way to achieve this, which comes to my mind, would be to mangle the name of the fasl output file name to incorporate the version in same way or to change the output directory path.) Thanks -Frank

2 5

[asdf-devel] Problem with CMUCL 20e and ASDF
by Pascal Costanza 08 Apr '15

08 Apr '15

Hi, I just installed CMUCL 20e on my Mac OS X 10.8.5. CMUCL 20e release notes say that it comes with ASDF 3.0.2. My .cmucl-init.lisp file looks like this: (setf (logical-pathname-translations "costanza") `(("**;*.fasl.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.fasl" (lisp-implementation-type) (lisp-implementation-version))) ("**;*.*.*" "/Users/costanza/**/*.*"))) ;;; The following lines added by ql:add-to-init-file: #-quicklisp (let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp" (user-homedir-pathname)))) (when (probe-file quicklisp-init) (load quicklisp-init))) When I start CMUCL, I see this: ; Loading #P"/Users/costanza/.cmucl-init.lisp". ;; Loading #P"/Users/costanza/quicklisp/setup.lisp". ;;; Loading #P"/Users/costanza/lib/cmucl/lib/contrib/asdf/asdf.sse2f". Error in function UIOP/UTILITY:CALL-FUNCTION: Invalid pathname #P"~/lisp/develop/": Expected an absolute pathname [Condition of type SIMPLE-ERROR] Restarts: 0: [REINITIALIZE-SOURCE-REGISTRY-AND-RETRY] Retry finding system asdf after reinitializing the source-registry. 1: [CONTINUE ] Return NIL from load of #P"home:quicklisp/setup.lisp". 2: Return NIL from load of "home:.cmucl-init". 3: [ABORT ] Skip remaining initializations. Debug (type H for help) (UIOP/UTILITY:CALL-FUNCTION ERROR "Invalid pathname ~S: ~*~?" #P"~/lisp/develop/" :WANT-ABSOLUTE ...) Source: ; File: modules:asdf/asdf.lisp ; File has been modified since compilation: ; modules:asdf/asdf.lisp ; Using form offset instead of character position. (APPLY (ENSURE-FUNCTION FUNCTION-SPEC) ARGUMENTS) 0] What do I do? Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

3 4

[asdf-devel] rename-file-overwriting-target on clisp
by Sam Steingold 08 Apr '15

08 Apr '15

Hi, I wonder why this function has a special case for clisp: (defun rename-file-overwriting-target (source target) #+clisp ;; But for a bug in CLISP 2.48, we should use :if-exists :overwrite and be atomic (posix:copy-file source target :method :rename) #-clisp (rename-file source target #+clozure :if-exists #+clozure :rename-and-delete)) it would seem that a more portable solution would be (defun rename-file-overwriting-target (source target) #-clozure (when (probe-file target) (delete-file target)) (rename-file source target #+clozure :if-exists #+clozure :rename-and-delete)) this code causes build problems in clisp because when asdf is distributed with clisp, it is built before the posix module is available. also, nobody uses 2.48 anymore, so I think you can safely assume 2.49. thanks. -- Sam Steingold <http://sds.podval.org> <http://www.childpsy.net/>

2 2