asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[asdf-devel] Recompiling SBCL contribs
by Zach Beane 08 Apr '15

08 Apr '15

I've saved an executable SBCL image that includes asdf and calls load-system. If the system it's loading depends-on sbcl contribs, e.g. sb-bsd-sockets, it is recompiling the contrib sources. What causes contribs to get recompiled? Is there an easy way to inhibit it? Thanks, Zach

4 11

[asdf-devel] :cwd pathname designator for source registry configuration?
by Mirko Vukovic 08 Apr '15

08 Apr '15

This is a follow-up to my previous post regarding asdf searching for a system in the current working directory. I resolved this to my satisfaction with something like this: (let ((asdf:*central-registry* (push directory asdf:*central-registry*))) (apply #'asdf:load-system system keys))) My question here is two-fold: - Am I misusing ASDF if I have asdf files for local projects sprinkled around, in addition to having them under centralized locations specified in the configuration file? - What about adding a :CWD keyword to the configuration file DSL to specify the current working directory? The new keyword seems to require a minor modification to ``resolve-absolute-location''. I don't know if this would conflict with output translations as it uses the same DSL and presumably code. Thanks, Mirko

2 2

[asdf-devel] Patch for UIOP/UTILITY:ENSURE-FUNCTION
by Mark Evenson 08 Apr '15

08 Apr '15

Without the attached patch, I believe the use of a function for output translations is hosed from post asdf-3.0.2 onwards. I think ABCL is the only implementation actively using the ability to specify an output translation as a function, as indeed Faré expressly introduced this for us. ABCL uses a specialized output translation to translate the location of FASLs for ASDF systems stored in jar files (like ABCL’s contribs) which can’t otherwise be expressed in the translation DSL. I have [committed an asdf-3.0.3.0.1 including this patch][r14583] to ABCL trunk, which I will sync in the near future to ASDF master if this is indeed the correct way to patch the problem. [r14583]: http://abcl.org/trac/changeset/14583 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

3 9

[asdf-devel] ASDF 3.0.2.1 released
by Robert Goldman 08 Apr '15

08 Apr '15

ASDF 3.0.2.1 is the first candidate release for ASDF, containing several bug fixes. If you can, please grab this ASDF release and test it with your systems, and by running make test or make test-all Please report any bugs you find to the ASDF project on launchpad.net We'd like this to pave the way for the best, most solid ASDF release ever! Best, R

4 10

[asdf-devel] (asdf:system-source-directory :uiop) not working after upgrade to 3.0.2.25
by Dave Cooper 08 Apr '15

08 Apr '15

Hi, There is an outstanding request from the maintainer to test the latest asdf "in production," and I'm here trying to do that. So what do I have to do in order to make (asdf:system-source-directory :uiop) still work after upgrading asdf? Is it a bug that after upgrading from 3.0.2.3 (the current ASDF shipping with fully patched Allegro) to 3.0.2.25, then (uiop:system-source-directory :uiop) returns nil? Before upgrading, it returns the uiop-3.0.2.4/ in the quicklisp/dists/quicklisp/software directory. After upgrading, it returns nil. The impact of this in production is that I am trying to make a monolithic fasl of a system which depends on :uiop, and the :uiop module is not getting included in this monofasl. This of course results in "package missing" errors when trying to load this monofasl into a vanilla image to do a build. The way I install asdf 3.0.2.25 for trying to use it in production is: 1. git pull into my local asdf directory. 2. make (to make a single asdf.lisp file in asdf/build/) 3. copy this to quicklisp/asdf.lisp 4. rm -r quicklisp/cache 5. edit quicklisp/setup.lisp to say: (defvar *required-asdf-version* "3.0.2.25") 6. copy the uiop/ directory from local asdf/ into quicklisp/local-projects/ 7. restart the Lisp 8. load quicklisp/setup.lisp and (ql:register-local-projects) Having done all this, the (asdf:system-source-directory :uiop) still returns nil, and uiop is not ending up in my monofasls which depend on it. Am I doing it wrong? My Best, Dave

2 3

[asdf-devel] Retest
by Robert P. Goldman 08 Apr '15

08 Apr '15

Now all tests pass on Linux for me (but I'm not testing ABCL there). ABCL on the Mac fails test-stamp-propagation: TEST ABORTED: These two expressions fail comparison with EQUAL: (SANITIZE-LOG (RELOAD ASDF/DEFSYSTEM:DEFSYSTEM)) evaluates to ((:COMPILING :SYSTEM)) (QUOTE ((:COMPILING :SYSTEM) (:COMPILE-TOPLEVEL :FILE1) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2))) evaluates to ((:COMPILING :SYSTEM) (:COMPILE-TOPLEVEL :FILE1) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2)) Above backtrace due to this condition: These two expressions fail comparison with EQUAL: (ASDF-TEST::SANITIZE-LOG (ASDF-TEST::RELOAD ASDF/DEFSYSTEM:DEFSYSTEM)) evaluates to ((:COMPILING :SYSTEM)) (QUOTE ((:COMPILING :SYSTEM) (:COMPILE-TOPLEVEL :FILE1) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2))) evaluates to ((:COMPILING :SYSTEM) (:COMPILE-TOPLEVEL :FILE1) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2)) Script failed Using abcl, test-stamp-propagation.script failed Does this work on Linux? cheers, r

2 3

[asdf-devel] Trying to get ASDF tests (especially uiop:run-program) on Windows (Allegro CL, CCL) cleaned up before 3.0.3 release
by Dave Cooper 08 Apr '15

08 Apr '15

Starting a new thread, but in due course we should keep Fare's most recent words from previous thread in mind for expanding the test suite for uiop:run-program: Fare wrote: Ideally there would a test that includes all printable ASCII > characters and ensures that quoting works alright, with either a list > or string argument (beware quoting when generating the string). Anyway, here is what I'm seeing currently (with an unpatched 3.0.2.7): Allegro 9.0: ========= Running the test script from cygwin brings up an Allegro CL Console which immediately displays the following error: ==== An unhandled error occurred during initialization: An error occurred (Attempt to take the value of the unbound variable `|"TEST/SCRIPT-SUPPORT.LISP"|'.) during the reading or evaluation of -e "(or #.(load \\\"test/script-support.lisp\\\") #.(asdf-test::compile-asdf-script))" <The Lisp process exited with status -1 (0xffffffff)> ==== So the -e argument is not making it properly into the Allegro, and it looks like something has to be updated in the test script just to get Allegro/Windows to start running the tests. Would anyone from Franz Support care to have a look at this? I did confirm that normal programs can be run with Allegro's excl:run-shell-command without the need for "cmd /c" prepended. CCL 1.9 ======= asdf test results for (unpatched) 3.0.2.7 are here: https://www.dropbox.com/sh/jc2cqwpkp06dupm/tx0U1Fun65/cl/tests/asdf/output/… Note that the first failure, for the bundle-test, is a known bug in ccl:fasl-concatenate in CCL 1.9 for Windows, and has been fixed in the trunk for CCL 1.10. The second failure just looks like the extra space after the "ok 1" as we were seeing before. Perhaps this is also a CCL issue? Can anyone from Clozure comment on this? Also, I think I confirmed that CCL's ccl:run-program on Windows really does need the "cmd /c " prepended to be able to run a normal program. Currently the uiop:run-program is doing (cons "cmd" (strcat "/c " command)) for commands given as a single string, but it does not prepend anything for commands given as a list. There was previous opinion that the list form of the command should not automatically get the ("cmd" "c/") prepended. But from what I can tell, the user will always have to do (uiop:run-program (append '("cmd" "/c") command) if user wants to give command as a list. If that's the case, then for consistent interface of uiop:run-program across different Lisps, shouldn't uiop:run-program go ahead and do that appending by default? SBCL ===== Sorry, I'm not running SBCL on Windows at the moment. Anyone? Get with me if you can use some guidance getting the ASDF test scripts running. LispWorks ======== I don't have LWW at this juncture. Anyone? ABCL, ECL, CLISP, GCL (who am I forgetting?) ====================================== Anyone running these on Windows and willing to run some ASDF testing scripts (probably through cygwin)? Get with me if you want some guidance and/or moral support. Regards, Dave

2 3

[asdf-devel] deferred warnings doesn't tell which file
by Attila Lendvai 08 Apr '15

08 Apr '15

hi! so, i'm using deferred warnings, because warnings are useful! the only problem is that, in this specific case, i get the following after compilation has finished: ; compilation finished in 0:00:00.033 ; in: LAMBDA (SB-PCL::.METHOD-ARGS. SB-PCL::.NEXT-METHODS.) ; (SB-MOP:SLOT-VALUE-USING-CLASS # HU.DWIM.PEREC::INSTANCE ...) ; ; caught WARNING: ; undefined variable: HU.DWIM.PEREC::INSTANCE ; ; compilation unit finished ; Undefined variable: ; HU.DWIM.PEREC::INSTANCE ; caught 1 WARNING condition ; ; compilation unit aborted ; caught 4 fatal ERROR conditions and it doesn't even tell which file it happened with. (this error comes from the depths of sbcl internals around generic methods). how was it meant to work originally? is it assumed that the warning will always contain a name or something that helps identifying where it comes from? if so, then it's not always the case, and when warnings are not deferred at least the current toplevel form is visible in the output. note: this is not a showstopper just an inconvenience. i can identify the file by checking the *.sbcl-warnings files manually. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Here is the world. Beautiful and terrible things will happen. Don't be afraid.” — Frederick Buechner

2 2

[asdf-devel] Pushed manual cleanups
by Robert P. Goldman 08 Apr '15

08 Apr '15

I have pushed what I hope are substantial improvements to the ASDF manual, at least to the early parts of it. Faré: is it easily possible to push this to the web page using your makefile? Cheers, r

2 5

[asdf-devel] ASDF
by Faré 08 Apr '15

08 Apr '15

I suppose it would be better to release 3.0.3 without merging my branches, and merge my branches afterwards. On the other hand, there are a few bugs I fixed in my run-program branch, independently from the new functionality, that I'd like to commit in the master branch before the release, with your permission: * the external-format bug in with-temporary-file is shameful. Sorry. * the stdin / stdout / stderr initialization is better, and allows run-program to work at all on ECL when in SLIME (or in many other cases). * the slight changes in external-format defaults (from :default to utf-8) should be done earlier rather than later (for increased consistency) * the new docstrings are also merge-worthy. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are even incapable of forming such opinions. — Albert Einstein

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel