Re: [asdf-devel] Chat with Anton Vodonosov
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.
18.02.2013, 15:13, "Faré" <fahree@gmail.com>:
Anton Vodonosov:
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.
Done so
And if you add implementations, please contribute them to asdf/image.
Sure
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?
No, it was run with ASCII both times. The difference turns out is :verbose t passed into (ql:quickload). I reproduced it manually: rm -r ~/.cache/common-lisp/ ~/lisps/sbcl-1.1.1-bin/run.sh --no-sysinit --no-userinit --load quicklisp-patched2/setup.lisp (ql:quickload :unicly) works, while rm -r ~/.cache/common-lisp/ ~/lisps/sbcl-1.1.1-bin/run.sh --no-sysinit --no-userinit --load quicklisp-patched2/setup.lisp (ql:quickload :unicly :verbose t) fails. As I see in the Quicklisp sources, The :verbose nil binds some variables like cl:*load-verbose* and invokes cl:muffle-warning restart from handler-bind. Probably this interferes somehow with ASDF.
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.
No, it was definetely tested with 2.29: $ head -n 2 quicklisp-patched2/asdf.lisp ;;; -*- mode: Common-Lisp; Base: 10 ; Syntax: ANSI-Common-Lisp -*- ;;; This is ASDF 2.29: Another System Definition Facility. I reproduce it 100%: ~/lisps/sbcl-1.1.1-bin/run.sh --no-sysinit --no-userinit --load quicklisp-patched2/setup.lisp (ql:quickload :cl-prolog)
mime4cl: bad use of defconstant for a list, caught by sbcl. Not an ASDF-specific issue.
True. I also want to clarify why the failure didn't shown in the previous run. If we repeat the (ql:quickload :mime4cl) several times it finally works. (I guess it's because at every invocation some .fasl files are saved successfully before defconstant error occurs, so finally all the .fals are compiled and load proceeds without errors). During test run mime4cl is loaded several times because there are libraries depending on it. But because of other library failures, the number of mime4cl attempts in the second test run is less then in the first test run, therefore we see it failing. If remaining libraries are upstream errors, we can perform another test run with 2.29.2 to see ensure we have no other errors, and the checkout these libraries to quicklisp/local-projects and test again to ensure they are fixed upstream.
On Tue, Feb 19, 2013 at 9:08 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
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?
No, it was run with ASCII both times. The difference turns out is :verbose t passed into (ql:quickload). [...]
As I see in the Quicklisp sources, The :verbose nil binds some variables like cl:*load-verbose* and invokes cl:muffle-warning restart from handler-bind. Probably this interferes somehow with ASDF.
Oh. Then it's not an ASDF issue, and the issue should be there using old versions of ASDF, too, whenever quickload is verbose and doesn't muffle these warnings. The real solution is to use UTF-8. Which reminds me, we should test with (setf asdf:*default-encoding* :utf-8) at some point, and also without (setf asdf:*warnings-file-type* nil).
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.
No, it was definetely tested with 2.29:
The mind boggles. Oh well, as long as the bug is gone with the latest ASDF, that should be fine.
If remaining libraries are upstream errors, we can perform another test run with 2.29.2 to see ensure we have no other errors, and the checkout these libraries to quicklisp/local-projects and test again to ensure they are fixed upstream.
I've contacted all upstream authors for the previously found bugs. Only a few did respond already. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There are three types of people in the world; those who can count, and those who can't.
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?
No, it was run with ASCII both times. The difference turns out is :verbose t passed into (ql:quickload). [...]
As I see in the Quicklisp sources, The :verbose nil binds some variables like cl:*load-verbose* and invokes cl:muffle-warning restart from handler-bind. Probably this interferes somehow with ASDF.
No, it's not interfering with ASDF. IIUC, you'd have have the failure with :verbose t on an old ASDF, too. It's just SBCL complaining that there's a non-ASCII character in comments; but since it's only in a comment, that's a style-warning that quicklisp ignores when non-verbose. The solution is that this system should be loaded as UTF-8. At some point, let's experiment with (setf asdf:*default-encoding* :utf-8) and see what breaks. Also without disabling *warnings-file-type*.
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.
No, it was definetely tested with 2.29:
OK. Well, is it working with 2.29.6?
If remaining libraries are upstream errors, we can perform another test run with 2.29.2 to see ensure we have no other errors, and the checkout these libraries to quicklisp/local-projects and test again to ensure they are fixed upstream.
Yes. I've contacted all upstream authors. Some have fixed things already, others haven't responded yet. Thanks a whole lot once again for your help testing! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org drug, n: A substance that, injected into a rat, produces a scientific paper.
I have yestereday run tests for 2.29.5: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-12.html The logs contains backraces now, but I didn't noticed that I print backraces from handler-case, so this time the backtraces show unwound stack, without usefull information. Fixed in cl-test-grid, so in the future the backtraces will be printed from handler-bind. We have reviewed the SBCL results. Faré found that cl-prolog and deoxybyte problems are also upstream errors. So the table entry for SBCL are explained as: - unicly: not a regressions, but an effect of using (ql:quickload .. :verbose t) - mime4cl: not a regression, bad defconstant, fails/succeeds depending on how many times it is rebuild - f2cl (lapack CRASH): old known issue with SBCL - runs out of heap Others are upstream errors in corresponding libraries: - deoxybytes-*: upstream errors (due to old operation-done-p method defined in deoxybyte to workaround some ASDF1 issue) - cl-prolog: upstream errors (due to old operation-done-p method defined in deoxybyte to workaround some ASDF1 issue) - buildapp: needs to be updated for ASDF3 (specialization of previous unexported traverse function without &key) - cl-sam: has a version dependenceny on cffi 0.10.3, but latest cffi doesn't sport a version number - jenkins.api: has version requirements on all dependencies, but iterate doesn't have a version to compare to 1.4.4 - jwacs: bad :version vs less forgiving asdf - meta-sexp: bad :version vs less forgiving asdf - metacopy-with-contextl: the .asd file has an ugly output-files :around method that expects only one output file when there are now several. - netkthuth: bad :version vs less forgiving asdf - qbook: sent patch upstream some time ago, no answer. - 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. - xcvb-bridge: fixed upstream already. What does these tests resutls mean? That of 1083 ASDF system I was able to ql:quickoad on my linux system with SBCL 1.1.1 and quicklisp 2013-01-28, I can ql:quickoad all of them except for the described above upstream errors on quicklisp 2013-01-28 + ASDF 2.29.5 with patched asdf-system-connections and (setf asdf:*warnings-file-type* nil) - this disables new ASDF3 deferred warnings processing. So, as for SBCL the tests reveal no work to be done in ASDF itself; authors of some libraries need to apply suggested fixes. I suggest that we review CCL results, and then run the tests on other lisp implementations. Additionally we will run tests with deffered warnings enabled to see what systems are affected. And also with utf8 as the default encoding, for the same reason. Best regards, - Anton
20.02.2013, 20:28, "Anton Vodonosov" <avodonosov@yandex.ru>:
That of 1083 ASDF system I was able to ql:quickoad on my linux system with SBCL 1.1.1 and quicklisp 2013-01-28, I can ql:quickoad all of them except for the described above upstream errors on quicklisp 2013-01-28 + ASDF 2.29.5 with patched asdf-system-connections and (setf asdf:*warnings-file-type* nil) - this disables new ASDF3 deferred warnings processing.
To clarify, the said asdf-system-connections fix is applied to the library git repo at Feb 10, 2013, thus it must be already in quicklisp.
20.02.2013, 20:28, "Anton Vodonosov" <avodonosov@yandex.ru>:
I have yestereday run tests for 2.29.5: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-12.html
Together with Faré we reviewd the CCL entries in this table. Some of the just repeat the upstream errors we considered on SBCL: - cl-prolog - cl-sam, deoxybyte-* -- author contacted - jwacs* -- author contacted - meta-sexp -- author contacted - metacopy-with-contextl -- just fixed upstream - qbook -- just fixed upstream - simple-blog - weblocks-prevalence (sbcl says "no package weblocks", while ccl says "no package weblocks-memory", but this is just different order of iteration over symbols) -- author contacted - xcvb-bridge -- fixed upstream some time ago already Others are either upstream errors or not real regressions: - (LOAD clem-benchmark TIMEOUT) - not a regression, it just takes long (it actually runs some benchmarks during asdf:load-op) - (LOAD clpython FAIL) - tries to redefine asdf::traverse, upstream maintainer was notified - (LOAD irc-logger FAIL) - got into the report becuase we use now (ql:quickload ... :verbose t) - (LOAD hu.dwim.reiterate FAIL) - got into the report because we use now(ql:quickload ... :verbose t) - upstream was notified - (LOAD defdoc FAIL) - cuased by nst - (LOAD userial-tests FAIL) - caused by nst - (LOAD nst FAIL) result of with-standard-io-syntax around asdf:load-asd in asdf3 and the fact that nst tries to modify ppring-dispatch table. On ccl 1.8 it results in error, as the table is readonly during with-standard-io-syntax. - (LOAD teepeedee2 FAIL) - (LOAD teepeedee2-test FAIL) Not a regression, may also be reproduced with old ASDF. Happens because teepeedee2 contains its own version of alexandria, where alexandria:format-symbol doesn't convert it's argument to string; this breaks babel. Opened an issue - https://github.com/vii/teepeedee2/issues/4 - (LOAD xcvb-test FAIL) - just fixed upstream Best regards, - Anton
Comparision for building with (setf asdf:*default-encoding* :utf-8): http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-14.html
On Thu, Feb 21, 2013 at 6:44 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
Comparision for building with (setf asdf:*default-encoding* :utf-8): http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-14.html
Wow, it's all positive! Not that surprising, when you think about it. Maybe I should just do it, and change the default. I've been warning people for a year already. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Future scholars will only have copies of copies of copies of manuscripts. How will they authenticate what really WAS said in our dark ages?
On Thu, 2013-02-21 at 08:00 -0500, Faré wrote:
On Thu, Feb 21, 2013 at 6:44 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
Comparision for building with (setf asdf:*default-encoding* :utf-8): http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-14.html
Wow, it's all positive! Not that surprising, when you think about it.
Maybe I should just do it, and change the default. I've been warning people for a year already.
Go ahead, please. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
21.02.2013, 17:27, "Stelian Ionescu" <sionescu@cddr.org>:
On Thu, 2013-02-21 at 08:00 -0500, Faré wrote:
On Thu, Feb 21, 2013 at 6:44 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
Comparision for building with (setf asdf:*default-encoding* :utf-8): http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-14.html Wow, it's all positive! Not that surprising, when you think about it.
Maybe I should just do it, and change the default. I've been warning people for a year already.
Go ahead, please.
I also support making :utf-8 the default. It will only improve stability, without any harm. Even if someone wants to use some incomatible encoding (but I doubt such people exist, let's say probability of their existence is 0.01), they can always specify :defsystem-depends-on :asdf-encodings :encoding :koi8-r That's 0.5 hour per ASDF system. 0.01 * 0.5 is nothing comparig to how many existing systems will build reliably. In the current situation when source file encoding is environment dependent, the defeloper is often is just unaware that hist ASDF system will not build on other computer.
OK, I've been convinced by that 100% positive cl-test-grid improvement, and starting with ASDF 2.30.1, :utf-8 is the default value of *default-encoding* (and 2.30.2 enforces the new default when upgrading while preserving non-:default overrides). Now to resurrect, update and process https://github.com/orivej/asdf-encodings/wiki/Tracking-non-UTF-8-lisp-files-... Grepping through quicklisp finds offending files in the following directories, whether or not they block a clean build: antik-20120909-git binary-types-20101006-git bknr-web-20130128-git cells-20120909-git cl-bibtex-20120909-cvs cl-pdf-20120909-svn cl-png-0.6 cl-typesetting-20120407-svn clfswm-20130128-git clsql-20130128-git def-symbol-readmacro-20130128-hg genworks-gdl-20130128-git lispbuilder-20120909-svn mcclim-20120909-cvs metatilities-20101006-darcs montezuma-20121013-git phemlock-20120909-cvs plain-odbc-20120909-svn utils-kt-20101006-git —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Taxonomy is the death of science — A. N. Whitehead On Thu, Feb 21, 2013 at 8:40 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
21.02.2013, 17:27, "Stelian Ionescu" <sionescu@cddr.org>:
On Thu, 2013-02-21 at 08:00 -0500, Faré wrote:
On Thu, Feb 21, 2013 at 6:44 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
Comparision for building with (setf asdf:*default-encoding* :utf-8): http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-14.html Wow, it's all positive! Not that surprising, when you think about it.
Maybe I should just do it, and change the default. I've been warning people for a year already.
Go ahead, please.
I also support making :utf-8 the default. It will only improve stability, without any harm.
Even if someone wants to use some incomatible encoding (but I doubt such people exist, let's say probability of their existence is 0.01), they can always specify
:defsystem-depends-on :asdf-encodings :encoding :koi8-r
That's 0.5 hour per ASDF system.
0.01 * 0.5 is nothing comparig to how many existing systems will build reliably. In the current situation when source file encoding is environment dependent, the defeloper is often is just unaware that hist ASDF system will not build on other computer.
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
OK, so I contacted each and every maintainer for the systems with warnings, and already got a few of them fixed. Now to test the systems enabled by UTF-8, and see if any have warnings. Anton, can you make a run with ASDF 2.26 + utf-8, then a run with ASDF 2.29 + utf-8 + warnings, so we can see the difference? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is deplorable that many people think that the best way to improve the world is to forbid something. However, they're morally more advanced than the people who think the best way to improve the world is to kill somebody. — John McCarthy (:individual-authors (("James Anderson <james.anderson@setf.de>" de.setf.wilbur) ("Gary King <gwking@metabang.com>" trivial-timeout asdf-system-connections lift lift-test cl-containers-test cl-graph-test) ("Paul Rodriguez <pmr@ruricolist.com>" spinneret) ("Alejandro Sedeno <asedeno@gmail.com>" cl-protobufs cl-protobufs-tests) ("Kevin Rosenberg <kmr@debian.org>" postoffice) ; not Orivej Desh <orivej@gmx.fr>'s updated but incomplete fork ("Vincent Toups <vincent.toups@gmail.com>" parseltongue) ;; fixed ("Leslie Polzer <leslie.polzer@gmx.net>" montezuma) ("Alan Oursland <alan.oursland@gmail.com>" km) ("Ryan Davis <ryan@acceleration.net>" cl-csv cl-mediawiki adw-charting) ("Drew Crampsie <drew.crampsie@gmail.com>" lisp-on-lines) ;; obsolete ("Robert Marlow <bobstopper@bobturf.org>" xmls-tools) ("Pascal J. Bourguignon <pjb@informatimago.com>" com.informatimago.linc com.informatimago.xcode com.informatimago.parser) ("Robert Smith <quadricode@gmail.com>" computable-reals) ("Dave Cooper <david.cooper@genworks.com>" gdl-ta2) ("Tapiwa Gutu <tapiwa.gutu@gmail.com>" clunit) ;; fixed ("Brit Butler <redline6561@gmail.com>" coleslaw) ;; fixed ("Nathan Froyd <froydnj@gmail.com>" diff) ("Michael Weber <michaelw+clawk@foldr.org>" regex) ;; both deferred-warnings failure and UTF8 issue, original author Michael Parker not active anymore. ;; should merge with lispbuilder-regex ? ("Gabor Melis <mega@retes.hu>" mgl) ;; fixed ("Masayuki Takagi <kamonama@gmail.com>" marching-cubes) ("Marc Kuo <kuomarc2@gmail.com>" open-vrp-lib) ("David Lichteblau <david@lichteblau.com>" prepl) ("Holger Dürer <H.Duerer@gmx.net>" cl-fluiddb-test) ;; codemonkey@betareduction.info ? ("Rob Blackwell <rob.blackwell@robblackwell.org.uk>" cl-azure) ("Chris Howey <chris@howey.me>" cl-fsnotify) ("Elias Martenson <lokedhs@gmail.com>" cl-gdata) ("Marc Battyani <marc.battyani@fractalconcept.com>" cl-pdf-doc) (("Eitarow Fukamachi <e.arrows@gmail.com>" "Julien Danjou <julien@danjou.info>") clack-handler-hunchentoot) ("Eitarow Fukamachi <e.arrows@gmail.com>" cl-memcached) ("Vsevolod Dyomkin <vseloved@gmail.com>" cl-redis) ;; fixed ("Leonardo Varuzza <varuzza@gmail.com>" cl-randist) ("Kevin Layer <layer@franz.com>" cl-quakeinfo) ) :mailing-lists (("mcclim-devel@common-lisp.net" mcclim) ("zlib-devel@common-lisp.net" zlib) ("clsql@b9.com" clsql) ;; fixed ("cleric-devel@common-lisp.net" cleric) ("cl-neo4j-devel@common-lisp.net" cl-neo4j) ;; fixed ("cl-kanren-trs-devel@common-lisp.net" cl-kanren-trs) ("elephant-devel@common-lisp.net" elephant dcm) ("pg-devel@common-lisp.net" pg) ("opensource@franz.com" webactions) ))
21.02.2013, 20:55, "Faré" <fahree@gmail.com>:
OK, so I contacted each and every maintainer for the systems with warnings, and already got a few of them fixed. Now to test the systems enabled by UTF-8, and see if any have warnings.
Anton, can you make a run with ASDF 2.26 + utf-8, then a run with ASDF 2.29 + utf-8 + warnings, so we can see the difference?
2.26 vs 2.29? You mean 2.29 in both cases I believe. We already have asdf.2.29.5-utf8-no-warn, so we only need to perform asdf.2.29.5-utf8. Will start do now.
Results for ECL, lisp-to-c compiler: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-16.html Most of the systems fails with the same error: Unhandled SERIOUS-CONDITION of type SIMPLE-ERROR is signaled: No defined method for ASDF/ACTION:PERFORM on compiling #<compiled-file "sockets" "sockets"> Also the test results demostrate that the code I borrowed for backtrace printing from ASDF doesn't work on ECL lisp-to-c compiler - the backtraces are empty.
22.02.2013, 22:38, "Anton Vodonosov" <avodonosov@yandex.ru>:
Results for ECL, lisp-to-c compiler: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-16.html
Most of the systems fails with the same error: Unhandled SERIOUS-CONDITION of type SIMPLE-ERROR is signaled: No defined method for ASDF/ACTION:PERFORM on compiling #<compiled-file "sockets" "sockets">
The problem nails down to usocket.asd depending on :sb-bsd-sockets. It ma be reroduced lik this: lisps/ecl-bin-12.12.1/bin/ecl -norc -load asdf/build/asdf.lisp (asdf:operate 'asdf:load-op :sb-bsd-sockets) Condition of type: SIMPLE-ERROR No defined method for ASDF/ACTION:PERFORM on compiling #<compiled-file "sockets" "sockets"> Available restarts: 1. (RETRY) Retry compiling #<compiled-file "sockets" "sockets">. 2. (ACCEPT) Continue, treating compiling #<compiled-file "sockets" "sockets"> as having been successful. 3. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at LAMBDA. In: #<process TOP-LEVEL>. File: #P"/home/testgrid/asdf/build/asdf.lisp" (Position #306038)
That smells like a bug in ECL. This works: rlwrap ecl -norc -eval \ "'(#.(require :asdf) #.(format t \"~S~%\" (asdf:asdf-version)) #.(asdf:load-system :sockets))" "2.26.6" This doesn't: rlwrap ecl -norc -load asdf/build/asdf.lisp -eval "'(#.(require :asdf) #.(format t \"~S~%\" (asdf:asdf-version)) #.(asdf:load-system :sockets))" "2.30.3" No defined method for ASDF/ACTION:PERFORM on compiling #<compiled-file "sockets" "sockets">. If I just query from rlwrap /home/testgrid/lisps/ecl-bin-12.12.1/bin/ecl -norc -load asdf/build/asdf.lisp I get: (COMPUTE-APPLICABLE-METHODS #'asdf:perform (list (make-instance 'asdf:compile-op :force t) (asdf:find-component :sockets "sockets"))) (#<standard-method PERFORM (#<The STANDARD-CLASS ASDF/OPERATION:OPERATION> #<The STANDARD-CLASS ASDF/COMPONENT:COMPONENT>)> #<standard-method PERFORM (#<The STANDARD-CLASS ASDF/OPERATION:OPERATION> #<The STANDARD-CLASS ASDF/COMPONENT:COMPONENT>)> #<standard-method PERFORM (#<The STANDARD-CLASS ASDF/OPERATION:OPERATION> #<The BUILT-IN-CLASS T>)> #<standard-method PERFORM (#<The BUILT-IN-CLASS T> #<The STANDARD-CLASS ASDF/BUNDLE:COMPILED-FILE>)>) (describe (car (last (COMPUTE-APPLICABLE-METHODS #'asdf:perform (list (make-instance 'asdf:compile-op :force t) (asdf:find-component :sockets "sockets")))))) #<standard-method PERFORM (#<The BUILT-IN-CLASS T> #<The STANDARD-CLASS ASDF/BUNDLE:COMPILED-FILE>)> is an instance of class STANDARD-METHOD it has the following instance slots THE-GENERIC-FUNCTION: #<standard-generic-function ASDF/ACTION:PERFORM> LAMBDA-LIST: (O C) SPECIALIZERS: (#<The BUILT-IN-CLASS T> #<The STANDARD-CLASS ASDF/BUNDLE:COMPILED-FILE>) QUALIFIERS: NIL THE-FUNCTION: #<compiled-closure 09de3510> DOCSTRING: NIL PLIST: NIL KEYWORDS: NIL (asdf:perform (make-instance 'asdf:compile-op :force t) (asdf:find-component :sockets "sockets")) Condition of type: SIMPLE-ERROR No defined method for ASDF/ACTION:PERFORM on compiling #<compiled-file "sockets" " sockets"> The method that ought to match is this: (defmethod perform (o (c compiled-file)) (declare (ignorable o c)) nil)) Interestingly, that part of the code hasn't changed since ASDF 2.26.6, which works as seen above. However, if I change it to: (defmethod perform ((o operation) (c compiled-file)) (declare (ignorable o c)) nil)) then it works again! And so that is my workaround for 2.30.5. I don't know what causes ECL to not match that method. Is it the new EVAL-WHEN around it? In any case, I believe it's a bug in ECL. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If six billion people have both more food and more forest than their three billion parents did; if the prices of copper, wheat and natural gas are going down, not up; if there are 20 times more carcinogens in three cups of organic coffee than in daily dietary exposure to the worst pesticide both before and after the DDT ban; if renewable resources such as whales are more easily exhausted than non-renewables such as coal; if lower infant mortality leads to falling populations, not rising ones, then perhaps we need to think differently about what sustainability means. Perhaps the most sustainable thing we can do is develop new technology, increase trade and spread affluence. — Matt Ridley On Fri, Feb 22, 2013 at 2:07 PM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
22.02.2013, 22:38, "Anton Vodonosov" <avodonosov@yandex.ru>:
Results for ECL, lisp-to-c compiler: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-16.html
Most of the systems fails with the same error: Unhandled SERIOUS-CONDITION of type SIMPLE-ERROR is signaled: No defined method for ASDF/ACTION:PERFORM on compiling #<compiled-file "sockets" "sockets">
The problem nails down to usocket.asd depending on :sb-bsd-sockets. It ma be reroduced lik this:
lisps/ecl-bin-12.12.1/bin/ecl -norc -load asdf/build/asdf.lisp (asdf:operate 'asdf:load-op :sb-bsd-sockets)
Condition of type: SIMPLE-ERROR No defined method for ASDF/ACTION:PERFORM on compiling #<compiled-file "sockets" "sockets">
Available restarts:
1. (RETRY) Retry compiling #<compiled-file "sockets" "sockets">. 2. (ACCEPT) Continue, treating compiling #<compiled-file "sockets" "sockets"> as having been successful. 3. (RESTART-TOPLEVEL) Go back to Top-Level REPL.
Broken at LAMBDA. In: #<process TOP-LEVEL>. File: #P"/home/testgrid/asdf/build/asdf.lisp" (Position #306038)
Pushed. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There is no meaning without words, no shape without matter, no soul without body. On Fri, Feb 22, 2013 at 5:35 PM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
23.02.2013, 02:33, "Anton Vodonosov" <avodonosov@yandex.ru>:
23.02.2013, 02:30, "Faré" <fahree@gmail.com>:
And so that is my workaround for 2.30.5.
I will run the tests
when you push it
ECL results for ASFD 2.30.5: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-17.html
23.02.2013, 08:48, "Anton Vodonosov" <avodonosov@yandex.ru>:
ECL results for ASFD 2.30.5: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-17.html
I have reivewded the ECL results. The (upstream) errors we have seen already on other CL implementations: - cl-prolog - deoxybyte-utilities - meta-sexp - qbook - xcvb-bridge Other not regressions: - opticl-doc - Not a regression. This ASDF system generates a documentation .html file from .md file. The output .html file is placed near the source file. This operation failes on ECL, but when .html is alreay present the operation is skipped. Interestengly, that new ASDF also rebuilds the ASDF system when dependencies are recompiled, so the failure is visible more often - jwacs - too heavy compilation for gcc (long, and finally gcc runs out of heap) - jwacs-tests - too heavy compilation for gcc (long, and finally gcc runs out of heap) - hu.dwim.serializer - (caused by https://github.com/quicklisp/quicklisp-client/issues/71) - hu.dwim.serializer.test - (caused by https://github.com/quicklisp/quicklisp-client/issues/71) Thigs deserving attention: - blas-complex - blas-real These two seem to be a problem of ASDF integration with cl:require. To reproduce: ./lisps/ecl-bin-12.12.1/bin/ecl -norc -eval '(ext::install-bytecodes-compiler)' -load quicklisp-patched2/setup.lisp -eval '(ql:quickload :blas-complex)' Compare to the following, with succeeds: ./lisps/ecl-bin-12.12.1/bin/ecl -norc -eval '(ext::install-bytecodes-compiler)' -load quicklisp/setup.lisp -eval '(ql:quickload :blas-complex)' - a2x-test - Fare, you might want to review. The error is strange - "Found invalid character Rubout." To reproduce: ./lisps/ecl-bin-12.12.1/bin/ecl -norc -eval '(ext::install-bytecodes-compiler)' -load quicklisp-patched2/setup.lisp -eval '(ql:quickload :a2x-test)' In constrast to old ASDF: ./lisps/ecl-bin-12.12.1/bin/ecl -norc -eval '(ext::install-bytecodes-compiler)' -load quicklisp/setup.lisp -eval '(ql:quickload :a2x-test)'
Thigs deserving attention:
- blas-complex - blas-real These two seem to be a problem of ASDF integration with cl:require. To reproduce: ./lisps/ecl-bin-12.12.1/bin/ecl -norc -eval '(ext::install-bytecodes-compiler)' -load quicklisp-patched2/setup.lisp -eval '(ql:quickload :blas-complex)' Compare to the following, with succeeds: ./lisps/ecl-bin-12.12.1/bin/ecl -norc -eval '(ext::install-bytecodes-compiler)' -load quicklisp/setup.lisp -eval '(ql:quickload :blas-complex)'
Aha. A bug in ASDF. Fixed in 2.30.9. I will include a regression test in next commit. It's also a bug in blas-complex to use (require 'f2cl) when it should be using asdf dependencies instead.
- a2x-test - Fare, you might want to review. Don't worry about a2x-test. It's part of xcvb, and xcvb isn't going to get much love until all current ASDF issues are resolved.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It has been my observation that most people get ahead during the time that others waste. — Henry Ford
Tested ASDF 2.30.5 with CMUCL - detected no new problems in ASDF. More detailed. The table: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-18.html The comparison is with quicklisp 2012-10-13, because it is the last quicklisp working with CMUCL. The (upstream) errors we have seen already on other CL implementations: cl-prolog clpython deoxybyte-utilities jwacs jwacs-tests meta-sexp metacopy-with-contextl qbook Other failures: cl-haml - seems to be a CMUCL bug, opened a ticket: http://trac.common-lisp.net/cmucl/ticket/74 image - unrelated to ASDF update, seems to be a regression in the "image" library since quicklisp 2012-10-13 parseltongue - unrelated to ASDF update, seems to be a regression in the "image" library since quicklisp 2012-10-13 So, we have covered now SBCL, CCL, ECL, CMUCL on linux. I will try to build CLISP 2.29 and test it. Then ACL 9.0 express and then ABCL. Best regards, - Anton
CLISP results. No new problems with ASDF found. One more upstream problem to report - mcclim. http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-19.html The (upstream) errors we have seen already on other CL implementations: qbook xcvb-bridge Other failures: gdl-demos gdl-robot These two are not regressions, got into the table just because during previous test run they had timeout. beirc climacs all the mcclim ASDF systems Fail because mcclim.asd is trying to define a method for asdf:travers and the method dignature is not compatible with the ASDF3 - doesn't have &REST or &KEY. We didn't saw this before because the method is defined under the #+clisp reader conditional (there is also another one for #+allegro)
participants (3)
-
Anton Vodonosov -
Faré -
Stelian Ionescu