asdf-devel February 2013

asdf-devel@common-lisp.net

15 participants
28 discussions

[asdf-devel] ASDF 2.30 released
by Faré 02 Mar '13

02 Mar '13

Dear Lisp hackers, ASDF 2.30 is another stability release in preparation for ASDF 3. Since 2.29, in addition to specific portability fixes for CCL and CMUCL, it notably restores some backward compatible behavior for syntax tables around loading .asd files, using mutable global tables, instead of standard syntax tables. Just like 2.29, 2.28 and 2.27 before it, ASDF 2.30 is a pre-release of ASDF 3, an almost complete rewrite of ASDF, and includes a vast number of improvements since ASDF 2.26. http://lists.common-lisp.net/pipermail/asdf-announce/2013-February/000014.h… We invite all implementation vendors to update to ASDF 2.30. We also invite all implementations to make the standard *readtable* and *print-pprint-dispatch* tables immutable, with useful error messages when a modification is attempted. See how the CLHS forbids conformant programs from modifying them: http://clhs.lisp.se/Body/26_glo_s.htm#standard_readtable http://clhs.lisp.se/Body/26_glo_s.htm#standard_pprint_dispatch_table Such modification can only result in problems down the line for users, and it would be nice if at least when SAFETY isn't 0, that were checked. In some unspecified future, we'd like to revert to ASDF 2.29's behavior of binding the syntax tables to their standard values, and then we hope that most implementations will immediately catch misguided attempts by users to modify them (SBCL is the only implementation enforced immutability on both tables). Many thanks to stassats and avodonosov for their help in testing ASDF and helping make it more robust, more portable and more backward compatible. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There is no reason ever to have the same thought twice, unless you like having that thought — David Allen, "Getting Things Done"

2 2

[asdf-devel] clearing output-translations for a "dumped" image
by Dave Cooper 01 Mar '13

01 Mar '13

Dear All, When "saving a world" (i.e. "dumping" an image, e.g. "dumplisp" in Allegro CL), which has asdf (and quicklisp) loaded in it, what is the proper way to clear the output-translations and any other local path residue from ending up in the saved image? That is, when a new user starts the image on a target machine, it should be forced to re-initialize the output-translations to the appropriate path for the new user (e.g. ~/.cache/common-lisp/... with respect to new user's home directory). -- 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

3 6

[asdf-devel] Test results on Mac OSX
by Robert Goldman 28 Feb '13

28 Feb '13

Just pulled from git this afternoon and reran the tests on ccl clisp sbcl ecl abcl allegro allegromodern * ECL 12.12.1 fails tests test-multiple.script test-run-program.script test-multiple: TEST ABORTED: Subprocess run with command "/bin/ln -sf /Users/rpg/lisp/asdf/test/test-multiple.asd /Users/rpg/lisp/asdf/build/test-multiple-too.asd 2>&1" exited with error code 1 No backtrace for this. TEST ABORTED: Subprocess run with command "echo ok 1" exited with error code 1 For test-run-program I see: exec: Too few arguments. TEST ABORTED: Subprocess run with command "echo ok 1" exited with error code 1 * ABCL 1.1.0.2 failed test-encodings: TEST ABORTED: These two expressions fail comparison with EQUAL: (STRING-CHAR-CODES "λ") evaluates to (338 170) (EXPECTED-CHAR-CODES (QUOTE :UTF-8)) evaluates to (955) Above backtrace due to this condition: These two expressions fail comparison with EQUAL: (ASDF-TEST::STRING-CHAR-CODES "λ") evaluates to (338 170) (ASDF-TEST::EXPECTED-CHAR-CODES (QUOTE :UTF-8)) evaluates to (955) Script failed * Allegro Modern 8.2 failed test-utilities with this error: TEST ABORTED: Package "ASDF/ACTION" not found. [file position = 3334] The problem is the defparameter for *ok-symbols*, which gives the symbol names in all caps. I am attaching a patch for this. Best, r

3 11

[asdf-devel] cl-growl and weakly-depends-on
by Faré 27 Feb '13

27 Feb '13

Dear Pat, I'd like to kill the evil that is :weakly-depends-on, and your cl-growl seems to be the only user of it in quicklisp. :weakly-depends-on is evil because it's non-deterministic, and what code you get depends on which order things were compiled or configured, and you can't fix things after the fact. Could you stop using it? Alternatives include having a separate system foo+bar that explicitly loads foo and bar before doing the connection, and/or using asdf-system-connections to automatically load foo+bar when both foo and bar have been loaded. I don't personally like this automatic loading, but at least it doesn't break determinism. As for allowing a system to run with or without another, that's what hooks are call, i.e. runtime configuration variables. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org So that there be reality, there must be an observer. "I am, therefore someone thinks." — Faré

2 2

[asdf-devel] strange interaction between ql:quickload and ASDF
by Anton Vodonosov 26 Feb '13

26 Feb '13

Hello. I have very strange behaviour of ql:quickload that I observer only on ABCL. It happens when I run (ql:quickload :modf). Precondition: the system :modf is NOT installed into quicklisp. > java -jar abcl.jar --noinit --nosystem Armed Bear Common Lisp 1.1.0 Java 1.6.0_26 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.945 seconds. Startup completed in 4.8 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "C:\\Users\\anton\\quicklisp\\setup.lisp") T CL-USER(2): (ql:quickload :modf) Error loading C:/Users/anton/quicklisp/dists/quicklisp/software/closer-mop-20130128-darcs/closer-mop.asd at line 43 (offset 1649) #<THREAD "interpreter" {40773F4B}>: Debugger invoked on condition of type LOAD-SYSTEM-DEFINITION-ERROR Error while trying to load definition for system closer-mop from pathname C:/Users/anton/quicklisp/dists/quicklisp/software/closer-mop-20130128 -darcs/closer-mop.asd: Unrecognized keyword argument ("closer-mop-packages" "closer-mop-shared") Restarts: 0: REINITIALIZE-SOURCE-REGISTRY-AND-RETRY Retry finding system closer-mop after reinitializing the source-registry. 1: ABORT Give up on "modf" 2: TOP-LEVEL Return to top level. [1] ASDF0(3): As you see it is trying to load closer-mop. Why? If :modf ASDF is not available, quicklisp should not load anything other systems yet. Moreover, modf.asd has :depends-on (:alexandria #-abcl :closer-mop :iterate) So on ABCL it does not depend on closer-mop. I got backtrace using this command: [1] ASDF0(3): (with-open-file (stream "C:\\Users\\anton\\unpacked\\abcl\\abcl-bin-1.1.0\\backtrace.txt" :direction :output :if-exists :supersede :if-does-not-exist :create) (let ((*debug-io* stream)) (top-level::backtrace-command "10000"))) The resulting file is here: https://dl.dropbox.com/u/5708042/backtrace.txt. @abcl dvelopers: this backtrace seem to contain not only the current invocation stack, but also previous calls, already finished. For example the (LOAD "C:\\Users\\anton\\quicklisp\\setup.lisp") at the very bottom of the file. Do I retrieve backtrace incorrectly? Back to the ql:quickload problem. I know that if I install :modf with CCL, this problem doesn't happen anymore, and ABCL can load it. Zach, how it works? Best regards, - Anton

1 2

Re: [asdf-devel] Chat with Anton Vodonosov
by Faré 26 Feb '13

26 Feb '13

Anton Vodonosov was kind enough to run cl-test-grid against ASDF 2.29, and here are the results, which I'm sharing with the asdf-devel list because some people might find this status informative. > I am thinking to add backtraces. Wasn't sure how (to depend > on some library like trivial-backtrace, but what if the library itself > is broken on the given lisp; or maybe copy/paste code to cl-test-gird; > did't know about asdf/driver, alghtouhg it will only work on the lates > ASDF). I will solve it somehow. Meantime it is necessary to reproduce > the problem manually. > At worst, you could copy/paste and simplify code from asdf/image. I already merged in code from xcvb-driver and trivial-backtrace, so it should work in more cases. And if you add implementations, please contribute them to asdf/image. >> Where are the SBCL results? > > At the same table, at the bottom part. If you want, here is > a separate SBCL-only table: > http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-11-sbcl.html > Oh, sorry. Thanks. unicly: encoding problem. I wonder why it doesn't appear with other run — are you using an ASCII locale where you were using UTF-8 before? I should really make UTF-8 the default default at some point, but let's fix the other issues first. iolib, and through it scriptl, inotify, hemlock.base, dbus, cl-ws, clonsigna, clavatar, cl-popen: ouch, iolib modifies the readtable in the .asd file. That's nasty, and is broken by my recent use of with-standard-io-syntax around loading .asd files. I temporarily removed that wrapper in 2.29.2 until all clients are fixed, but clients should definitely get fixed. Upstream errors, need to contact the respective upstream authors if not done already: jwacs, netkthuth, meta-sexp: bad :version vs less forgiving asdf xcvb-bridge: fixed upstream already. weblocks: they are missing some dependencies in their .asd files. I sent them a patch, I think they applied it in the end, but not sure. qbook: sent patch upstream some time ago, no answer. mime4cl: bad use of defconstant for a list, caught by sbcl. Not an ASDF-specific issue. metacopy-with-contextl: the .asd file has an ugly output-files :around method that expects only one output file when there are now several. jenkins.api: has version requirements on all dependencies, but iterate doesn't have a version to compare to 1.4.4 cl-sam: has a version dependenceny on cffi 0.10.3, but latest cffi doesn't sport a version number deoxybytes-*, cl-prolog: WFM. Maybe it's looks like it's been fixed by 2.29.1??? Or maybe you're actually using 2.28.10?? This looks more like the bug I fixed in 2.28.11 aka 2.29. buildapp: needs to be updated for ASDF3 (specialization of previous unexported traverse function without &key) I'm adding the "contacting upstream errors" on my TODO list. I'm just telling Stelian for now that though I'm adding back compatibility with modifying the readtable within a .asd file, this is strongly frowned upon and we need a different solution, possibly using named-readtables. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It’s amazing that the amount of news that happens in the world everyday always just exactly fits the newspaper.

3 24

[asdf-devel] Mac OSX test upgrade status
by Robert Goldman 26 Feb '13

26 Feb '13

I got through almost all the upgrade tests before failing with allegromodern trying to upgrade from 1.85: ; registering #<system :asdf @ #x1000afe932> as asdf ; Fast loading /Users/rpg/lisp/asdf/build/asdf.fasl TEST ABORTED: Attempt to fast load a non-fasl file: #P"/Users/rpg/lisp/asdf/build/asdf.fasl" Script failed upgrade FAILED for allegromodern from 1.85 using method 'load-asdf-lisp'load-asdf-system I can see why this fails! When I look at ~/lisp/asdf/build/asdf.fasl in emacs I see this: #!/usr/local/bin/sbcl --script # FASL compiled from "/Users/rpg/lisp/asdf/build/asdf.lisp" using SBCL version 1.1.3.7-63e78fc which suggests to me that we may be leaking something from one test to another... best, r

2 3

[asdf-devel] standard io syntax woes
by Faré 26 Feb '13

26 Feb '13

Dear Common Lisp hackers, Inspecting with Anton Vodonosov the latest batch of cl-test-grid issues when running with asdf 2.29.x, we found an interesting case that mirrors the previous failure of iolib 0.7.3 with 2.29. In the hope of making the semantics of asd files more deterministic, with an eye on eventually making .asd files a strict subset of Lisp, I had put in 2.27 a with-standard-io-syntax around the loading of a .asd file. However, this is specified to bind *readtable* and *print-pprint-dispatch* to standard tables that are notionally read-only, though this immutability is NOT enforced on most implementations, instead there being unspecified bad consequences if you do mutate. So, I could conceivably (copy-readtable nil) and (copy-pprint-dispatch nil) every time, but that could be expensive on some implementations. Or I could say "it's the programmer's responsibility to ensure a proper table has been setup before he modifies it", but that would be harsh and a notable backward incompatibility (and there's no equivalent of named-readtables for pprint-dispatch). Or I could preserve the current semantics of a global table that everyone modifies causing "interesting" issues, by rebinding *print-pprint-dispatch* as well as *readtable* within the w-s-i-s, only ensuring that the other syntax variables are standard. Or I could remove the with-standard-io-syntax altogether, and say "yes, if you're doing any global modification, you suck and you're going to break something for someone, but that's none of my business". Anton leans for the latter. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org One can be so anxious to put his "best foot forward" that he doesn't even notice that it isn't his own foot. — Harry Browne (HIFFIAUW)

7 12

[asdf-devel] Failures due to deferred warnings
by Faré 22 Feb '13

22 Feb '13

When we enable the checking of deferred warnings, the following 57 systems have issues. Now to contact the authors. Then of course, there are all the style-warnings that we are ignoring, but oh well. s-xml mcclim cl-csv clsql-helper lisp-on-lines regex zlib cl-mediawiki cl-neo4j cleric coleslaw com.informatimago.common-lisp.parser diff gdl-ta2 lispbuilder-regex marching-cubes mgl odd-streams open-vrp-lib pg prepl webactions xmls-tools adw-charting-vecto cl-azure cl-containers-test cl-fluiddb-test cl-fsnotify cl-gdata cl-graph-test cl-markdown-test cl-memcached cl-pdf-doc cl-protobufs-tests cl-quakeinfo cl-randist cl-redis clack-handler-hunchentoot clunit com.informatimago.linc com.informatimago.xcode computable-reals dcm elephant-tests hh-web json-template kanren-trs-test km lift-test lucene-in-action-tests parseltongue postoffice spinneret trivial-timeout-test weblocks-demo weblocks-demo-popover wilbur —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Justice is not concerned with the results of the various transactions but only with whether the transactions themselves are fair. — F.A. Hayek, "Law, Legislation and Liberty", I.6.j

4 10

[asdf-devel] asdf 2.30.2, (upgrage?) problem on ECL
by Anton Vodonosov 22 Feb '13

22 Feb '13

I decided to continue testing on other lisps. On ECL bytecode compiler there is a problem: /home/testgrid/lisps/ecl-bin-12.12.1/bin/ecl -norc -eval '(ext::install-bytecodes-compiler)' -eval '(LOAD #P"/home/testgrid/quicklisp-patched2/setup.lisp")' (ql:quickload :alexandria) Condition of type: UNDEFINED-FUNCTION The function ASDF/SYSTEM:FIND-SYSTEM is undefined. Available restarts: 1. (ABORT) Give up on "alexandria" 2. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at QUICKLISP-CLIENT::RECURSE. In: #<process TOP-LEVEL>. File: (1 . #P"/home/testgrid/quicklisp-patched2/quicklisp/setup.lisp") (Position #2087)

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel February 2013