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

[asdf-devel] Messages are a bit uglier now
by Zach Beane 24 Mar '11

24 Mar '11

Sorry for not following the line wrapping discussion earlier. Now that I've had a chance to build some systems, the new output looks a bit ugly to me. Here's how 2.010 looked: * (asdf:load-system "my-very-long-system-woo-hoo") ; loading system definition from ; /home/xach/src/asdf/my-very-long-system-woo-hoo.asd into #<PACKAGE "ASDF0"> ; registering #<SYSTEM #:MY-VERY-LONG-SYSTEM-WOO-HOO> as ; MY-VERY-LONG-SYSTEM-WOO-HOO T Here's how 2.013.4 looks: * (asdf:load-system "my-very-long-system-woo-hoo") ; Loading system definition from /home/xach/src/asdf/my-very-long-system-woo-hoo.asd into #<PACKAGE "ASDF0"> ; Registering #<SYSTEM #:MY-VERY-LONG-SYSTEM-WOO-HOO> as MY-VERY-LONG-SYSTEM-WOO-HOO T I thought it might be improved by setting *print-pretty* to nil, but that still produces this: * (asdf:load-system "my-very-long-system-woo-hoo") ; Loading system definition from /home/xach/src/asdf/my-very-long-system-woo-hoo.asd into #<PACKAGE "ASDF0"> ; Registering #<SYSTEM #:MY-VERY-LONG-SYSTEM-WOO-HOO> as MY-VERY-LONG-SYSTEM-WOO-HOO T It looks like there are extra blank lines before each message. In case your mail client makes the wrapping look weird, I also pasted these examples at http://paste.lisp.org/display/120843/raw. I really prefer the older output. If the newer output is kept, it would be nice if the extra blank lines could be eliminated. Thanks, Zach

3 4

[asdf-devel] Didn't you fix this bug?
by Robert Goldman 23 Mar '11

23 Mar '11

I believe you have already not just committed, but released, a fix, and we also have a test now. https://bugs.launchpad.net/asdf/+bug/732317 Want to clear this (credit where credit is due)? If you don't have time, drop me a line, and I can. cheers, r

1 0

[asdf-devel] Status of :feature
by Didier Verna 23 Mar '11

23 Mar '11

Hello, what is the current status of :feature in a list of dependencies? I mean, is it safe to replace #+ reader conditionals in the asd file with it? Thanks. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

3 2

[asdf-devel] Compiling ASDF and style warnings.
by Douglas Crosher 22 Mar '11

22 Mar '11

The file test/compile-asdf.lisp catches compiler style warnings to avoid them being counted. However this would not appear to be necessary as the third result of 'compile-file would seem to be just what is needed to catch warnings (excluding style-warnings) and errors. Many CL implementations have style-warning handlers that show useful context and it would seem better to just leave it to the implementation to handle. Possible patch attached. Regards Douglas Crosher

2 1

[asdf-devel] ASDF 2.013 released
by Faré 22 Mar '11

22 Mar '11

Dear ASDF developers, I posted the announcement for ASDF 2.013 on asdf-announce, and I see that almost no one is subscribed. Should I subscribe asdf-devel? Or Cc: it to the announcements? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Committee, n.: A group of men who individually can do nothing but as a group decide that nothing can be done. — Fred Allen ---------- Forwarded message ---------- From: Faré <fahree(a)gmail.com> Date: 20 March 2011 00:29 Subject: ASDF 2.013 released To: asdf-announce(a)common-lisp.net Dear Common Lisp Users, I just blessed ASDF 2.012.12 as 2.013. It includes many small improvements since previous release, for portability, robustness, usability. For the sake of making these improvements available to all users, I invite all vendors and packagers to update their software to include this latest release. Improvements since 2.012: * Fixes and cleanups for CLISP, ECL, SBCL. * Added support for two legacy platforms: (R)MCL, Genera * Cleanup features: now using #+asdf-unix and #+asdf-window * Many cleanups and improvements regarding our portable pathname layer * Fixes a regression in source-registry scanning from 2.011.4 * Remember *source-registry-parameter* and *output-translations-parameter* * Export and document coerce-pathname (f.k.a merge-component-name-type) * allow description and long-description for all components * Several documentation updates Happy hacking, [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I hold that America, Champion of the World is a betrayal of its humble beginnings as One Nation Underdog.

3 3

[asdf-devel] About asdf:*compile-file-failure-behaviour* and its value on SBCL
by Chun Tian (binghe) 20 Mar '11

20 Mar '11

Hi, ASDF developers I think asdf:*compile-file-failure-behaviour* should never been set to :error, just :warn is good. CLHS [1] said about COMPILE-FILE's 2nd and 3rd return values: "The secondary value, warnings-p, is false if no conditions of type error or warning were detected by the compiler, and true otherwise. "The tertiary value, failure-p, is false if no conditions of type error or warning (other than style-warning) were detected by the compiler, and true otherwise." This means, any warnings other than style-warning will cause COMPILE-FILE return T on its third return value. Than every Lisp file which contains a general (WARN "...") form, when compiling, will cause COMPILE-FILE return T on its third return value, and therefore was marked as "failure" (by ASDF). In current asdf.lisp, asdf:*compile-file-failure-behaviour* was defined as follow: (defvar *compile-file-failure-behaviour* (or #+sbcl :error #+clisp :ignore :warn) "How should ASDF react if it encounters a failure (per the ANSI spec of COMPILE-FILE) when compiling a file? Valid values are :error, :warn, and :ignore. Note that ASDF ALWAYS raises an error if it fails to create an output file when compiling.") I don't know why SBCL here is special, but this definition caused my project (cl-net-snmp 6.0) failed to be compiled by ASDF "only" on SBCL. Just try to put following lines in your ASDF based project and try to build it: (eval-when (:compile-toplevel) (warn "xxx")) you'll find how ludicrous the current setting of asdf:*compile-file-failure-behaviour* are. Regards, Chun Tian (binghe) [1] http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm#compile-…

4 7

[asdf-devel] 2.013 later this week
by Faré 18 Mar '11

18 Mar '11

Dear ASDF users, unless you have requests for urgent bugs and/or object to some of the changes I just made (see below), I intend to release 2.013 later this week. Changes since 2.012: * cleanup in use of features. Introducing #+asdf-unix and #+asdf-window. (2.012.1) * cleanup in support for clisp. Implementation identifier vs processor name (2.012.2) * support for Digitool's legacy system (R)MCL (2.012.3) - as requested by p-cos to test his library. * cleanup when using portable pathnames (2.012.4) * cleanup in support for ECL (2.012.5, 2.012.6) * parse the pathname of a defsystem portably when it's a string. (2.012.7) * support for Symbolics' legacy system Genera (2.012.8) - proof of concept, completes legacy support and allowed me to test my libraries. * support for .. as :back in our portable pseudo-namestring language and in merge-pathnames* - should make quite a few pathnames things less ugly. (2.012.8) * Remember source-registry and output-translations parameters (2.012.8) - should provide a portable solution to the need many people have expressed to be able to tweak a configuration after the fact. * some documentation updates Possibly questionable change: * To support Genera, I removed ~@< from our error message format strings. Frankly, I think cuteness matters that much when printing error. Feedback requested: * are the (currently unexported) variables *source-registry-parameter* and *output-translations-parameter* acceptable APIs for reconfigurability of ASDF? If so, I'll export them before release. If not, I'd appreciate API proposals, if possible from people who understand how current code works. ASDF is pretty stable, and we're really polishing corner cases, but also making some [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Give up all hope for a better yesterday, even a better just now. Never give up hope for a better tomorrow. — Patri Friedman

4 13

[asdf-devel] ASDF2: run-shell-command for clisp: what is the correct :output?
by Mirko Vukovic 22 Feb '11

22 Feb '11

Hello, The asdf:run-shell-command for clisp is specified to use the output as terminal. That makes its output unavailable to clisp. Instead, one should have something like this: (read (ext:run-shell-command command :output :stream :wait t)) I am cross-posting this to the clisp mailing list. Folks there know much more about this than I do. Mirko

2 1

[asdf-devel] Minor simplification
by Juan Jose Garcia-Ripoll 06 Feb '11

06 Feb '11

Right now there are hooks in ASDF which are used by ECL in a perhaps too complicated way. More precisely, ECL requires to make an object file and a FASL file out of every compiled file, so that other operations (LOAD-FASL-OP, monolithic building, standalone executables, etc) become easier. Right now this is done using an :AFTER method on PERFORM. I suggest this patch (already in ECL's tree) which removes that method, removes the upgradability hacks and insteads wraps around COMPILE-FILE* (which now becomes redefinable at run time). Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

3 14

[asdf-devel] Issues with logical pathnames in Allegro and clisp
by Pascal Costanza 25 Jan '11

25 Jan '11

Hi, I have encountered two more issues when trying to use ASDF 2 with logical pathnames in Allegro and clisp. I have the following logical pathname translations in Allegro and clisp respectively: #+allegro (setf (logical-pathname-translations "costanza") `(("**;*.fasl.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.fasl" (lisp-implementation-type) (read-from-string (lisp-implementation-version)))) ("**;*.*.*" "/Users/costanza/**/*.*"))) #+clisp (progn (setq custom:*parse-namestring-ansi* t) (setf (logical-pathname-translations "costanza") `(("**;*.lib.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.lib" (lisp-implementation-type) (read-from-string (lisp-implementation-version)))) ("**;*.fas.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.fas" (lisp-implementation-type) (read-from-string (lisp-implementation-version)))) ("**;*.*.*" "/Users/costanza/**/*.*")))) When compiling systems with ASDF, however, the fasl, lib and fas files don't end up in the folders designated by these logical pathname translations, but rather in the locations as specified with ASDF output translations. (In CMUCL, Clozure, ECL, LispWorks, RMCL, and SBCL, similar logical pathname translations work as expected.) I have not defined any ASDF output translations of my own, but I'm using quicklisp, which probably does this. Please let me know if I can do something to help fixing this problem. Thanks, Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium

3 6