Re: [asdf-devel] testing ASDF with cl-test-grid
22.02.2013, 22:38, Anton Vodonosov avodono...@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) ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] testing ASDF with cl-test-grid
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 •ReflectionCybernethics• 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 avodono...@yandex.ru wrote: 22.02.2013, 22:38, Anton Vodonosov avodono...@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) ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] testing ASDF with cl-test-grid
23.02.2013, 02:30, Faré fah...@gmail.com: And so that is my workaround for 2.30.5. I will run the tests ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] testing ASDF with cl-test-grid
Pushed. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• 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 avodono...@yandex.ru wrote: 23.02.2013, 02:33, Anton Vodonosov avodono...@yandex.ru: 23.02.2013, 02:30, Faré fah...@gmail.com: And so that is my workaround for 2.30.5. I will run the tests when you push it ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Failures due to deferred warnings
I must be missing something because I thought Quicklisp already rejects at least new dists if they throw warnings on compiling. Maybe they were/are some different class of warnings, but I remember clearly that Genworks got rejected for inclusion in Quicklisp (this was just over a year ago, and we got cantbuild labels in our Issue in quicklisp-projects) until we got all Warnings eradicated. In the meantime it looks like a few more mis-ordered defparameters crept in, which did not cause new Quicklisp rejections but were flagged by Anton's recent CL-test-grid results with tnew strict asdf. So if the Quicklisp policy has been like this since the beginning, that seems to imply that any warnings in current systems have come in sometime since the system was first accepted into Quicklisp. Dave P.S. are style-warnings going to be next? (First they came for my Warnings. Then, they came for my Style-Warnings... :) On Feb 22, 2013, at 6:01 PM, Faré fah...@gmail.com wrote: Opn Thu, Feb 21, 2013 at 1:30 PM, Anton Vodonosov avodono...@yandex.ru wrote: I want to say do not really support chaning the warinings handling. For two reasons: 1. I don't see how it can be introduced smoothly. Faré, you did significant piece of work by contacting all the maintainers, and it will take more work to track their responses. Somebody will not respond, because the systems are not developed for several years, somebeody will report the undefined variable if fixed, but when we try we will find next undefined variable. Warnings are not always trivial to fix. It's not utf-8 where author can just set the :encoding attribute. Fixing warning involves changing code, analyzing how variables for functions are used, is it possible to reorder definitions, and so on. Also it may result in new bugs. So I am affraid it will take half a year to push the fixes and it's work for you and for the maintainers. Changing the warning rules without fixing the affected systems is not an option at all IMHO. This CL codebase we inherit is a valueable asset, we should direct efforts to preservig it functioning, but not breaking. If we want to direct evolution of CL into some more robust direction, it's better to find a way without rejecting previous work. Well, I agree that it might not be as smooth as we'd all like, but on the other hand, as with any enforcement, it's the whole point of it that it will catch errors that were not previously seen. Pro checking deferred warnings by default: P1- We don't go asking SBCL to remove new error checking features, or to downgrade errors to warnings, warnings to style-warnings, because these new checks find bugs in existing software. We welcome the checks and fix the bugs. P2- It's trivial to disable if desired with (setf asdf:*warnings-file-type* nil) and get the old behavior back. For backwards compatibility, make it (defparameter asdf::*warnings-file-type* nil) P3- If we don't enable it now, by induction, we won't enable it ever, because until we enforce it by default, there will always be someone somewhere who introduce new bugs. The overall cost of transitioning is not substantially reduced by postponing the transition. P4- If some maintainers are unresponsive or unwilling to maintain anymore, it's time to either fork their work (if used) or drop it (if unused). P5- As Attila Lendvai noted, users shouldn't be pulling changes to a library in isolation from changes to other libraries, but be using coherent snapshots of things that work together. And developers should be working on keeping their latest coherent with the latest of their dependencies. i.e. they should keep using the February snapshot of Quicklisp until it's time to upgrade to the March or April snapshot. Con checking deferred warnings by default: C1- If it was compiling cleanly (enough) and working before, why complain about it now? Preventing new bug is one thing, but can't we grandfather in old bugs we know don't affect us? C2- Transition is smoother if old code doesn't have to be modified, only new code. C3- Though the overall work is made somewhat larger by spreading it over time, the instant pain is less, and that matters, too. C4- not having to either wait for the late maintainers or have some non-maintainer update in a fork allows us to make progress without any latency. C5- Inasmuch as some software works for what it's used for, even if it otherwise has bugs, as long as these bugs are not exercised, it's better to let the software run than to reject it at compile-time. So, how can we make transition smoother without sacrificing checking for new code? I could T1- have some magic transition date wired in asdf.lisp, and enable checking for any code modified after that date. Ouch. T2- have a configurable list of systems
Re: [asdf-devel] standard io syntax woes
On Thu, Feb 21, 2013 at 4:46 PM, Juan Jose Garcia-Ripoll juanjose.garciarip...@gmail.com wrote: On Wed, Feb 20, 2013 at 11:18 PM, Faré fah...@gmail.com wrote: Implementations that make the standard readtable read-only: allegro sbcl Implementations that don't: abcl ccl clisp cmucl ecl lispworks scl This is not true (with-standard-io-syntax (set-dispatch-macro-character #\! #\Y (constantly nil))) Condition of type: SIMPLE-ERROR Change readtable Oops, my tests were not automated enough and I missed that. Sorry. I just realized the error message is broken, but ECL does have read-only readtables and a function to lock them (ext:readtable-lock readtable optional yes-or-no) Thanks. I am not sure about the pprint dispatch table, though. We just recycled old SBCL/CMUCL code for that. You would have to do something similar to keep the standard pprint-dispatch table read-only. Thanks a lot! —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Vision is the art of seeing what is invisible to others. — Jonathan Swift ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Failures due to deferred warnings
On Fri, Feb 22, 2013 at 8:42 PM, Dave Cooper david.coo...@genworks.com wrote: I must be missing something because I thought Quicklisp already rejects at least new dists if they throw warnings on compiling. Maybe they were/are some different class of warnings, but I remember clearly that Genworks got rejected for inclusion in Quicklisp (this was just over a year ago, and we got cantbuild labels in our Issue in quicklisp-projects) until we got all Warnings eradicated. In the meantime it looks like a few more mis-ordered defparameters crept in, which did not cause new Quicklisp rejections but were flagged by Anton's recent CL-test-grid results with tnew strict asdf. So if the Quicklisp policy has been like this since the beginning, that seems to imply that any warnings in current systems have come in sometime since the system was first accepted into Quicklisp. Quicklisp hasn't changed here. It relies on ASDF to build software. It's ASDF that has been catching the warnings, and on SBCL failing the build if there is any non-style-warning warning, as per asdf:*compile-file-failure-behaviour* (the default value of which varies by implementation). Now, what warnings get detected evolves as implementation are improved, or in this case as ASDF itself gets more clever and checks deferred warnings that it previously was failing to check. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Democracy is but government of the busy, by the bully, for the bossy. — Arthur Seldon, The Dilemma of Democracy ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] testing ASDF with cl-test-grid
ECL results for ASFD 2.30.5: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-17.html ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
