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

[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] Pushed change to test-program
by Robert P. Goldman 05 Nov '14

05 Nov '14

Previously, if the lisp-invocation library was not there, we would simply skip this test (relatively quietly -- the skip was not visible at the end of the run). I have changed this so that the test fails in that case. There's no need to skip any longer, since the tester will have lisp-invocation available in the ASDF repository as a git submodule. This will help avoid problems we've had, as most recently with JCB, who checked out a fresh ASDF, and believed all was well, because absent a git submodule initialization, test-program.script was skipping, rather than failing. Please report any issues, R

1 0

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

04 Nov '14

Jean-Claude Beaudoin wrote: > I think I just found out the environmental discrepancy between your > setup and mine. > test-program.script depends on system :lisp-invocation from XCVB and > will happily skip over the whole test if that demand is not satisfied. > XCVB is not currently part of my readily available configuration. Thus > nothing shows up on my side when I test ASDF. > > In a patch I provided to you to port ASDF 3.0.3 to MKCL and that you > applied on 2014-03-17, I submitted in test-program.script a way to run > the test without that "XCVB/lisp-invocation" dependency but that code > got removed by the commit applied right after yours. > > Currently test-program.script seems to be the only test requiring XCVB. > Is this requirement really worth the overhead it imposes? Actually, we pulled lisp-invocation into ASDF as a git submodule (it was liberated from XCVB). You should get this lisp invocation automatically. Please go to your ext/ subdirectory and populate the git submodules there, and try again. Thanks! r

2 1

[Asdf-devel] New test-undeferred-warnings.script
by Robert P. Goldman 03 Nov '14

03 Nov '14

I have put in a new test, test-undeferred-warnings.script, that illustrates your problem. It fails on the version of SBCL I have on my Mac, but succeeds on ACL and CCL. I think this is arguably an SBCL bug. I understand there's been some correspondence on the subject of deferring warnings on sbcl-devel lately. Cheers, r

1 0

[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