asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[asdf-devel] spurious warnings patch for CMUCL
by Devon Sean McCullough 06 Sep '10

06 Sep '10

Fix two unreachable code removal warnings in CMUCL: diff -Bbdur old/asdf/asdf.lisp new/asdf/asdf.lisp --- old/asdf/asdf.lisp 2010-05-21 17:18:04.000000000 -0400 +++ new/asdf/asdf.lisp 2010-05-22 17:01:06.000000000 -0400 @@ -492,7 +492,7 @@ (let* ((specified (pathname specified)) (defaults (pathname defaults)) (directory (pathname-directory specified)) - #-sbcl (directory (if (stringp directory) `(:absolute ,directory) directory)) + #-(or cmu sbcl) (directory (if (stringp directory) `(:absolute ,directory) directory)) (name (or (pathname-name specified) (pathname-name defaults))) (type (or (pathname-type specified) (pathname-type defaults))) (version (or (pathname-version specified) (pathname-version defaults)))) @@ -734,7 +734,7 @@ (directory (pathname-directory p))) (when (typep p 'logical-pathname) (return p)) (ignore-errors (return (truename p))) - #-sbcl (when (stringp directory) (return p)) + #-(or cmu sbcl) (when (stringp directory) (return p)) (when (not (eq :absolute (car directory))) (return p)) (let ((sofar (ignore-errors (truename (pathname-root p))))) (unless sofar (return p)) Peace --Devon /~\ \ / Health Care X not warfare / \ PS: Is this a good venue for patches?

2 1

[asdf-devel] configuration question
by Daniel Herring 02 Sep '10

02 Sep '10

Hi all, I've been kicking the old LibCL tires lately (tyres for those of you in the UK). ;) With ASDF1, LibCL's configuration required the following steps to be added to the user's lisp rc files. - make sure ASDF is loaded (and trying to guess whether to use the implementation's copy or LibCL's copy) - push LibCL's link directory into *central-registry* - load asdf-binary-locations I think ASDF2 makes these steps easier. - make sure LibCL's ASDF is loaded (ASDF's upgrading handles old implementations, and blocks a downgrade?) - drop a new file in ASDF's config.d - put some translations in that config file So the only potential change to the user's lisp rc file is an added line to load LibCL's ASDF file. The other steps can be done once for all implementations. However, I'm having some difficulty with the config.d file. So far, the syntax is fine; its the naming that I can't get right. When a new version of LibCL is installed, I don't want to auto-uninstall the old version... So my thought was to create files like the following. 50-libcl-2009-10-27.conf # old config 50-libcl-2010-10-27.conf # new, preferred config Unfortunately, string< will load the old file first; thus the old libraries will be found first... Can you think of a natural naming scheme such that the new libraries will be found? Thanks, Daniel

2 1

[asdf-devel] asdf git?
by Zach Beane 02 Sep '10

02 Sep '10

Fare, you mentioned that you committed a new version, 2.126. I'd like to test it by building all Quicklisp projects with it. However, that revision doesn't show up in the git repo I'm using, git://common-lisp.net/projects/asdf/asdf.git. I see only 2.125. Should I use a different repo, or use some command other than "git pull" to get it? Zach

2 1

[asdf-devel] Should ASDF define many packages?
by Faré 01 Sep '10

01 Sep '10

sds filed an interesting bug: https://bugs.launchpad.net/bugs/620579 The question is whether we should avoid creating extra packages, and instead export all relevant functions from ASDF, or should we keep those separate packages ASDF-BOOTSTRAP and ASDF-UTILITIES. Does anyone of you use functions from ASDF-UTILITIES? Does any of you :use ASDF-UTILITIES? Should I just export the same functions from ASDF instead? Would you see a problem with ASDF-UTILITIES either disappearing or becoming an alias for ASDF? PS: we're at ASDF 2.005 (=2.120), and considering the sudden surge of bugs that led to 2.121, there will be a 2.006 soon. Sigh. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [A] Computer [programming] language is inherently a pun — [it] needs to be interpreted by both men & machines. — hbaker

4 10

[asdf-devel] Draft paper for ILC 2010
by Faré 01 Sep '10

01 Sep '10

Dear all, Robert and I have written a paper about ASDF that we intend to submit to ILC'2010, and we'd be delighted to hear about your comments for this draft: http://common-lisp.net/project/asdf/ilc2010draft.pdf [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] If normative judgments cannot be rational, then science is actually useless. — François Guillaumat

1 0

[asdf-devel] Is there anything one can do to make old versions of clisp run ASDF2?
by Robert Goldman 01 Sep '10

01 Sep '10

I am getting complaints about a library that I maintain, which is loaded using ASDF, from CLISP users. These aren't bugs with my system, but when they try to bring up ASDF to load it... fail. This has to do with this error: #<PACKAGE POSIX> has no external symbol with name "UID" I believe there is a CLISP ticket about this. The problem is that the version of CLISP distributed with Ubuntu 10.4 and the one distributed with OpenSUSE 11.2 both are too old to have this fix. It seems like it would be A Good Thing if ASDF2 could be made compatible with Ubuntu and OpenSUSE. Is there an easy work-around for this that we could patch into the current version of ASDF2? Cheers, r

2 1

[asdf-devel] Optional dependencies
by Tobias C Rittweiler 21 Aug '10

21 Aug '10

Quite a few libraries come with reader hacks. They usually come with a ENABLE-FOO-SYNTAX function. I'd like those libraries to optionally depend on the named-readtables library, and define a named readtable that includes their hacks. So users can just use (IN-READTABLE FOO:SYNTAX) on a per-file basis. What do you think would be the best way to do it? There's :weakly-depends-on which only loads a dependency if that system is present. Named-readtables pushes :NAMED-READTABLE to *FEATURES*. So in principle, people can use (:weakly-depends-on :named-readtables) and then #+named-readtables (named-readtables:defreadtable ...) Or put that definition in a file readtable.lisp and use feature-conditionalized compilation in the system definition (which used to be, and I guess still is, awfully awkward -- I never remember how to do it.) Now I'm wondering how good that solution is. What is if the library was compiled with a core that happened to include named-readtables? Trying to load that fasl with another core file would probably result in an obscure error. Now, it's a shoot-yourself-in-the-foot kind of thing to do, but I'd think it's something that can happen quite easily. Does ASDF somehow guard against this case? >From what I can see, it appears that :WEAKLY-DEPENDS-ON was added in a quick rush thinking that it might be appropriate for conditional compilation, but it really is not. Does that seem true to you, too? Maybe people can share how they got bitten by it? I'd think ASDF should include a ./configure step (there are extension for that kind of thing out there), and should then save configuration choices persistently, and check for these when loading a system. -T. PS. Thanks, appreciation, and kudos again to Fare and Robert for having taken up the ASDF hat.

5 8

Re: [asdf-devel] [Sbcl-help] cl-fad, sb-grovel and failure to compile constants.lisp-temp
by Nikodemus Siivola 18 Aug '10

18 Aug '10

On 18 August 2010 14:49, James Fleming <lisp(a)electronic-quill.net> wrote: > The very short version of the question: what changed between 1.0.39 and > 1.0.40, regarding the expected locations of source files, and when/how > they're expected to be copied there during asdf::perform operations? ASDF version supplied with SBCL changing is the probable culprit for at least some of this -- adding asdf-devel to CC. (It seems the NEWS entry for ASDF2 was forgotten, oops...) However, this bit right here > ; compiling file > "/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-grovel/def-to-lisp.lisp" (written 15 indicates that something else is wrong too: loading SB-GROVEL should not cause it to be compiled. If your ASDF-LOAD uses :FORCE, that's a the obvious reason, but if not I suspect something funny is going on with timestamps on those files since ASDF feels the need to recompile them. Cheers, -- Nikodemus > The context: I'm writing a wiki (yes, yet another one), and its back-end > consists of plain-text files while I get to grips with writing a parser. > > The text-file wrangling calls on cl-fad, which uses sb-posix, which in > turn makes use of sb-grovel. > Somewhere between 1.0.39 and 1.0.40, a change was made that broke > sb-posix, at least on the two machines I use - both run 64-bit Linux, one > on AMD and one on Intel. > > The symptom: sb-grovel's def-to-lisp fails to compile at line 244, where > it tries to evaluate (compile-file tmp-constants :output-file output-file) > after defining 'tmp-constants in this manner: > (let ((tmp-constants (merge-pathnames #p"constants.lisp-temp" > real-output-file))) > > It seems to come down to where source-files are expected to be, i.e. the > ~/.cache tree, and how they're copied there. The problem can be reproduced > on cue by invoking (asdf:oos 'asdf:load-op :sb-posix). This appears as > (asdf-load :sb-posix) below because I'm a lazy git and defined that > abbreviation in my .sbclrc. > > I've been trying to follow along in the source-code, and the nearest > relevant changes appear to be in contrib/asdf/asdf.lisp, but my thinking > has been addled by a nasty head-cold. Could somebody please give me a > pointer to what I need to look at next? What have I missed? Help! > > > Thanks in advance for any useful tips, > James > > > P.S. For those who'd like to see exactly what happens, a bleeding great > copy-and-paste follows... > > * (asdf-load :sb-posix) > > ; compiling file > "/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-grovel/def-to-lisp.lisp" (written 15 > AUG 2010 07:51:57 PM): > ; compiling (IN-PACKAGE #:SB-GROVEL) > ; compiling (DEFVAR *DEFAULT-C-STREAM* ...) > ; compiling (DEFUN ESCAPE-FOR-STRING ...) > ; compiling (DEFUN SPLIT-CFLAGS ...) > ; compiling (DEFUN C-ESCAPE ...) > ; compiling (DEFUN AS-C ...) > ; compiling (DEFUN PRINTF ...) > ; compiling (DEFUN C-FOR-ENUM ...) > ; compiling (DEFUN C-FOR-STRUCTURE ...) > ; compiling (DEFUN PRINT-C-SOURCE ...) > ; compiling (DEFUN C-CONSTANTS-EXTRACT ...) > ; compiling (DEFCLASS GROVEL-CONSTANTS-FILE ...) > ; compiling (DEFINE-CONDITION C-COMPILE-FAILED ...) > ; compiling (DEFINE-CONDITION A-DOT-OUT-FAILED ...) > ; compiling (DEFMETHOD PERFORM ...) > > ; > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-grovel/ASDF-TMP-def-to-lisp.fasl > written > ; compilation finished in 0:00:00.558 > (/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.fasl > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.fasl > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/foo.c > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/a.out > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp) > > debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #<THREAD > "initial > thread" RUNNING > {1002AC20A1}>: > failed to find the TRUENAME of > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp: > No such file or directory > > Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [TRY-RECOMPILING] Try recompiling constants > 1: [RETRY ] Retry performing #<ASDF:COMPILE-OP NIL > {1003B23C31}> on > #<SB-GROVEL:GROVEL-CONSTANTS-FILE > "sb-posix" "constants">. > 2: [ACCEPT ] Continue, treating #<ASDF:COMPILE-OP NIL {1003B23C31}> > on > #<SB-GROVEL:GROVEL-CONSTANTS-FILE > "sb-posix" "constants"> > as having been successful. > 3: [ABORT ] Exit debugger, returning to top level. > > (SB-IMPL::SIMPLE-FILE-PERROR > "failed to find the TRUENAME of ~A" > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp" > 2) > 0] backtrace > > 0: (SB-IMPL::SIMPLE-FILE-PERROR > "failed to find the TRUENAME of ~A" > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp" > 2) > 1: ((FLET SB-IMPL::FAIL) > "failed to find the TRUENAME of ~A" > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp" > 2) > 2: (SB-IMPL::QUERY-FILE-SYSTEM > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp" > :TRUENAME > T) > 3: (TRUENAME > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp") > 4: ((FLET SB-C::TRY-WITH-TYPE) > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp" > "lisp" > T) > 5: (SB-C::VERIFY-SOURCE-FILE > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp") > 6: (SB-C::VERIFY-SOURCE-FILE > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp")[:EXTERNAL] > 7: (COMPILE-FILE > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp")[:EXTERNAL] > 8: ((SB-PCL::FAST-METHOD ASDF:PERFORM > (ASDF:COMPILE-OP SB-GROVEL:GROVEL-CONSTANTS-FILE)) > #<unavailable argument> > #<unavailable argument> > #<ASDF:COMPILE-OP NIL {1003B23C31}> > #<SB-GROVEL:GROVEL-CONSTANTS-FILE "sb-posix" "constants">) > 9: ((LAMBDA > (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. > SB-PCL::.ARG1.)) > #<unavailable argument> > #<unavailable argument> > #<ASDF:COMPILE-OP NIL {1003B23C31}> > #<SB-GROVEL:GROVEL-CONSTANTS-FILE "sb-posix" "constants">) > 10: ((SB-PCL::FAST-METHOD ASDF::PERFORM-WITH-RESTARTS > (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) > #<unavailable argument> > #S(SB-PCL::FAST-METHOD-CALL > :FUNCTION #<FUNCTION #> > :PV NIL > :NEXT-METHOD-CALL NIL > :ARG-INFO (2)) > #<ASDF:COMPILE-OP NIL {1003B23C31}> > #<SB-GROVEL:GROVEL-CONSTANTS-FILE "sb-posix" "constants">) > 11: ((LAMBDA ())) > 12: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) > 13: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]324)) > 14: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK > #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK) {7FFFF79AB6C9}> > #S(SB-THREAD:MUTEX > :NAME "World Lock" > :%OWNER #<SB-THREAD:THREAD "initial thread" RUNNING {1002AC20A1}> > :STATE 1)) > 15: ((FLET SB-C::WITH-IT)) > 16: ((SB-PCL::FAST-METHOD ASDF:OPERATE (T T)) > #<unavailable argument> > #<unavailable argument> > ASDF:LOAD-OP > :SB-POSIX)[:EXTERNAL] > 17: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF-LOAD :SB-POSIX) #<NULL-LEXENV>) > 18: (INTERACTIVE-EVAL (ASDF-LOAD :SB-POSIX))[:EXTERNAL] > 19: (SB-IMPL::REPL-FUN NIL) > 20: ((LAMBDA ())) > 21: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {1002EBD309}>) > 22: (SB-IMPL::TOPLEVEL-REPL NIL) > 23: (SB-IMPL::TOPLEVEL-INIT) > 24: ((LABELS SB-IMPL::RESTART-LISP)) > > 0] > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Sbcl-help mailing list > Sbcl-help(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sbcl-help >

3 3

[asdf-devel] create temporary Lisp files in fasl directory
by Robert Brown 06 Aug '10

06 Aug '10

I'm using ASDF to build an open source implementation of Google's protocol buffer data serialization library. The code is here: http://github.com/brown/protobuf I've defined a new component type that allows developers to include protobuf message definition files in their Lisp ASDF files: (defclass protobuf-source-file (cl-source-file) ((relative-proto-pathname ... ) (search-path ... ) (:documentation "A protocol buffer definition file.")) When used like this in a system definition: :components ((:protobuf-source-file "foo")) executing the ASDF:LOAD-OP operation causes the file called foo.proto to be translated into foo.lisp by a C++ program, and then compiled into foo.fasl and loaded. Note that foo.lisp is created in the same directory as the system definition, but I would prefer it to be created in the same directory as foo.fasl, which for me is in a subdirectory of ~/.cache/common-lisp. What's the easiest way to accomplish this? I initially tried overriding INPUT-FILES when applied to CL-SOURCE-FILE instances, but ASDF::PERFORM is defined like this: (defmethod perform ((operation compile-op) (c cl-source-file)) (let ((source-file (component-pathname c)) ... ) ... ) Since it calls COMPONENT-PATHNAME to find Lisp source, it will always look in the system definition directory. bob

3 4

Re: [asdf-devel] Performance hit in TRUENAMIZE
by Juan Jose Garcia-Ripoll 25 Jul '10

25 Jul '10

On Fri, Jul 16, 2010 at 12:54 AM, edgar <edgar-rft(a)web.de> wrote: > I think the main problem here is that some implementations > (notably CLISP) differ between files and directories, so > PROBE-FILE cannnot be used to probe files AND directories. Well, SBCL and ECL do not have that problem, AFAIK. But TRUENAMIZE also seems to be used with files, not directories, from what I could gather during the debugging of ASDF. I would abstract those calls into a function PROBE-FILE-AND-DIRECTORY and use PROBE-FILE internally in this function. The purpose would be clear and sensible implementations might profit from that -- maybe the terrible startup times for ASDF might be decreased this way. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

2 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel