asdf-devel November 2014

asdf-devel@common-lisp.net

4 participants
10 discussions

[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] Request for hints debugging ASDF: SLIME-FIND-DEFINITION
by Robert P. Goldman 27 Nov '14

27 Nov '14

Any advice about the attached would be helpful... 1. I thought I had figured out how to interactively get at the real definitions, instead of the ones dumped into build/asdf.lisp (which I don't want to edit -- that's like editing your binary). I have this function: (defun debug-asdf () (dolist (c (asdf::required-components :asdf/defsystem :keep-component 'asdf:cl-source-file)) (load (asdf:component-pathname c)))) and that does seem to load everything properly. However, use of SLIME-EDIT-DEFINITION after executing DEBUG-ASDF still dumps me into build/asdf.lisp instead of where I want to be. 2. SLIME-EDIT-DEFINITION on SBCL is confused by the WITH-UPGRADABILITY macro. Anyone know of a way to clue SLIME in to the fact that what's really wanted is the enclosed DEFUN* form, not the WITH-UPGRADABILITY macro? Interestingly, ACL is *not* fooled by this macro, and drops me where I want to be (although still in asdf.lisp instead of the component file). So this seems to be a problem with SB-INTROSPECT:FIND-DEFINITION-SOURCE, not SLIME per se. Cheers, r

2 2

[Asdf-devel] native-namestring in asdf/cache:normalize-namestring?
by Orivej Desh 25 Nov '14

25 Nov '14

Currently, between CFFI-GROVEL and ASDF, neither normalizes pathnames with a dot in :NAME and NIL in :TYPE. (cffi-grovel:grovel-file "grovel.cffi") in a system definition may cause an error under SBCL in ASDF/CACHE:NORMALIZE-NAMESTRING when it calls NAMESTRING on the value of CFFI-GROVEL::EXE-FILENAME: Calling (cffi-grovel::exe-filename #p"grovel.cffi.lisp") returns #<pathname (with no namestring) :HOST #<sb-impl::unix-host {10002ACE43}> :DEVICE nil :DIRECTORY (:relative ".") :NAME "grovel.cffi" :TYPE nil :VERSION :newest> to ASDF/ACTION:COMPUTE-ACTION-STAMP which can't deal with it when called with :JUST-DONE NIL. Backtrace: http://report.quicklisp.org/cl-libssh2/2014-09-26/failtail.txt One solution is to make CFFI-GROVEL::EXE-FILENAME normalize resulting pathname: https://github.com/cffi/cffi/pull/52 Another is to make ASDF/CACHE:NORMALIZE-NAMESTRING call NATIVE-NAMESTRING instead of NAMESTRING. Who should be responsible for normalizing such a pathname, ASDF of CFFI-GROVEL?

3 3

[Asdf-devel] ASDF 3.1.4.1 (non-release) pushed
by Robert P. Goldman 21 Nov '14

21 Nov '14

This has a bug-fix for MKCL and some minor tweaks to the internal tools (not visible to most of you) and tests. Bug-reports and test results welcome. Cheers, r

1 0

[Asdf-devel] Mistakenly pushed mis-numbered version
by Robert P. Goldman 21 Nov '14

21 Nov '14

Please don't pull from the repo while I tidy this up, or there will be non-fast-forward merges. Sorry!

1 0

[Asdf-devel] Noticed CCL issue in Linux tests
by Robert P. Goldman 21 Nov '14

21 Nov '14

When testing the MKCL patch, I did a test-all on Linux, and found that CCL claimed not to build cleanly. But actually it wasn't failing to build cleanly: it was failing to correctly parse the second command line in test_clean_load. I am not seeing this on Mac, but there I have 1.9 instead of 1.10. Unfortunately the transcript is not helpful (see attachment). Seems like I'm no longer able to parse all that quoting. Two questions: 1. Can anyone else replicate this? 2. Any reason we couldn't take the contents of that command line and stuff it into a lisp file to load? Thanks! R

1 0

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel November 2014