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

[Asdf-devel] Registering preloaded systems for Quicklisp/ASDF
by Dave Cooper 05 Jun '15

05 Jun '15

Hi, I know this has been discussed, but what is currently the best practice for registering a preloaded system after loading Quicklisp? That is, I have a pre-built image with some Quicklisp/ASDF systems in it, which were loaded through so-called monolithic-fasls (now known as compile-bundles). So the pre-built image doesn’t itself have ASDF or Quicklisp. A downstream user then loads Quicklisp and ASDF (I take steps to ensure that they are loading the matching version of ASDF and Quicklisp as was used to build the image). Now I need to do something to tell Quicklisp and ASDF that certain systems are already loaded in this image, so it won’t try to re-load them as depended-upon systems. In this specific case, I don't want it to try to fetch and reload Gendl when the user does (ql:quickload ...) on an application which :depends-on :gendl (because gendl is already built into this image). asdf/find-system:register-preloaded-system seems like it should be the answer if we’re talking about plain ASDF, because it will prevent ASDF from raising a “missing-component” error for the system in question, if some other system :depends-on it and yet no source code is found. But in my case I can’t guarantee that “no source code is found.” The source might be there in the quicklisp dist directory. So apparently I need something stronger than register-preloaded-system? Or something else? -- My Best, Dave Cooper

3 21

[Asdf-devel] ASDF test failure on MKCL linux
by Robert P. Goldman 19 Nov '14

19 Nov '14

test-bundle failed for me, on version 1.1.9 of MKCL: Now for the mono-fasl TEST ABORTED: There is no package with the name MKEXT. 0: (#<compiled-closure 0000000004039500> #<compiled-debug-lexical-info 00007fffcfee80d0>) 1: (#<compiled-function UIOP/STREAM:CALL-WITH-SAFE-IO-SYNTAX> #<compiled-debug-lexical-info 00007fffcfee82b0>) 2: (#<compiled-function UIOP/IMAGE:PRINT-BACKTRACE> #<compiled-debug-lexical-info 00007fffcfee8490>) 3: (#<compiled-function UIOP/IMAGE:PRINT-CONDITION-BACKTRACE> #<compiled-debug-lexical-info 00007fffcfee8660>) 4: (#<bytecompiled-function ASDF-TEST:ACALL> ((ASDF-TEST::ARGS #<a SIMPLE-ERROR 66680128> :COUNT 69 :STREAM #<output strea\ m "stdout">) (ASDF-TEST::NAME . :PRINT-CONDITION-BACKTRACE) (#:|%the-lock--28954-510| . #<lock (recursive) MT:+LOAD-COMPIL\ E-LOCK+ 00000000010b5280>) (#:|%lock-acquired--28954-511| . T))) 5: (#<bytecompiled-function 00000000035f4f00> (((NIL) (#:G-28954-948 . 0)) (#:G-28954-947) ((NIL) . #:G-28954-946) (ASDF-T\ EST::C . #<a SIMPLE-ERROR 66680128>) (:ASDF-TEST-DONE . :ASDF-TEST-DONE) (ASDF-TEST::THUNK . #<bytecompiled-closure 000000\ 0003d48180>) (#:|%the-lock--28954-932| . #<lock (recursive) MT:+LOAD-COMPILE-LOCK+ 00000000010b5280>) (#:|%lock-acquired--\ 28954-933| . T))) 6: (#<bytecompiled-function 0000000003628f80> ((ASDF-TEST::NAME . "test-bundle.script") (ASDF-TEST::FILE . ASDF-TEST::|tes\ t-bundle.script|) (#:|%the-lock--28954-982| . #<lock (recursive) MT:+LOAD-COMPILE-LOCK+ 00000000010b5280>) (#:|%lock-acqui\ red--28954-983| . T))) 7: (#<compiled-function ASDF/CACHE:CALL-WITH-ASDF-CACHE> #<compiled-debug-lexical-info 00007fffcfeea620>) 8: (#<bytecompiled-function ASDF-TEST::CALL-WITH-TEST> ((:ASDF-TEST-DONE . :ASDF-TEST-DONE) (ASDF-TEST::THUNK . #<bytecomp\ iled-closure 0000000003d48180>) (#:|%the-lock--28954-932| . #<lock (recursive) MT:+LOAD-COMPILE-LOCK+ 00000000010b5280>) (\ #:|%lock-acquired--28954-933| . T))) 9: (#<bytecompiled-function ASDF-TEST:RUN-TEST-SCRIPT> ((ASDF-TEST::FILE . ASDF-TEST::|test-bundle.script|) (#:|%the-lock-\ -28954-982| . #<lock (recursive) MT:+LOAD-COMPILE-LOCK+ 00000000010b5280>) (#:|%lock-acquired--28954-983| . T))) 10: (#<bytecompiled-function SI:BYTECODE> NIL) 11: (#<bytecompiled-function SI:BYTECODE> ((SI::OUTPUT-FILE . T) (SI::C-FILE) (SI::H-FILE) (SI::DATA-FILE) (SI::EXTERNAL-F\ ORMAT . :DEFAULT) (SI::VERBOSE . T) (SI::FASL-P . T) (MKCL:QUIT))) 12: (#<bytecompiled-function SI:BYTECODE> NIL) 13: (NIL NIL) Above backtrace due to this condition: There is no package with the name MKEXT. Script failed Using mkcl, test-bundle.script failed Updated mkcl to head from git as of this afternoon, and same error, and this time test-retry-loading-component-1 *also* failed: TEST ABORTED: Error while trying to load definition for system hello-world-example from pathname /home/rpg/common-lisp/asd\ f/test/hello-world-example.asd: Unknown initialization option :EPILOGUE-CODE for class #<The STANDARD-CLASS SYSTEM 7752937\ 6> Cheers, r Tried updating my mkcl from git and that failed to build on linux: sed '/-CUT-/,$d' ./mkcl/config.h > ./mkcl/config-install.h /bin/bash: ./mkcl/config-install.h: Permission denied make[1]: *** [mkcl/config-install.h] Error 1 make[1]: Leaving directory `/home/rpg/src/mkcl/src' make: *** [all] Error 2

4 19

[Asdf-devel] ASDF does not signal deferred non-style warnings as an error
by Ilya Perminov 31 Oct '14

31 Oct '14

Hi, ASDF does not raise an error, when the SBCL compiler produces warnings (e.g. "undefined variable", "undefined function"). Example: ======== test.asd ============= (defsystem :test :version "1.0" :components ((:file "test"))) ======== test.lisp ============ (defun foo () (+ a b)) =============================== (asdf:load-system :test) does not signal an error. I discovered this problem using SBCL, but I bet it can be reproduced on some other CL implementations that deffer warnings. The cause of the problem is that WITH-COMPILATION-UNIT may affect result values (warnings-p, and failure-p) of COMPILE-FILE. sbcl-help has a discussion of this WITH-COMPILATION-UNIT/COMPILE-FILE interaction: http://sourceforge.net/p/sbcl/mailman/message/32976990/ Regards, Ilya

3 9

Re: [Asdf-devel] resurrecting some tests
by Robert P. Goldman 16 Oct '14

16 Oct '14

Dave Cooper wrote: > For what it's worth, I experimented with my installed clisp (installed > with homebrew on Mac, clisp 2.49). Just starting the plain clisp, and > calling > > (ext:saveinitmem "/tmp/try.image" :executable t) > > results in an image which gives the same error: > > module 'syscall' requires package OS. > > Reading in some forums > (http://web.archiveorange.com/archive/v/nsNbdc66dCHkCg8lKyXg) other > people encountered the same error, and fixed it by upgrading to CLISP > 2.49+. Will try that when I get a chance... should we comment out the > test-program.script for clisp, or assume clisp 2.49+ and leave it in? > It seems like it is time to ask the clisp maintainers (if any) to try to > make new builds, which fix this problem - I for one am not really used > to hand-compilng Lisps like this... The clisp test failure is a failure in the lisp-invocation library. I don't own that (still waiting for commit privileges), so I made the executive decision not to hold up ASDF release for it. I try to keep up on the latest *released* versions of lisp implementations, and there are some (SBCL, mkcl, and ABCL) where I'm more likely to be on the bleeding edge. With these exceptions, I limit myself to testing against versions available through Mac Ports and Ubuntu packages. I don't regard it as my job to build or test on pre-release versions of lisp implementations, although I'm certainly willing to provide support for those who wish to do so. Minimakefile is not in master yet, so it's not ready. I hope to work to get it into master, but I'm not sure how to test it. Since it's a development tool, it's not obvious how to test it. Cheers, r > > > > > On Wed, Oct 15, 2014 at 1:29 AM, Dave Cooper > wrote: > > > [please let me know if I should post this to the > asdf-devel(a)common-lisp.net - I'm > not sure if we are back in testing mode or not]: > > So is 3.1.4 the thing we were trying to run these tests for? > > It got released with several apparent issues still hanging. Is the > idea that those issues are not new regressions, so go ahead and > release? > > Anyway I'm trying to carry on with some testing here. Currently I get: > > Macos: > ====== > > Master: Failure with clisp (as reported before) > Minimakefile: If I run the tests as before, with several > ASDF_TEST_LISPS, it only runs for sbcl (and does succeed). > > > Windows: > ======= > > Master: [alisp.dxl] TEST ABORTED: illegal namestring: ... (reported > last time) > Minimakefile: Makefile:88: *** missing separator (did you mean TAB > instead of 8 spaces?). Stop. > > > -- > 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) > > > > > -- > 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

2 1

Re: [Asdf-devel] resurrecting some tests
by Robert P. Goldman 15 Oct '14

15 Oct '14

Dave Cooper wrote: > Windows: > ======= > > Master: [alisp.dxl] TEST ABORTED: illegal namestring: ... (reported > last time) > Minimakefile: Makefile:88: *** missing separator (did you mean TAB > instead of 8 spaces?). Stop. > Will you please send the transcript for Master? I'm sure I must have this somewhere, but I don't know how to retrieve it. As for the Makefile line, it looks like it was mistakenly untabified. I changed that and re-pushed. Will you please try again? Thanks, r

1 0

[Asdf-devel] ASDF 3.1.4 released today
by Robert Goldman 11 Oct '14

11 Oct '14

This is a maintenance and bugfix release. There should be no incompatibilities, and many small fixes. The one new feature is an optional speedup to system search. Users who have large directory trees to search, and stable sets of systems, can build a system search cache that will substantially speed up finding and loading system definitions. Because this version does not cause compatibility issues, we strongly suggest that implementations move to replace 3.1.3 with 3.1.4. Thanks to Faré for many bug fixes, to Dave Cooper for testing, and all who reported bugs and provided patches. Best, R

3 7

[Asdf-devel] clisp test failure
by Robert P. Goldman 09 Oct '14

09 Oct '14

Here's what RUN-PROGRAM gets for arguments: (RUN-PROGRAM '("/Users/rpg/lisp/asdf/build/fasls/clisp-2.49-unix-x86_64/asdf/test/hello-world-example--all-systems.image" "-norc" "--quiet" "--quiet" "-ansi" "-I" "-on-error" "exit" "-x" "(uiop:restore-image :entry-point 'hello:entry-point :lisp-interaction nil)") ':OUTPUT ':LINES ':ERROR-OUTPUT 'T) 1. Trace: RUN-PROGRAM ==> ("[4]> hello, world"), NIL, 0 What happens at the command line agrees with that: $ /Users/rpg/lisp/asdf/build/fasls/clisp-2.49-unix-x86_64/asdf/test/hello-world-example--all-systems.image -norc --quiet -ansi -I -on-error exit -x "(uiop:restore-image :entry-point 'hello:entry-point :lisp-interaction nil)" [4]> hello, world Maybe the error is in UIOP:RESTORE-IMAGE: $ /Users/rpg/lisp/asdf/build/fasls/clisp-2.49-unix-x86_64/asdf/test/hello-world-example--all-systems.image -norc --quiet -ansi -I -on-error exit [1]> (hello:entry-point) hello, world T ...because just calling the entry-point function does not yield the "[4] >" prompt. Unfortunately, neither removing :lisp-interaction nil nor --quiet lets me see what's actually happening inside clisp here. By the way, the "-I" argument here means "be ilisp friendly." Removing this seems to give happier results: $ /Users/rpg/lisp/asdf/build/fasls/clisp-2.49-unix-x86_64/asdf/test/hello-world-example--all-systems.image -norc -ansi -on-error exit -x "(uiop:restore-image :entry-point 'hello:entry-point)" hello, world T Why is that argument there? And why is this working for you?

1 0

[Asdf-devel] Mac test update status
by Robert P. Goldman 09 Oct '14

09 Oct '14

The following tests were run last night (update tests still running): abcl allegro8_64 allegro8_64_s allegro_64 allegro_64_s allegromodern8_64 allegromodern8_64_s allegromodern_64 allegromodern_64_s ccl clisp cmucl ecl lispworks sbcl Two test failures: 1. the clisp test-program failure that we have been discussing, that Dave and I are seeing, and that Faré can't reproduce. More investigation required. 2. sbcl is failing test-retry-loading-component-1: Running test-retry-loading-component-1.script with sbcl-1.2.0-macosx-x64 ; loading #P"/Users/rpg/lisp/asdf/test/test-retry-loading-component-1.script" TEST ABORTED: READ error during LOAD: :ASCII stream decoding error on #<SB-SYS:FD-STREAM for "file /Users/rpg/lisp/asdf/test/test-retry-loading-component-1.script" {100566ACA3}>: the octet sequence #(195) cannot be decoded. (in form starting at line: 8, column: 69, file-position: 241) This smells like a Unicode regression to me. Now, *ASDF* defaults to loading UTF-8 files, but our *script* files are just loaded any old way. "Déjà vu" is a terrible error message, anyway -- cute, but cryptic and unhelpful -- so I'm just going to kill it, rather than drive myself crazy trying to figure out how to load .script files as UTF-8 on every possible Lisp implementation.

3 2

[Asdf-devel] Status update on Linux tests
by Robert P. Goldman 08 Oct '14

08 Oct '14

clisp 2.49: test-program fails We have had a great deal of correspondence about this. mkcl from git failing. We have agreed with JCB that this should not be a blocker, since the test failures seem to be related to mkcl issues. Mac tests will run overnight.

1 0

[Asdf-devel] clisp on Linux [was Re: ASDF Release?]
by Robert P. Goldman 07 Oct '14

07 Oct '14

Faré wrote: > I get an all pass on Linux with my hand-compiled clisp. I have the clisp that you get with Linux Mint, and for me I get this failure: TEST ABORTED: These two expressions fail comparison with EQUAL: (NEST (LISP-INVOCATION:INVOKE-LISP :CROSS-COMPILE NIL :IMAGE-PATH (NATIVE-NAMESTRING IMG) :EVAL "(uiop:restore-image :entry-point 'hello:entry-point :lisp-interaction nil)" :RUN-PROGRAM-ARGS '(:OUTPUT :LINES :ERROR-OUTPUT T))) evaluates to ("[4]> hello, world") '("hello, world") evaluates to ("hello, world") This is the same failure I was getting on Mac OS X (and not the same one Dave was getting). clisp 2.49 As a quick follow-up, when I start clisp the prompt looks like this for me: [1]> I am wondering if somehow your hand-built system gets a different prompt or somehow my prompts bleed through into program output in a way yours don't.... Best, r

2 3