Re: [asdf-devel] testing ASDF with cl-test-grid
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 •ReflectionCybernethics• http://fare.tunes.org It has been my observation that most people get ahead during the time that others waste. — Henry Ford ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Test results on Mac OSX
Maybe the test script runner should just export SHELL=/bin/sh ? That sounds right for the short term. I don't claim to have fully grokked ASDF:RUN-PROGRAM yet. Would it be reasonable to modify it so that when :force-shell is T (a) it prefers /bin/sh to alternatives, or CMD.EXE on windows? and (b) it allows the user to override and request her shell to be used? I thought it already did that by using the system() libc call, the manpage which, on Linux at least, promises to use /bin/sh, not $SHELL. But looking at ecl/src/lsp/process.lsp I see it uses $SHELL. Probably a mistake. It makes the function mostly unusable to the programmer. Whereas if sh were guaranteed, it would be trivial to execute $SHELL in the rare cases that it is desired (who needs a shell escape when you have a REPL?) Also, the manual page for run-program doesn't explain the return values. And has at least one typo vaule for value: http://ecls.sourceforge.net/new-manual/rn01re63.html Sorry -- make it work just meant make it so that I could determine which test failed, not make the encoding behave correctly. Uh, doesn't this test print the test name just before, in the logs? As to making it work -- this smells like an ABCL bug. Any ABCL hacker listening? —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org So from the depths of its enchantment, Terra was able to calculate a course of action. Here at last was an opportunity to consort with Dirbanu on a friendly basis — great Durbanu which, since it had force fields which Earth could not duplicate, must of necessity have many other things Earth could use; mighty Durbanu before whom we would kneel in supplication (with purely- for-defense bombs hidden in our pockets) with lowered heads (making invisible the knife in our teeth) and ask for crumbs from their table (in order to extrapolate the location of their kitchens). — Theodore Sturgeon, The World Well Lost ___ 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
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] 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
On Thu, Feb 21, 2013 at 6:44 AM, Anton Vodonosov avodono...@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 •ReflectionCybernethics• 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? ___ 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
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-in-Quicklisp 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 •ReflectionCybernethics• http://fare.tunes.org Taxonomy is the death of science — A. N. Whitehead On Thu, Feb 21, 2013 at 8:40 AM, Anton Vodonosov avodono...@yandex.ru wrote: 21.02.2013, 17:27, Stelian Ionescu sione...@cddr.org: On Thu, 2013-02-21 at 08:00 -0500, Faré wrote: On Thu, Feb 21, 2013 at 6:44 AM, Anton Vodonosov avodono...@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 ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] help needed with asdf internals knowledge
On Thu, Feb 21, 2013 at 10:04 AM, Attila Lendvai attila.lend...@gmail.com wrote: dear asdf devels, i want to conditionally compile and load some lisp files on-demand at runtime, and i would like to use the asdf machinery for that. the set of files are not known at development time. the code in question is load-resource-file here: http://common-lisp.net/cgi-bin/darcsweb.cgi?r=cl-l10n-cl-l10n;a=headblob;f=/src/load-locale.lisp the current implementation is broken on asdf3 due to the assert (and a kludge in general): (defun load-resource-file (resource-file) (bind ((output-files (asdf:output-files (make-instance 'asdf::compile-op) (make-instance 'asdf:cl-source-file :pathname resource-file :parent (asdf:find-system :cl-l10n) (assert (length= 1 output-files)) (bind ((output-file (first output-files))) (ensure-directories-exist output-file) (when (or (not (cl-fad:file-exists-p output-file)) ( (file-write-date resource-file) (file-write-date output-file))) (compile-file resource-file :output-file output-file)) (load output-file any help, pointers, thoughts are welcome! I had code that looked just like that in cl-launch, now also copied to exscribe (see compile-and-load-file in exscribe.lisp). I suppose I should make it part of asdf/lisp-build even though asdf/defsystem itself won't use it. Is it OK for you to depend on a recent asdf-driver? —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Any sufficiently advanced bug is indistinguishable from a feature. — Rich Kulawiec ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] standard io syntax woes
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 •ReflectionCybernethics• 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) ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] ASDF 2.30 released
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/14.html 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 •ReflectionCybernethics• 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 ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] Failures due to deferred warnings
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 •ReflectionCybernethics• 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 ___ 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
OK, so I notified the following, but more remain. Notified: :individual-authors ((James Anderson james.ander...@setf.de de.setf.wilbur) (Gary King gwk...@metabang.com trivial-timeout asdf-system-connections lift lift-test cl-containers) (Paul Rodriguez p...@ruricolist.com spinneret) (Alejandro Sedeno ased...@gmail.com cl-protobufs cl-protobufs-tests) (Orivej Desh ori...@gmx.fr postoffice) (Vincent Toups vincent.to...@gmail.com parseltongue) (Leslie Polzer leslie.pol...@gmx.net montezuma) (Alan Oursland alan.oursl...@gmail.com km) (Ryan Davis r...@acceleration.net cl-csv cl-mediawiki) (Drew Crampsie drew.cramp...@gmail.com lisp-on-lines) (Robert Marlow bobstop...@bobturf.org xmls-tools) ) :mailing-lists ((mcclim-de...@common-lisp.net mcclim) (zlib-de...@common-lisp.net zlib) (cl...@b9.com clsql) (cleric-de...@common-lisp.net cleric) (cl-neo4j-devel cl-neo4j) ) :no-valid-email ((Michael Parker mparker...@hotmail.com regex) ;; both deferred-warnings failure and UTF8 issue, but author email not valid anymore. )) Remain: coleslaw com.informatimago.common-lisp.parser diff gdl-ta2 lispbuilder-regex marching-cubes mgl odd-streams open-vrp-lib pg prepl webactions 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-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 For the record, failure logs are here: http://common-lisp.net/project/cl-test-grid/asdf/sbcl-warning-failures.html http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-13.html —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org May you live all the days of your life. — Jonathan Swift On Wed, Feb 20, 2013 at 9:54 PM, Faré fah...@gmail.com wrote: 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 •ReflectionCybernethics• 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 ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] clearing output-translations for a dumped image
On Tue, Feb 19, 2013 at 11:27 PM, Dave Cooper david.coo...@genworks.com wrote: 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? If you're using ASDF3's program-op or the underlying dump-image, then you don't need do anything to clean up the output-translations: it's all handled for you using the *image-dump-hook*. On ASDF2, I recommend using (asdf:clear-configuration) before you dump an 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). Indeed. Regards, —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org An insult may sometimes adequately fit the person who is insulted. However, it can only ever possibly tarnish but the person who insults. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] clearing output-translations for a dumped image
On Wed, Feb 20, 2013 at 12:46 AM, Dave Cooper david.coo...@genworks.com wrote: Holy Cow I started looking through ADSF3 (asdf 2.29) and it is starting to do everything under the sun! Well, not *everything*, just everything needed to portably bootstrap the building of Common Lisp code. The new functionality like the ASDF/DRIVER compatibility layer, dumping images, and concatenated fasls look really useful and have potential to simplify things on our end a lot. That's the whole point of it. So ASDF/DRIVER has superseded asdf-utils, right? Yes it has. There is a package nickname that says so, and asdf-utils is now an otherwise empty system that depends on asdf/driver. The functions in 10.3 Miscellaneous Functions of the documentation are the main functions now in ASDF/DRIVER? Or I suppose there are a lot more now -- and the main documentation for the moment are in the source code (understandable). The manual has been minimally updated. Writing then debugging ASDF3 took so much energy that I didn't have much left for writing the manual, especially since things were moving fast while I made many passes to refactor the API until it was in a satisfying shape. For dumping of images, I see for Allegro CL this maps to excl:dumplisp with only a couple of keyword arguments, which is fine for basic dumping of images when there's not a lot of need of fine control. As you may or may not know, Allegro CL has a couple other ways of making executable images: excl:generate-application and excl:build-lisp-image. For our distributions we sometimes have to call these functions instead of excl:dumplisp. When the ASDF3 dust has settled a bit and I understand the workings of ASDF3 a bit better, I hope I (or somebody -- maybe somebody from Franz?) will be able to extend the image-dumping support in ASDF to handle these Allegro CL functions as well. But, these functions take many (maybe dozens) of keyword arguments, so maybe it starts to go beyond what a reasonable portability layer like what ASDF is trying to achieve should be trying to provide... (actually excl:dumplisp takes many of the same keyword arguments as well... so I suppose the answer is that if one needs that find level of control, one had better go ahead and directly call the native version). Yes, for the moment, you'll have to go native if you need the support. Nonetheless I still recommend you use ASDF3 and respect its hooks as you dump the image: (setf *image-dumped-p* (if executable :executable t)) (standard-eval-thunk *image-postlude*) (call-image-dump-hook) Then use restore-image as your restart function. If you contribute support for all these options and more to asdf/image, I would be grateful. Anyway for the time being, if I am using ASDF3 with Allegro CL, and want to use excl:generate-application or excl:build-lisp-image, in order to clear the configuration, is the (asdf:clear-configuration) still going to work as in ASDF2? Yes, it will; but still I recommend you use ASDF3 and its hooks instead (see above). —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as bad luck. — Robert Heinlein, Time Enough For Love ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
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 •ReflectionCybernethics• http://fare.tunes.org It’s amazing that the amount of news that happens in the world everyday always just exactly fits the newspaper. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] ASDF 2.29 released
Dear Lisp hackers, ASDF 2.27 was a major rewrite of ASDF, and everything since then should be considered as candidate releases for ASDF 3: http://lists.common-lisp.net/pipermail/asdf-announce/2013-February/14.html ASDF 2.28 was released shortly after 2.27, without an announcement, to fix an issue found by Stelian Ionescu using TEST-OP on some systems. ASDF 2.29 is a stability release, with which I'm once again inviting implementers to update the ASDF they distribute. Since ASDF 2.27, ASDF 2.29 further brings: * deferred-warnings support for Allegro, CMUCL, SCL; fixes to the CCL support. * Upgrade fixes regarding fallback system versions; making it possible (via massive use of eval-when) to compile ASDF without loading it first. * Compatibility with private use of :D package nickname by not claiming it for package ASDF/DRIVER anymore. Also explicitly handle NIL in safe-file-write-date, in case the implementation doesn't issue a file-error in that case; make UTF-8 the default encoding for with-input-file. Be portable to #+(and sbcl (not sb-eval)). * Bugfixes to old bugs: inline-methods can now be unqualified (lp#485393), defsystem-depends-on accepts arbitrary specs, not just names (lp#1027521). —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Panties: not best thing on earth, but next to it. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] maybe hot-upgrade of ASDF is not needed anymore
If I do a (require FOO) for FOO some internally supplied library of SBCL, doesn't that trigger the use of ASDF to load FOO? It does. For example, (require :sb-bsd-sockets) also loads ASDF. Note that if and when SBCL uses ASDF 3, it will be trivial to update its contrib to use the one-fasl-for-the-entire-contrib approach, and not have any contrib require ASDF. But we're not there yet. But If if I load my ASDF before doing (require :sb-bsd-sockets) then my ASDF is used. Yes. The question: is this situation mean that ASDF must be hot-upgradable? IMHO not, because there is enough freedom for user to load his ASDF in the beginning. In the current world, ASDF must still be hot-upgradable. It is conceivable that we could move toward a world where it need not. Beware, though, of the perverse incentives that used to exist in the previous situation where it was not: http://fare.livejournal.com/149264.html You will need some force capable of countering them. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org The main difference between a computer salesman and a used car salesman is that the used car salesman can probably drive and knows when he's lying. - Peter da Silva ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Change in the way ASDF performs a plan? Or :force semantics?
Well, remove-method could be used in some cases, but it doesn't by far cover all cases: 1- sometimes, the function signature changed; key arguments were added (or removed?), a function was made generic that wasn't before, or generic no more that was before. Only fmakunbound can handle these cases. Adding or removing keyword arguments in methods is not a problem in CLOS. It's not about removing a specific keyword. It's about adding or removing the key capability at all. If you have a previous (defgeneric gf (x y)) then you can't (defmethod gf (x y key z) ...). Why not keep functions generic if your intent is to redefine functionality at runtime? Some functions were once added as simple defuns before they were made into gf's later. Other functions were originally added as gf's but were later made thin defun wrappers around other gfs. In any case, remove-method just doesn't cut it. We need fmakunbound if the signature was ever incompatible. 2- sometimes, other methods exist that were installed by asdf extensions that have been invalidated by other reasons (such as classes being updated, etc.) These methods should NOT be preserved, but wholly invalidated, until an updated version of the ASDF extension can themselves be loaded. I don't understand this use case. Can you give more details? ASDF3 radically enhanced the way operate or component-depends-on works. Many internals have changed. If any ASDF extension depended on some old behavior or internal, it may fail to work spectacularly. The only *safe* thing in many cases is to invalidate all methods by all extensions, and reload a (new updated version of) the extensions that you need. 3- CLOS is yet another vast source of portability issues, CLOS is part of ANSI CL [...] I have ported ASDF to 15 different implementations. Many implementations have subtle bugs in their CLOS implementation, or interesting interpretations of the specification. I'm not going to write compatibility layers around incorrect behavior just so I may build further dependencies on correct CLOS behavior. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org There is joy in work. There is no happiness except in the realization that we have accomplished something. — Henry Ford ___ 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 2.28 [was: can't run quicklisp with asdf 2.28 on CCL (upgrage issue?)] [was: sbcl results for quicklisp + asdf 2.28]
On Thu, Feb 7, 2013 at 9:22 PM, Anton Vodonosov avodono...@yandex.ru wrote: Diff between unpatched quicklisp 2013-01-28 and quicklisp 2013-01-28 + asdf 2.28.6 for SBCL and CCL: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-9.html 07.02.2013, 07:16, Faré fah...@gmail.com: On Thu, Feb 7, 2013 at 3:36 AM, Anton Vodonosov avodono...@yandex.ru wrote: Meantime the SBCL results for ASDF 2.28.4 Diff comparing to 2.28: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-7.html (don't pay attention to weblocks-test, it crushes sometimes when SBCL runs out of heap) OK, so that's (small) progress. Note that unicly system started to fail. It's an ASCII vs UTF-8 issue. I'm tempted for the 3.0 release to make it use UTF-8 by default instead of :default, on platforms that support it. Which means I once again have to track down the handful of offenders. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Our love was a supernova, bursting with an immense light only to wane quickly, leaving behind a black hole. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Change in the way ASDF performs a plan? Or :force semantics?
Dear Robert, it looks like the issue is that you loaded your methods to extend ASDF before upgrading ASDF itself, which won't work. Upgrading ASDF includes a FMAKUNBOUND on several functions, including PERFORM, which indeed UNTRACE's them on many implementations. ASDF 3 will always try to upgrade itself before any operation, precisely to avoid squashing your methods in the middle of the operation, which would be far worse. But if it was already upgraded, this should be a No-Op (unless there's a bug in ASDF). Moreover, :force t should not apply to ASDF, because it has the :builtin-system-p t flag. I just tried at home, and it worked. Considering that you seem to already have had ASDF 3 installed (since it did the automatic upgrade attempt), the issue seems to be that you git pull'ed after loading your ASDF overrides, and they thus got squashed during the implicit ASDF upgrade. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Money doesn't change men, it merely unmasks them. If a man is naturally selfish or arrogant or greedy, the money brings that out, that's all. — Henry Ford On Wed, Feb 6, 2013 at 1:41 AM, Robert Goldman rpgold...@sift.info wrote: I was having a case where some package wrangling in one of our systems behaved differently with new ASDF than with the ASDF 2 that ships with ACL. It seemed like there was an :AFTER method on one of my modules that simply wasn't being called. I took my usual resort and did (TRACE ASDF:PERFORM). I was very surprised to see that my (asdf:load-system circa-csm :force t) resulted in only four calls to perform, and all of them had to do with ASDF: CL-USER (asdf:load-system circa-csm :force t) ; Loading /Users/rpg/lisp/asdf/asdf.asd ; Loading /Users/rpg/lisp/asdf/asdf-driver.asd 0[7]: (ASDF/ACTION:PERFORM #ASDF/LISP-ACTION:PREPARE-OP #ASDF/SYSTEM:SYSTEM asdf) 0* (MULTIPLE-VALUE-PROG1 (PROGN #STANDARD-METHOD ASDF/ACTION:PERFORM :BEFORE (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT) #STANDARD-METHOD ASDF/ACTION:PERFORM (ASDF/LISP-ACTION:PREPARE-OP ASDF/COMPONENT:COMPONENT)) #STANDARD-METHOD ASDF/ACTION:PERFORM :AFTER (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)) 0[7]: returned NIL 0[7]: (ASDF/ACTION:PERFORM #ASDF/LISP-ACTION:PREPARE-OP #ASDF/COMPONENT:MODULE asdf build) 0* (MULTIPLE-VALUE-PROG1 (PROGN #STANDARD-METHOD ASDF/ACTION:PERFORM :BEFORE (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT) #STANDARD-METHOD ASDF/ACTION:PERFORM (ASDF/LISP-ACTION:PREPARE-OP ASDF/COMPONENT:COMPONENT)) #STANDARD-METHOD ASDF/ACTION:PERFORM :AFTER (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)) 0[7]: returned NIL 0[7]: (ASDF/ACTION:PERFORM #ASDF/LISP-ACTION:PREPARE-OP #ASDF/LISP-ACTION:CL-SOURCE-FILE asdf build asdf) 0* (MULTIPLE-VALUE-PROG1 (PROGN #STANDARD-METHOD ASDF/ACTION:PERFORM :BEFORE (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT) #STANDARD-METHOD ASDF/ACTION:PERFORM (ASDF/LISP-ACTION:PREPARE-OP ASDF/COMPONENT:COMPONENT)) #STANDARD-METHOD ASDF/ACTION:PERFORM :AFTER (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)) 0[7]: returned NIL 0[7]: (ASDF/ACTION:PERFORM #ASDF/LISP-ACTION:LOAD-OP #ASDF/LISP-ACTION:CL-SOURCE-FILE asdf build asdf) 0* (MULTIPLE-VALUE-PROG1 (PROGN #STANDARD-METHOD ASDF/ACTION:PERFORM :BEFORE (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT) #STANDARD-METHOD ASDF/ACTION:PERFORM (ASDF/LISP-ACTION:LOAD-OP ASDF/LISP-ACTION:CL-SOURCE-FILE)) #STANDARD-METHOD ASDF/ACTION:PERFORM :AFTER (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)) ; Fast loading ;
Re: [asdf-devel] Change in the way ASDF performs a plan? Or :force semantics?
On Wed, Feb 6, 2013 at 3:48 PM, Robert Goldman rpgold...@sift.info wrote: ASDF 3 will always try to upgrade itself before any operation, precisely to avoid squashing your methods in the middle of the operation, which would be far worse. I'm afraid that this behavior needs refinement. Consider what we are doing: * we load my system definition * we load/upgrade ASDF3 * ASDF3 destroys part of my system definition and *quietly* goes ahead and does the wrong thing, loading a damaged system definition. I can't imagine a case where the programmer wants this behavior. Is there any reason not to load your definitions *after* upgrading ASDF? ASDF *must* be upgraded first thing during your build. Upgrading it at any other time is bound to cause trouble sooner or later. There's just no reliable way we can update the basic ASDF methods without squashing the generic functions, which in turn will necessarily squash any extensions. Squashing entire functions and reloading extensions is also the only way to survive unless we require each and every extension to also follow the hot-upgrade discipline of ASDF. And frankly, considering how hard that discipline is, it's not something I wish on my enemies, much less my friends. I could be convinced that ASDF should upgrade itself, but I believe my example shows that any time ASDF upgrades itself it must reload all system definitions, because they have potentially been damaged. That's an option I have considered: automatically re-loading all previously defined systems when you upgrade ASDF. But not all systems can be upgraded at all, so this can potentially cause more damage as it can prevent. That seems like a tall order, so a more modest alternative would be: ASADF should raise an error and refuse to continue after reloading itself, forcing the programmer to re-do any operations that triggered the reload. In that case, it should mark all loaded system definitions as invalid, since they may contain method definitions that have been removed. Usually, the initial upgrade just works, and the restarting of operations is automatic when that upgrade happens as part of an operate. It only fails if your definitions are not findable via the normal find-system mechanism, and/or have undeclared defsystem-depends-on dependencies. If you do things cleanly, it should work. But if it was already upgraded, this should be a No-Op (unless there's a bug in ASDF). Moreover, :force t should not apply to ASDF, because it has the :builtin-system-p t flag. I just tried at home, and it worked. I just retried and got the same behavior. No git operations done this morning. This is on ACL 8.2, Mac OS X, 64-bit Enterprise: CL-USER (push home:lisp;asdf; asdf:*central-registry*) (home:lisp;asdf; home:lisp;franz-clx; ~/lisp/asdf-systems/ ~/lisp/asdf-install-systems/systems/ ~/lisp/asdf-systems/ ~/lisp/asdf-install-systems/systems/) CL-USER (asdf:load-system asdf) ; Loading /Users/rpg/lisp/asdf/asdf.asd ; Fast loading ; /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/lisp/asdf/build/asdf.fasl ; Upgrading ASDF from version 2.23.7 to version 2.28 T CL-USER (circa) Configuring for CIRCA systems... CIRCA ASDFs now in load path. NIL CL-USER (asdf:load-system circa-csm :force t) ; Loading /Users/rpg/circa/code/csm/circa-csm.asd ; Loading /Users/rpg/circa/code/csm/logical-pathname.lisp ; Loading /Users/rpg/circa/code/csm/optimization-boilerplate.lisp ; Fast loading /usr/local/acl/acl82.64/code/CLX.001 ;;; Installing clx patch, version 1. ; Autoloading for package CLTL1: ; Fast loading from bundle code/cltl1.fasl. ; Foreign loading clx:excldep.dylib. ; Loading /Users/rpg/lisp/asdf/asdf.asd ; Loading /Users/rpg/lisp/asdf/asdf-driver.asd ; Fast loading ; /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/lisp/asdf/build/asdf.fasl . I verify that this behavior does *NOT* occur in SBCL, loading the same system definition. The only suspicious thing I see in the transcript from ACL is the loading of CLX. I wonder if there's any chance that this triggers some interaction with ASDF? That would be bad. Looks like it's an issue with logical pathnames, whereby on Allegro, it thinks that ASDF has changed because it resolves to a different file, what with ASDF 3 being more careful at not squashing logical-pathnames than was ASDF 2. Maybe (describe (find-system :asdf)) at various stages can help diagnose the exact issue. Considering that you seem to already have had ASDF 3 installed (since it did the automatic upgrade attempt), the issue seems to be that you git pull'ed after loading your ASDF overrides, and they thus got squashed during the implicit ASDF upgrade. No, the above experiment shows that is not the explanation. Something stranger is going on. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Computer programming is omnipotence without omniscience. —
[asdf-devel] load-op
For those who are interested, lp#515807 contains a discussion about how we'd like to customize LOAD-OP so that on some files it would load the source (but what on ECL and MKCL?), whereas on some systems it would load a bundle, etc. https://bugs.launchpad.net/asdf/+bug/515807 —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Living your life is a task so difficult, it has never been attempted before. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] can't run quicklisp with asdf 2.28 on CCL (upgrage issue?)
On Wed, Feb 6, 2013 at 9:22 PM, Anton Vodonosov avodono...@yandex.ru wrote: Trying with ASDF 2.28.4 The ECL problem has gone, but CCL still can't run quicklisp: OK, I committed a workaround to ASDF 2.28.5. lisps/ccl-1.8/lx86cl --no-init --load quicklisp-patched2/setup.lisp Error: Error while trying to load definition for system quicklisp from pathname /home/testgrid/quicklisp-patched2/quicklisp/quicklisp.asd: Undefined function #:|ASDF::COMPONENT-VERSION| called with arguments (2012112500 #SYSTEM quicklisp) . While executing: (:INTERNAL ASDF/FIND-SYSTEM:LOAD-ASD), in process listener(1). Type :GO to continue, :POP to abort, :R for a list of available restarts. If continued: Retry applying #:|ASDF::COMPONENT-VERSION| to (2012112500 #SYSTEM quicklisp). Type :? for other options. This is a problem with package upgrade of the setf-function. Background: CCL and CLISP both use a trick whereby (setf foo::bar) is internally resolved to some regular symbol, bound to a function, SETF::|FOO::BAR| in the case of CCL. When ASDF is split into several packages and ASDF:COMPONENT-VERSION becomes ASDF/COMPONENT:COMPONENT-VERSION, care is taken to move the SETF symbols so that SETF::|ASDF::COMPONENT-VERSION| is replaced by SETF::|ASDF/COMPONENT::COMPONENT-VERSION| in the mapping table; but apparently something is not right between ASDF and CCL 1.8, so that the new parse-component-form gets compiled with the old uninterned SETF symbol. A recent CCL 1.9 doesn't seem to have the same issue. It's harder for me to write a real solution without being able to reproduce locally. My current workaround is to use SETF SLOT-VALUE instead of the accessor, and eschew this SETF symbol issue. Ugly, but seems to work, or at least to get us further. Maybe I need more magic in define-package for SETF symbols on older CCLs, or maybe I need to detect bad ASDF/CCL combos and punt on upgrades in these cases. Or maybe I just need to convince Xach that he should do the safe thing and load asdf from source before to compile-file it, since my recent attempt at putting everything in an EVAL-WHEN to make that unnecessary seems to have failed on CCL. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org To speak algebraically, Mr. M. is execrable, but Mr. G. is (x+1)ecrable. — Edgar Alan Poe ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] can't run quicklisp with asdf 2.28 on CCL (upgrage issue?)
07.02.2013, 05:54, Faré fah...@gmail.com: On Wed, Feb 6, 2013 at 9:22 PM, Anton Vodonosov avodono...@yandex.ru wrote: OK, I committed a workaround to ASDF 2.28.5. Have you pushed it? The comment on the top of asdf.lisp still says This is ASDF 2.28.4 I was experiencing Internet connection issues from this remote country house in France. Now that the 'net is back, and it's pushed. Sorry for the delay. I have impression that the code upgrade support is one of the most expensive features in ASDF. It is, and by far. Maybe I should have stuck with deleting the package ASDF and all packages that depend on it. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Failure is not an option. It comes bundled with your Microsoft product. — Ferenc Mantfeld ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] can't run quicklisp with asdf 2.28 on CCL (upgrage issue?)
Anton, the failure you found seems to be a case of quicklisp compiling asdf without having loaded it as source first. To compile asdf even when a previous asdf was loaded, it is currently necessary to first load asdf.lisp as source. quicklisp (require)'s the previous asdf, then compiles the new one without loading it. That won't work. To make it work, I would essentially have to have each and every form in asdf.lisp wrapped in an eval-when. I suppose I could do just that; it wouldn't be worse than loading asdf.lisp before compiling it, and it would be simpler for Zach and other people. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Each new generation born is in effect an invasion of civilization by little barbarians, who must be civilized before it is too late. — Thomas Sowell ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] can't run quicklisp with asdf 2.28 on CCL (upgrage issue?)
On Tue, Feb 5, 2013 at 4:03 AM, Anton Vodonosov avodono...@yandex.ru wrote: I placed new asdf.lisp into quicklisp and changed (defvar *required-asdf-version* 2.28) in quicklisp/setup.lisp to the lates version - 2.28. This looks like the bad interaction of files compiled with a previous ASDF and files compiled with the new one. Did you clean your fasl cache after you upgraded? I'll investigate tomorrow. It's also possible that my upgrade tricks don't work so well on CCL, and I need to punt like I do on CLISP. However, CCL does pass all my automated upgrade tests so far, so if that's the case I need to improve those tests. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Pournelle's Iron Law of Bureaucracy states that in any bureaucratic organization there will be two kinds of people: those who work to further the actual goals of the organization, and those who work for the organization itself. Examples in education would be teachers who work and sacrifice to teach children, vs. union representative who work to protect any teacher including the most incompetent. The Iron Law states that in all cases, the second type of person will always gain control of the organization, and will always write the rules under which the organization functions. lisps/ccl-1.8/lx86cl --no-init --load quicklisp-patched2/setup.lisp Error: Error while trying to load definition for system quicklisp from pathname /home/testgrid/quicklisp-patched2/quicklisp/quicklisp.asd: Undefined function #:|ASDF::COMPONENT-VERSION| called with arguments (2012112500 #SYSTEM quicklisp) . While executing: (:INTERNAL ASDF/FIND-SYSTEM:LOAD-ASD), in process listener(1). Type :GO to continue, :POP to abort, :R for a list of available restarts. If continued: Retry applying #:|ASDF::COMPONENT-VERSION| to (2012112500 #SYSTEM quicklisp). Type :? for other options. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
After discussion with people on #lisp and via private chat, I decided to use a shorter name. Here is what was released in 2.27: :long-name Another System Definition Facility :homepage http://common-lisp.net/projects/asdf/; :bug-tracker https://launchpad.net/asdf/; :mailto asdf-devel@common-lisp.net :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Hopefully, they ban not just gay marriage, but straight marriage too, and at last we have separation of state and marriage. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] More backward compatibility needed
On Thu, Jan 31, 2013 at 4:13 AM, Bill Robinson wivl...@gmail.com wrote: Sorry, I haven't touched it for a while. Is this causing a problem? For what projects? The actual cl-glfw-opengl system is probably a lot less used than cl-glfw. Oh, that appeared while blindly loading software from Quicklisp. As I recall I think it's because there are two packages that can provide those named functions, the ARB extensions for older version of OpenGL and the core equivalents for later versions. Including those packages assumes you will have loaded one or other of the specific versions. Basically, it depends on another package. I see. I suppose a clean approach would be to define a base package with appropriate interfaces, either through special variables and hook variables or an explicit interface object (possibly using interface-passing style); at worst, stub functions to be overridden in another system. Then, your system would not have hidden dependencies on one of two other systems. I could go back and have a look, but it might not be for some weeks before I get time to do it. Sorry. If it's working as designed, then the issue is not urgent, but you might consider it a worthwhile cleanup. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Foolishness is rarely a matter of lack of intelligence or even lack of information. — John McCarthy ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
On Fri, Feb 1, 2013 at 8:19 PM, Anton Vodonosov avodono...@yandex.ru wrote: 01.02.2013, 23:23, Faré fah...@gmail.com: After discussion with people on #lisp and via private chat, I decided to use a shorter name. Here is what was released in 2.27: :long-name Another System Definition Facility :homepage http://common-lisp.net/projects/asdf/; :bug-tracker https://launchpad.net/asdf/; :mailto asdf-devel@common-lisp.net :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) Another useful slot would be :purpose, it could specify what the library is: web server, db client, image processing library, data-structures library, etc. The values in this slots are tags from some specified taxonomy. To avoid creating the taxonomy from scratch we could start for example with the tag tree from cl-user.net. In in the future we could want to improve the taxonomy. If the new improved taxonomy is incompatible with the old one, we can then introduce new slot, :purpose2, specifying that it can hold values from new taxonomy. I think this is an idea for future, it's probably too big to be in the scope of ASDF3 s Why not. And if some people end up actually using component-property for such useful purpose, or otherwise make successful use of it, I am willing to reconsider the deprecation of component-property, and/or my successor will. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org No matter what language you use, a Sufficiently Smart Compiler(TM) will be able to find an efficient implementation for whatever apparently difficult problem you specify. However, a Sufficiently Smart Compiler(TM) for arbitrary problems is itself an AI-complete problem. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
On the one hand, I am deprecating component-property in ASDF3, Why? What will be the new mechanism for what component-property provides? I propose that any data that component-property is actually used for should be in appropriate slots of the system. This will introduce a new round of synchronization headaches whenever a new slot is added. The existing mechanism is forward and backward compatible indefinitely. Synchronization is NOT necessary to add new slots. If you want a new slot, just create a new class with that slot, and use both :defsystem-depends-on and :class in your defsystem form. This usage pattern wouldn't work on ASDF 1 or early ASDF 2, but it works quite well since ASDF 2.016 from June 2011 and later. Then, a year after your slot gets merged into asdf:system, you can stop using your defsystem-depends-on. The properties mechanism is already totally and irremediably useless. Automation across systems is impossible unless everyone agrees on a schema, or you somehow merge the zillions of possible ad-hoc schemas; but properties actually make synchronization *harder* than lack thereof, by making it cheaper to diverge and more expensive to converge. Properties without a synchronized schema are useless within a single system, where it is easier, safer and more powerful to just directly store data in a Lisp variable rather than in the properties. In other words, properties not only do not serve the purpose they look like they are addressing, but cannot possibly serve any purpose. They are a lure and a waste of everyone's time — an attractive nuisance. I propose they be replaced by the real thing, i.e. agreeing on a schema. Before we do, we would be well inspired to look at similar metadata schemas from Debian, RPM, Hackage, PLaneT, etc. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Failure is the opportunity to begin again, more intelligently. — Henry Ford, who had two flops before founding Ford Motor Co. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Synchronization is NOT necessary to add new slots. If you want a new slot, just create a new class with that slot, and use both :defsystem-depends-on and :class in your defsystem form. This usage pattern wouldn't work on ASDF 1 or early ASDF 2, but it works quite well since ASDF 2.016 from June 2011 and later. Then, a year after your slot gets merged into asdf:system, you can stop using your defsystem-depends-on. Feel free to adopt this technique for your proposed website slot, so it does not cause compatibility problems. Please do not remove other techniques. There is no compatibility problem whatsoever with adding optional slots. And I *will* severely cripple the properties slot, then remove it eventually, but not until after everyone has moved away from it for a year or two. The properties mechanism is already totally and irremediably useless. Automation across systems is impossible unless everyone agrees on a schema, or you somehow merge the zillions of possible ad-hoc schemas; but properties actually make synchronization *harder* than lack thereof, by making it cheaper to diverge and more expensive to converge. Properties without a synchronized schema are useless within a single system, where it is easier, safer and more powerful to just directly store data in a Lisp variable rather than in the properties. In other words, properties not only do not serve the purpose they look like they are addressing, but cannot possibly serve any purpose. They are a lure and a waste of everyone's time — an attractive nuisance. I think it would be pretty easy to get everyone to agree on a schema for properties, and it would be useful to do so. For the same price, we can agree on a schema, add it to defclass system, and get rid of the attractive nuisance that is component-properties. Silently incompatible is not the same as compatible. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org War does not determine who is right — only who is left. — Bertrand Russell ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] API changes into ASDF 3
Dear all, is anyone of you using any of these functions from ASDF, ASDF-UTILS or XCVB-DRIVER ? I've removed them and here are the alternatives I am using. Since previous code didn't have any numbered release API, I will only provide compatibility trampolines if there is a declared user base. These symbols are gone since ASDF 2.26 and corresponding ASDF-UTILS, and here are the alternatives: orf = latest-stamp-f (compares timestamp, not just booleans) aif, it = if-let (compatible with alexandria) remove-keys = remove-plist-keys (compare with EQL, not STRING=) remove-keyword = remove-plist-key (more consistent and descriptive name) split-pathnames* = split-native-pathnames-string (naming makes clear it's native-namestrings, not namestrings) ensure-pathname-absolute = ensure-absolute-pathname (API much enhanced with different error behavior) resolve-relative-location-component = resolve-relative-location resolve-absolute-location-component = resolve-absolute-location Backward-compatible wrappers are already provided for the below deprecated functions with known users: coerce-pathname = parse-unix-namestring component-name-to-pathname-components = split-unix-namestring-directory-components compile-file-keeping-object = compile-file* From XCVB-DRIVER and ASDF-CONDITION-CONTROL, these have been renamed as they moved to ASDF/DRIVER: run-program/ = run-program with-controlled-compiler-conditions = with-muffled-compiler-conditions with-controlled-loader-conditions = with-muffled-loader-conditions with-xcvb-compilation-unit = with-saved-deferred-warnings eval-string = eval-input bork = handle-fatal-condition *debugging* = *lisp-interaction* For ASDF itself, these interfaces have been removed, and here are their replacements. :if-component-dep-fails = :if-feature :do-first = :in-order-to (:do-first wouldn't actually work in ASDF 1; :in-order-to does the right thing in ASDF 3 for both previous :in-order-to and previous :do-first). make-sub-operation = find-operation asdf-binary-locations configuration = enable-asdf-binary-locations-compatibility (ABL worked with ASDF 1; this compatibility layer exists since ASDF 2 and still supported, actually enhanced, with ASDF 3) These ASDF internals have compatibility wrappers, but are deprecated: run-shell-command = asdf/driver:run-program (used by many clients) load-sysdef = load-asd (used by slime) make-temporary-package = (find-package :asdf-user) (used by slime) operation-error = define your own error class compile-error = compile-file-error compile-failed = compile-failed-error, compile-failed-warning compile-warned = compile-warned-error, compile-warned-warning operation-on-warnings = *compile-file-warnings-behaviour* operation-on-failure = *compile-file-failure-behaviour* system-definition-pathname = system-source-directory, system-relative-pathname (since ASDF 2) component-property = no replacement yet, working on it. make-instance 'some-op = either just 'some-op or (make-operation 'some-op) (make-instance operation still works for now but is deprecated) —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Skill without imagination is craftsmanship. Imagination without skill is contemporary art. — Tom Stoppard ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Feel free to adopt this technique for your proposed website slot, so it does not cause compatibility problems. Please do not remove other techniques. There is no compatibility problem whatsoever with adding optional slots. I just tried, and got this: Error while trying to load definition for system wwwoops from pathname /home/xach/src/lisp/wwwoops/wwwoops.asd: Invalid initialization argument: :WEBSITE in call for class #STANDARD-CLASS ASDF:SYSTEM. [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR] There *is* a compatibility problem. I haven't added the slots yet, so of course it won't work. As for disabling properties on old versions of ASDF that don't actually support them, that's what #+asdf3 is for, just like #+asdf2 before it. Hopefully, two years from now we can assume everyone has moved from ASDF2 to ASDF3, just like today we can safely assume no one uses ASDF1 anymore. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Oignez villain, il vous poindra ; poignez villain, il vous oindra. — Rabelais ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
I did an analysis of how system properties are used in Quicklisp systems, and this suggests that the following initargs be added: :website-url === widely requested. the URL suffix makes it less ambiguous. :bug-tracker-url === Zach's request that makes a *whole* lot of sense :development-email === More actionable name than :author-email. Or maybe just use mailto: URL in bug-tracker-url? :long-name === we have :long-description already, so why not? I believe some kind of :source-control slot might be useful, though between SVN, GIT, Mercurial, etc., there is no common URL pattern, so we'd have to specify some structure. Either a list of `(,vcs-keyword ,@url+options) or a command to checkout / clone the repository to be parsed, or something. Here are the uses of component properties in Quicklisp systems: asd's that directly use asdf:component-property: *** yaclml = :features === property for version comparison. See arnesi below. *** amazon-ecs = :website === Yes, need to be added to ASDF 3. *** hemlock.asd = :last-loaded-as-source === bad implementation of latin1 encodings with lifted from ASDF 1's bad implementation of load-source-op. Let's just use asdf-encodings for that, and/or use UTF-8, furgossake. asd's that use :properties in defsystem: *** arnesi, arnesi+ = :features === misguided property used for version comparison and pseudo #+features version comparison should use :version. The pseudo-features should probably be replaced by either having separate systems or actual features, depending on their use pattern. If actually useful, create a subclass with a :component-features initarg. *** lkcas, thopter = :long-name === used by the Makefile through component-property. I could add that to defclass system, or he could use a subclass. *** cl-irc cliki-bot rss cl-syslog com.informatimago.clext com.informatimago.clisp com.informatimago.clmisc com.informatimago.common-lisp.arithmetic om.informatimago.common-lisp.bank com.informatimago.common-lisp.cesarum com.informatimago.common-lisp com.informatimago.common-lisp.csv com.informatimago.common-lisp.cxx com.informatimago.common-lisp.data-encoding com.informatimago.common-lisp.diagram com.informatimago.common-lisp.ed com.informatimago.common-lisp.graphviz com.informatimago.common-lisp.heap com.informatimago.common-lisp.html-base com.informatimago.common-lisp.html-generator com.informatimago.common-lisp.html-parser com.informatimago.common-lisp.http com.informatimago.common-lisp.interactive com.informatimago.common-lisp.invoice com.informatimago.common-lisp.lisp com.informatimago.common-lisp.lisp.ibcl com.informatimago.common-lisp.lisp.stepper com.informatimago.common-lisp.lisp-reader com.informatimago.common-lisp.lisp-sexp com.informatimago.common-lisp.lisp-text com.informatimago.common-lisp.parser com.informatimago.common-lisp.picture com.informatimago.common-lisp.regexp com.informatimago.common-lisp.rfc2822 com.informatimago.common-lisp.rfc3548 com.informatimago.common-lisp.telnet com.informatimago.common-lisp.unix linc com.informatimago.lispdoc com.informatimago.lua com.informatimago.cocoa-playground com.informatimago.objcl com.informatimago.rdp com.informatimago.rdp.basic com.informatimago.rdp.basic.example com.informatimago.rdp.example com.informatimago.susv3 com.informatimago.common-lisp.tools.make-depends com.informatimago.xcode spartns xlunit = (WTF uninterned symbols, really?) #:author-email === somewhat useful piece of data #:date === You're never going to get anything but stale information here. (#:albert #:output-dirs) === An absolute pathname in a .asd? Braindamage! (#:albert #:formats) === should be moved to some albert-system class slots (#:albert #:docbook #:template) (#:albert #:docbook #:bgcolor) (#:albert #:docbook #:textcolor) (#:albert #:docbook #:dtd) *** portableaserve = (WTF The same albert thing, just incompatibly?) (system author email) (albert presentation output-dir) (albert presentation formats) (albert docbook dtd) (albert docbook template) !! Albert should probably use its own subclass to put its information *** com.clearly-useful.generic-collection-interface = :com.clearly-useful === whatever you're doing, use a subclass. *** metatilities = :ait-timeout :system-applicable-p === same comment *** ucw ucw-core = it.bese.ucw.system::version === WTF? use :version instead. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org On two occasions I have been asked [by members of Parliament!], `Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. — Charles Babbage ___ asdf-devel
Re: [asdf-devel] component-property
In 2.26.174, I added the following initargs to system with system-FOO accessors. I also added an :initform nil to all those optional metadata slots and previous ones. :long-name Another System Definition Facility :website-url http://common-lisp.net/projects/asdf/; :bug-tracker-url https://launchpad.net/asdf/; :developers-email asdf-devel@common-lisp.net :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) If there is more automatically-processable metadata for which you'd like a defined slot in ASDF3, now is the time to speak. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org What a lot of trouble to prove in political economy that two and two make four; and if you succeed in doing so, people cry, 'It is so clear that it is boring.' Then they vote as if you had never proved anything at all. — Frederic Bastiat, What Is Seen and What is Not Seen, 1850 ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] component-property
Dear Red, as a follow up to my previous email, I eventually added in 2.26.174 the following initargs to defclass system, with system-FOO accessors. :long-name Another System Definition Facility :website-url http://common-lisp.net/projects/asdf/; :bug-tracker-url https://launchpad.net/asdf/; :developers-email asdf-devel@common-lisp.net :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) The down side is that until ASDF2 is end-of-lifed, you'll have to #+asdf3 all these things either individually or together via e.g. (eval `(defsystem ... #+asdf3 ,@'(...) ...), (defsystem ... . #.(or #+asdf3 '(...)) or some other such ugliness. The upside is that with this standardization, odds are higher that this metadata can be used to automate processing of some sort across systems. If there are more slots that you need, now is a good time to suggest them. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org What a lot of trouble to prove in political economy that two and two make four; and if you succeed in doing so, people cry, 'It is so clear that it is boring.' Then they vote as if you had never proved anything at all. — Frederic Bastiat, What Is Seen and What is Not Seen, 1850 ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
(Replying in public to this private email; I hope this is not a faux-pas.) On Thu, Jan 31, 2013 at 11:23 PM, Daniel Herring dherr...@tentpost.com wrote: :long-name Another System Definition Facility :website-url http://common-lisp.net/projects/asdf/; :bug-tracker-url https://launchpad.net/asdf/; :developers-email asdf-devel@common-lisp.net :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) Slight ribbing: (:git ...) has the same problem as the original properties mechanism; it won't catch errors such as (:get ...) Indeed. An external tool with a documented specification is required here. But at least there's a clear intent and the beginning of an actual convention, and it all makes sense. You might have left the properties as-is and just added warnings when an unknown property name was used. Possibly. It's still time to have parse-component-form call a better validation function that does such checks, and otherwise have some allow-other-keys mechanism. See also https://bugs.launchpad.net/asdf/+bug/1007335 Meh. A good project for ASDF4, if anyone is foolish enough to undertake it. Actually bug https://bugs.launchpad.net/asdf/+bug/953489 reminds me that one could use #-asdf3 :allow-other-keys #-asdf3 t to say yeah, there are optional slots here that aren't defined before asdf3. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org No one has the right to a position; everyone has the right to positions being well filled. — Ernest Renan ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Fare On the other hand, now is a good time for me to add new slots to system objects. Fare I will add a website slot in 2.26.171, though you'll have to Fare #+asdf3 :website #+asdf3 http://xxx; for now. Does :website do anything other than record that info? If not, then why not use :url? I actually pushed 2.26.171 without adding any such slot yet. I'm open to debate on naming things. And I reinstantiated the previous properties interface for backward compatibility, until everyone adopts the new solution (which may take years). —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org The main difference between a computer salesman and a used car salesman is that the used car salesman can probably drive and knows when he's lying. - Peter da Silva ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] ASDF 3 news
Getting closer to release. The codebase is stable now, and I'm just making minor adjustments. Now at 2.26.164. I'm going to release 2.27 as soon as all tests pass on all implementations. The magic feature is #+asdf3, and 2.27 should be considered a pre-release. Hopefully by next month, after some testing, we can declare the next one to be ASDF 3.0. There were previously performance issues, with ASDF 2.26.152 being over 37 times slower than 2.26 at making a plan for iolib than it was before (3s vs .08s). After a day spent optimizing away a lot of truename queries and other pathname computations, ASDF is back at being 70% slower with default settings (while doing much more work behind the scene), and slightly faster if you disable all truename queries via (setf *resolve-symlinks* nil) -- but goodbye linkfarms if you do. After the last round of upgrade cleanups, hot upgrade now works without punting on recent versions of ABCL or CMUCL. But still not on CLISP. There seem to be various optimizations in CLISP FASLs that defeat everything I've tried so far except punting by renaming away the ASDF package as the very first thing. Many thanks to Stelian Ionescu, Stas Boukarev, Anton Vodonosov and Robert Goldman for their help with testing. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org You may easily play a joke on a man who likes to argue — agree with him. — Edgar Waston Howe ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF-USER ?
On Sun, Jan 27, 2013 at 12:13 PM, Robert Goldman rpgold...@sift.info wrote: On 1/26/13 Jan 26 -6:12 PM, Faré wrote: I think the whole temporary package thing is a failure, and we should just have an ASDF-USER package that uses ASDF. Does anyone have any objection to having .asd files be loaded in a shared ASDF-USER rather than a temporary ASDF~D package? If you want to define your own private functions in their private namespace, there's defpackage for you. I am sympathetic to your concerns here, but I am worried that it will cause lots of breakage. I have always done the old-school thing and defined a new package for my system definition. This makes for a pleasing symmetry between behavior where I incrementally evaluate forms, and when I load the system into an image. *HOWEVER*, some CL pundits seem to think that making extra packages is bad, and in a spirit of (to me, misguided) parsimony, strongly encouraged people to rely on the creation of the temporary packages. I fear that this means that loading all the package definitions into a single ASDF-USER package is likely to cause breakage from namespace collisions. Also, I fear that this will be a nuisance to catch in testing, because it is likely to require testing large numbers of *combinations* of loaded systems to simulate behavior downstream programmers might see. In my customary role as backward compatibility buzz-kill, I suggest that we keep the old behavior. I know that quicklisp is not *everything*, but I did a quick survey and found nothing clashy: A=( $(grep -L in-package ~/quicklisp/dists/quicklisp/software/**/*.asd) ) fgrep '(def' $A | grep -v 'defsystem\|defpackage\|defmethod \(asdf:\)\?\(perform\|operation-done-p\)' | less The most clashy thing I found was hemlock defining variables the name of which start with *hemlock- which actually seem perfectly fine to me. There are plenty of scary-looking definitions in optima.asd, but that's actually documentation in #| |#. I say anyone who does something clashy deserves the lossage he gets, and so do people who use his software. There is already plenty of namespace management around, ASDF cannot substitute to using proper namespace management techniques. And if Common Lisp is lacking in this regard, let's fix Common Lisp, not add a crock to ASDF. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Soccer riots kill at most tens. Intellectuals' ideological riots sometimes kill millions.— John McCarthy ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF-USER ?
On Sat, Jan 26, 2013 at 7:58 PM, Stelian Ionescu sione...@cddr.org wrote: I think the whole temporary package thing is a failure, and we What problems does it actually cause ? It causes having to maintain this weird system, having functions and classes the symbols of which become inaccessible, etc. It causes users having the wrong expectations and/or having to learn some magic semantics that do not apply to other cases. Why inaccessible ? Because the package was delete-package'd in an unwind-protect form after loading the .asd file, and its symbols are thereafter uninterned. * Using TRUENAME to simplify .asd management with a link farm. Big win at the time, though ultimately not scalable. I still use this and love it. Actually, I'd like to be able to be allowed to return to the old behavior where ASDF re-initializes the source registry on every find-system. Given that I only use quicklisp and a symlink directory on an SSD, that's preferable(I don't use the :directory scanning thing). I respect the *central-registry* feature and will keep supporting it. It's great for advanced developers like you. Don't want no caching? Keep using the *central-registry*, it's not going away any time soon. However, the caching is a big win for those of us who use :tree, especially on implementations on which scanning is slow. And that means most end-users and newbies, who want things to just work with minimal configuration (i.e. none at all if possible). —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org The ultimate result of shielding men from the effects of folly is to fill the world with fools. — Herbert Spencer ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF-USER ?
Because the package was delete-package'd in an unwind-protect form after loading the .asd file, and its symbols are thereafter uninterned. Then keep it, store it somewhere and perhaps delete it only when no longer referenced. I have no way to know when the package is not referenced. ASDF currently assumes nothing useful will be done with it after the asd is done loading. That's just wrong. I say stop trying to shield users from the responsibility of namespace management by making things more complex. They already need to create private packages for private uses, anyway, and they already can create all the clashes they want, anyway. I respect the *central-registry* feature and will keep supporting it. It's great for advanced developers like you. Don't want no caching? Keep using the *central-registry*, it's not going away any time soon. However, the caching is a big win for those of us who use :tree, especially on implementations on which scanning is slow. And that means most end-users and newbies, who want things to just work with minimal configuration (i.e. none at all if possible). That's fine, but I'd like to be able to disable caching. And I'm not using *central-registry* but this configuration: (:source-registry (:directory (:home lisp/systems)) :inherit-configuration) Maybe what you want is this: (defmethod asdf:operate :before (o c key allow-other-keys) (declare (ignorable o c)) (unless asdf::*system-being-operated* (asdf:initialize-source-registry))) I'm not convinced anyone but you wants this behavior, or I'd add a flag for it. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org A pretty face is not a passport; it's a visa and it runs out fast. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] distributing asdf
On Thu, Jan 24, 2013 at 9:58 AM, Zach Beane x...@xach.com wrote: Faré fah...@gmail.com writes: fare-matcher fails because FARE-UTILS does not designate any package. Oops, I had removed xcvb-utils, but still needed fare-utils (previous imported through fare-utils). This affects weblocks and other projects. This means that weblocks still didn't apply my patch getting rid of fare-matcher in favor of its worthy successor optima, in addition to .asd cleanups. Hopefully, the new ASDF is backward-compatible enough to work despite lack of such cleanups. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org #.(let((q`(#0=lambda(q)(labels((p(q)(if(atom q)(intern(#1=reverse(string q)))(#1#(mapcar #'p q(q(q)(subst q(eq q q)'(#2=defun p(aux #2#nufed ,@''#3=etouq(xua #3#)p tsil)((#0#(q)(setq q 't tsil q nufed(eval(list q (list'quote q)#3#)(nconc(q q)(p(q q)))(eval`(,q',q))) ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] distributing asdf
On Thu, Jan 24, 2013 at 11:41 AM, Zach Beane x...@xach.com wrote: By the way, this steady stream of oops, ooops, oops, oops, is causing me a huge, huge, huge headache. My apologies. I've been focusing so much on ASDF that I forgot to update all the systems I maintain that indirectly depend on it. Now (only) I've added an automated test that all these systems can still load correctly. The short life of asdf-utils is causing me a huge headache. asdf-utils still exists. Now it's just a thin wrapper over asdf-driver. I broke it briefly, thinking it had no clients (none showing in quicklisp); I didn't you of all people were using it, after your complaining that asdf should export utilities at all. The incompatibilities introduced in ASDF are causing me a huge headache. I've been working hard to resolve them. There's no way the old ASDF could be fixed without a complete rewrite, and that was bound to introduce some minor incompatibilities, especially in cases where clients software were exploiting unsupported interfaces or outright bugs. This is a very annoying mess from my perspective. I haven't really gotten a grip on what the benefits are to make this (temporary?) pain worth it. I'll publish a feature update shortly. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Advertising may be described as the science of arresting the human intelligence long enough to get money from it. — Stephen Leacock. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] New features in ASDF 2.27
I'm in the opinion that if you want W-C-U, you should do it yourself explicitly. However, for the sake of backward compatibility, and since you have a strong opinion otherwise, I'll restore the W-C-U :around perform-plan. The deferred-warning feature (currently on CCL and SBCL only) will continue working because it uses W-C-U (:override t). Now, if you would contribute deferred-warning support of ACL, that would be great. My apologies for the breakage. That's one big reason why I ask people to test before release. Thank you for testing. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org I think sex is better than logic, but I can't prove it. — Monty Python On Thu, Jan 24, 2013 at 7:50 PM, Robert Goldman rpgold...@sift.info wrote: I am heartened to see the many fixes to long-deferred bugs, particularly the system dependency fail. However, this ASDF is not ready for prime time, at least for use with ACL. Its behavior with ACL, because of getting rid of the WITH-COMPILATION-UNIT, is simply unacceptable. On all our well-formed ASDF systems, compilation now spews out huge numbers of false-positive undefined function warnings that used to be handled acceptably by the WITH-COMPILATION-UNIT. I really don't like the removal of W-C-U: it takes the normal ASDF use-case of single-process compilation and loading, and deprecates correct behavior there in order to achieve some improvements in a non-standard case of compiling lisp files in different processes, and to fix a problem with the less often used TEST-OP. So far, the fix here is worse than the disease, since it fails any number of good ACL systems. For example, I believe every one of my company's systems would fail its continuous integration testing using the new ASDF, because of the spurious warnings. At this point, I would have to advise implementations other than CCL and SBCL to decline to adopt 2.27, or to restore the WITH-COMPILATION-UNIT with some :AROUND methods. I don't like to see divergence among implementations like this, so I can think of two short-term expedients 1. push the WITH-COMPILATION-UNIT removal out onto a topic branch until the community can ensure that all supported implementations defer the warnings correctly, or 2. keep a single ASDF, and restore the WITH-COMPILATION-UNIT in a #-(or sbcl ccl) block. Add more implementations to the #- as we can support them. The advantage of 2 is that we can continue to test the new behavior on systems where it is implemented, and we have a single ASDF version; no forking. The advantage of 1 is that it better handles the situation if there are implementations where warning throttling *cannot* be made to work properly. In that case, I believe it's better to have a single behavior, even if suboptimal, instead of having a divergence in ASDF semantics between different implementations. Another reason we might prefer alternative 1 is that it is robust to finding other behaviors that require W-C-U. I don't understand the semantics thoroughly enough to know whether undefined entity warnings are all that we need to worry about. I will try to make a test that shows the bad behavior on ACL. Then we could see if this behavior happens on other CL implementations, and would have a criterion for good performance. Best, r ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Another problem with the warnings deferrel
On Thu, Jan 24, 2013 at 8:14 PM, Robert Goldman rpgold...@sift.info wrote: If you get an error in compilation, and rebuild the system, even on SBCL, it doesn't seem like the warnings lists get cleared At least I see ones that are clearly fixed reappear when I use the restart Each file's deferred warnings are now saved in a .sbcl-warnings file (respectively, .ccl-warnings). Unless you modify said file to remove any forward reference, the forward references will persist; however, those that are resolved by the end of the system compilation should not be shown at all, or it's a bug. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Passive hope is wishful thinking, a poison of the mind. Active hope is creative passion, the mover of the universe. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] distributing asdf
Now I get :ASDF does not match 2.26.114. Is that to be expected? OK, that was a message from cl-launch. I both improved the message, and scaled back the ASDF requirement to 2.015, with explicit loading of asdf-driver if old than that. While I was at it, I had exscribe stop requiring cl-launch, by importing the two needed cl-launch functions that were too klugy to make it to asdf/driver. Thanks again for the testing. PS: I made sure ASDF 2.26.142 works minimally on GCL 2.6, Genera and LispWorks, in addition to all the automatically tested implementations. ASDF 2.27 is coming close. Now to try to get cleaner upgrade on ABCL, CLISP, CMUCL, and make sure cl-grid-test comes clean. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Common Lisp makes it easy for you to grow your own language; however, it makes it difficult for that language to be the same as anyone else's. — Faré ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] distributing asdf
Now I don't get a package conflict, I get Your ASDF version is too old. I'm using 2.26. Is taht really too old? tldr: just update whichever libraries used to depend on xcvb-driver. Long version: That's message from xcvb-driver. I will make it clearer. Yes, on the one hand, 2.26 is too old for xcvb-driver. On the other hand, no program should be needing xcvb-driver anymore except xcvb itself (which is broken, in need of serious updating after the last year or so of asdf improvements; I just made a minimal adjustment so at least it compiles, and released that). Now that asdf-driver does everything that xcvb-driver did and much more as far as everyone but xcvb itself is concerned, all my systems that used to depend on xcvb-driver for its runtime support instead depend on asdf-driver. NB: The runtime support that used to be in xcvb-driver and is now in asdf-driver includes such things as: run-program, stream handling, condition muffling, environment access, command-line arguments, quitting, image dumping and restoring, etc. From the old asdf, asdf-driver also has pathname abstractions, encoding support, lisp compilation support, some generic configuration file support. And from two months of hacking, debugging, and automatic testing on 12 different implementations, asdf-driver has a more robust and self-sufficient version of all that, including a cleaned up API, a few general purpose utilities, and hot-upgradable package support. In other words, I would like asdf-driver to become a universally available portability layer to bridge the differences between all CL implementations. The minimal batteries included that all Lisps require to interact with the underlying operating system in a portable way. I used to miss a usable, portable run-program, or access to command-line arguments. Now I have all that. It sure makes for a simpler cl-launch. Lisp scripting sure is more fun than shell scripting. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Corollaries to the Law of Bitur-Camember: The political process destroys the value of all known resources that are up for grabs. The socialist process of systematically denying legitimacy to property rights applies the political process universally and destroys the value of all available resources. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] distributing asdf
When will that work? Right now many things still fail with the most recent updates of everything, e.g. fare-utils, rpm, cl-launch, exscribe, etc. I just fixed rpm, but apart from that, the other ones have already been fixed yesterday at most. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org We will never get the money out of politics until we get the politics out of money. — Alex Tabarrok ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] Upgrade issues
ABCL is one of the three implementations, together with CLISP and CMUCL, where I ultimately punted on ASDF hot-upgrade, by just trying to rename away the ASDF package if it's too old. I don't know if you're interested in making the kind of package surgery I was indulging in work, but it involves rehoming symbols from ASDF to subpackages such as ASDF/COMPONENT, including for class slot names. Anyway, please test the latest ASDF with ABCL, I think it's ripe for release, but I'd like your feedback considering the massive amount of hacking that happened. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org If the human mind were simple enough to understand, we'd be too simple to understand it. — Pat Bahn ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] clisp and asdf
On Mon, Jan 21, 2013 at 11:51 AM, Sam Steingold s...@gnu.org wrote:
* Faré snu...@tznvy.pbz [2013-01-20 22:46:35 -0500]:
Of all the lisp implementations, CLISP has given me the most trouble
with ASDF upgrade. Unlike all other Lisps, it won't let me undefine
functions and redefine them in the same fasl file. Somehow, I always
end up with CLISP either complaining that a function signature doesn't
match (was or wasn't a generic function with an incompatible
lambda-list), because I couldn't undefine it, or that it is undefined
and never redefined, because I undefined it and CLISP throws away my
redefinition somehow. I tried to selectively unintern symbols for
functions thus upgraded, but that also fails. Yet all these things
work in about all other Lisps.
In the end, I punted: I just rename the old ASDF package to
ASDF-${version} early on, but that messes with any package that :use's
ASDF, and then CLISP will complain again, unless ASDF is the very
first thing upgraded before anything uses it.
Could CLISP be made more upgrade-friendly?
When you actually do change function signatures, a warning is, IMO,
quite appropriate. I am not really sure why you want to silence them.
A warning when the signature changes is quite OK.
My problem is the unability to override the previous signature.
If I fmakunbound the function then redefine it in the same file,
it looks like the new definition never appears.
I will try to extract some reduced example.
(another thing I don't understand that may or may not be related is
the .lib output files produced together with a fasl,
when and how they are used, and what I should or should not do with them.)
http://clisp.org/impnotes/require.html#lib-files
Oh, that's cool. Does the .lib also include the user-supplied
(EVAL-WHEN (:COMPILE-TOPLEVEL) ...) side-effects?
If so, that's great -- it's like the CFASLs of SBCL
(except it probably pre-dates them).
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Die Mathematiker sind eine Art Franzosen: redet man zu ihnen, so übersetzen
sie es in ihre Sprache, und dann ist es alsobald ganz etwas anderes.
[Les mathématiciens sont comme les Français: quoiqu'on leur dise,
ils le traduisent dans leur propre langue, et cela devient alors
quelque chose de complètement différent.] — Johann Wolfgang von Goethe
___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] clisp and asdf
Of all the lisp implementations, CLISP has given me the most trouble
with ASDF upgrade.
Unlike all other Lisps, it won't let me undefine functions and
redefine them in the same fasl file.
Somehow, I always end up with CLISP either complaining that a function
signature doesn't match
(was or wasn't a generic function with an incompatible lambda-list),
because I couldn't undefine it,
or that it is undefined and never redefined, because I undefined it
and CLISP throws away my
redefinition somehow. I tried to selectively unintern symbols for
functions thus upgraded, but
that also fails. Yet all these things work in about all other Lisps.
In the end, I punted: I just rename the old ASDF package to
ASDF-${version} early on,
but that messes with any package that :use's ASDF, and then CLISP will
complain again,
unless ASDF is the very first thing upgraded before anything uses it.
Could CLISP be made more upgrade-friendly?
(another thing I don't understand that may or may not be related is
the .lib output files produced together with a fasl,
when and how they are used, and what I should or should not do with them.)
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Nostalgia isn’t what it used to be.
___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] deferred warnings in asdf, and more
Here's another one for James Knight: ASDF now correctly (I hope) saves undefined function warnings at compile-time in SBCL, to check them at the end of a system's build. All the low level support is in asdf-driver, and the necessary hooks in asdf-defsystem. This builds upon work by Douglas Katzman I had once again a *lot* of pain with pathnames, and the pathname compatibility file has soared in length to 1157 lines (not counting hundreds of related lines in os support). Go grab asdf 2.26.124 (also available separately as asdf-driver and asdf-defsystem). —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org You can learn many things from children. How much patience you have, for instance. — Franklin P. Jones ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Just pulled an update and now CCL fails the tests
Lovely. It's a case of merging with the *default-pathname-defaults* being #p and how I tried to limit the amount of truenaming but overshot. And while debugging it, running into more bugs in my code, and loveliness in the implementation such as (equal #pccl: #p/) == T. 2.26.120 is at your service. Now if only we can get a good run of tests, I'd like to release 2.27 as soon as things are stable. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Invente un aphorisme éclairant, et ton nom sera immortel. — Anonyme ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] distributing asdf
On Fri, Jan 18, 2013 at 6:12 PM, Zach Beane x...@xach.com wrote: Faré fah...@gmail.com writes: OK, so I've put in the archives/ directory of asdf a few tarballs. See: http://common-lisp.net/project/asdf/archives/ Would you consider adding an URL like asdf-driver-latest.tgz that will always refer to the latest version? Done: (defun link-archive () (run `(ln -sf ,(tarname (driver-name)) (,*clnet-asdf-public* archives/asdf-driver.tar.gz)) :show t :host *clnet*) (values)) While I'm at it, a present for foom, 2.26.119 will do its best to avoid resolving pathnames at all if *resolve-symlinks* is nil (please test with your setting). Does it also fix the issue with the asdf-utils package name conflict? Which way do you want the conflict resolved? The current resolution is that asdf-utils.asd is an empty system that depends on asdf-driver.asd, and asdf-driver has the nickname asdf-utils, and exports about everything useful that asdf-utils used to; I omitted a few things that have changed name, but I can provide compatibility functions with the previous backward API if there's a demand. If you think it's nicer to NOT have the same name, and/or to have asdf-utils a proxy package that imports and re-exports select symbols from asdf-driver, everything is possible. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Fraud is the homage that force pays to reason. — Charles Curtis ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] asdf-encodings?
On Tue, Jan 15, 2013 at 12:27 PM, Raymond Toy toy.raym...@gmail.com wrote: Is this the right place to talk about asdf-encodings? Apologies if this is the wrong place. This is the right place indeed. One minor issue with asdf-encodings and cmucl: It looks like find-implementation-encoding does not expect an error for unknown encodings, so for cmucl, the implementation should be #+cmu (ignore-errors (stream::find-external-format encoding)) Yes, I discovered as much while running the recently enhanced asdf's test-encodings and put an ignore-errors around the whole thing, for all implementations. Also, once asdf-encodings is loaded, compiles with asdf fail because cl:compile-file is called with :external-format set to the external format object instead of the name. To get the name from the object, use (stream::ef-name obj). I don't know where that should be applied. I tried something and it looks like it passes the test-encodings test. BTW, make test lisp=cmucl CMUCL=cmulisp passes 41 tests, but there are some warnings like loading level1/file1 Warning: compiling #STATIC-FILE test-module-pathnames sources/level1 level2/static.file completed without its input file #P/home/rtoy/src/clnet/asdf/test/sources/level1/level2/static.file There's some magic in some old tests that I haven't tried to figure out - I don't know who set up those directories, but apparently, some static files are expect that were removed or never committed, but that didn't use to cause problems when those files were ignored, which they are not anymore now that timestamps take them into account. I added the files, and it seems to have hushed the tests. Speaking of tests, I just added a 42nd test, but it fails on cmucl: the hello-world-example for producing a standalone program. My dump attempt has these errors, using an image from your distribution on a not-so-fresh ubuntu machine (to be upgraded RSN): [Saving current lisp image as executable into /home/tunes/cl/asdf/test/hello-world-example: [Writing core objects Read-Only: 27735760 bytes... Static: 4499880 bytes... Dynamic: 8192 bytes... done] Linking executable... [/ita/local/bin/./../lib/cmucl/lib/linker.sh: linking /home/tunes/cl/asdf/test/hello-world-example... /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../libdl.so when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../libdl.a when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/libdl.a when searching for -ldl /usr/bin/ld: cannot find -ldl collect2: ld returned 1 exit status done] —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Anything created must necessarily be inferior to the essence of the creator. — Claude Shouse (sho...@macomw.arpa) Einstein's mother must have been one heck of a physicist. — Joseph C. Wang (j...@athena.mit.edu) ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] fare-utils build failure
Cc'ng asdf-devel. On Wed, Jan 16, 2013 at 9:30 AM, Zach Beane x...@xach.com wrote: Faré fah...@gmail.com writes: How do I get asdf-driver? It's currently part of the asdf git tree. Should I make it separate? I think you can already include asdf-driver.asd without including asdf. What is the relationship between asdf-driver and asdf? What is a driver? asdf uses asdf-driver. asdf-driver is currently distributed as part of the asdf source tree, but if that is an issue, there is no barrier to splitting it apart. For bootstrap purposes, the source code of asdf-driver is transcluded into asdf.lisp as a prelude to asdf, so asdf can rely on it. asdf-driver is a general purpose portability and runtime management library. It provides various abstraction layers for packages, pathnames, command-line arguments, compilation, condition-muffling, run-program, image dump and restore with hooks, basic I/O, etc. Basically, it's all the portability work I did over the last few years as part of asdf and xcvb, so as to be able to run user code unchanged (above the abstraction layer) on all supported lisp implementations. When rpgoldman convinced me that a portable, usable run-program should be part of asdf, whereas the legacy run-shell-command is an unusable unmaintainable unfixable crock, I decided to pull in the implementation from xcvb-driver. At the same time, drewc convinced me that having plenty of smaller files, with one package per file, was a good idea. I have been haunted for a few years for having failed janderson when he proposed to split asdf in parts; yet now asdf.lisp is much bigger than it was then, and at the same, having integrated bundle operations and figured out the dependency mess means it's easier and safer to write a general purpose source-concatenation operation. Finally you (Xach) convinced me that ASDF itself should not be a utility library, but only a build system; at the same time I really need the portability library, for XCVB as well as for ASDF and for any portable CL code I write. To top it all, after having completely reimplemented ASDF several times, I have started feeling much more comfortable with taking it apart and reassembling it in better ways. So there. I split ASDF in parts, and the part that's not specific to the system definition facility has been separated into asdf-driver. On most implementations, you can upgrade asdf-driver on top of an old ASDF -- though I admit I haven't yet added this situation to my automated testing regime. (The outlier as usual is CLISP, which is very funky to upgrade, and I don't know how to do things short of deleting the ASDF package when there's an incompatibility, which isn't conducive to upgrading ASDF-DRIVER far beyond ASDF; but I have ideas on how to make things a little bit more usable.) —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org If I go through life free and rich, I shall not cry because my neighbour, equally free, is richer. Liberty will ultimately make all men rich; it will not make all men equally rich. Authority may (and may not) make all men equally rich in purse; it certainly will make them equally poor in all that makes life best worth living. — Benjamin Tucker ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] fare-utils build failure
On Wed, Jan 16, 2013 at 10:23 AM, Zach Beane x...@xach.com wrote: For nearly all other libraries, there is a repo or .tgz file I can download to package it up for Quicklisp. It would be nice if that was the case for asdf-driver, too. Sure. Which format do you prefer? If I remember correctly, you will want a directory asdf-driver-2.26.100/ containing the code. PS: I'm declaring asdf-utils and xcvb-utils obsolete and will be removing them. I've also stripped xcvb-driver of all its portability layer and will redirect my packages (such as inferior-shell) to use asdf-driver instead. I was sorely missing the pathname portability in xcvb-driver, and it has now been cleaned up and documented in asdf-driver. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Any sufficiently advanced bug is indistinguishable from a feature. — Rich Kulawiec ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] More test results
On Wed, Jan 16, 2013 at 10:48 AM, Robert Goldman rpgold...@sift.info wrote: ccl now passes. clisp fails to build ASDF successfully: clisp now passes. I've had a lot more package woes with it than with any other implementation, and I can't find a perfect way to upgrade with it. 2.26.103 passes the normal tests on CLISP, but only a fraction of upgrade tests. Insight or solutions appreciated. still 9 tests failing on Allegro 8.2: asdf-pathname-test.script test-force.script test-module-depend.script test-module-excessive-depend.script test-static-and-serial.script test-touch-system-1.script test-touch-system-2.script test1.script test3.script Only the first one poses problems to me, with a failure in realpath when deliberately trying to run resolve-symlinks on path that does not exist. I wonder how that test was working before, or why it broke. Adding an ignore-errors with a fallback value looks like it works. Meh. didn't bother with allegromodern yet... SBCL passes ECL goes ape-execrement, and goes into what looks like an infinite loop in error-handling on test test-retry-loading-component-1.script. Seemingly infinite flood of the following: I've fixed ECL, except for a weird problem while creating an executable. I'll have to ask help from the ECL guys on test-program.script. ABCL compilation failed for me: I'll test again with ABCL. Thanks a lot for the testing! —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org La superstition porte malheur. — Paul Carvel ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Status update on tests
Works for me. Were you running these tests at the same time? The two runs could interfere with each other. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Have the courage to take your own thoughts seriously, for they will shape you. — Albert Einstein On Mon, Jan 14, 2013 at 3:04 PM, Robert Goldman rpgold...@sift.info wrote: CCL fails on test-static-and-serial.script TEST ABORTED: These two expressions fail comparison with EQUAL: (FILE-WRITE-DATE FILE1) evaluates to 3567182153 DATE3 evaluates to 3567182002 Same failure on allegro. Allegro (8.2) has 6 failures all told: test-force.script test-static-and-serial.script test-touch-system-1.script test-touch-system-2.script test1.script test3.script On allegro there are a large number of date comparison failures. TEST ABORTED: the assertion (EQUAL (FILE-WRITE-DATE FILE1) DATE2) TEST ABORTED: These two expressions fail comparison with EQUAL: TEST ABORTED: These two expressions fail comparison with EQUAL: TEST ABORTED: the assertion ( DATE2 DATE1) failed. TEST ABORTED: These two expressions fail comparison with EQUAL: TEST ABORTED: the assertion (NOT (PROBE-FILE FASL2)) failed. More results as I can grab time to collect them. cheers, r ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Test results: one failure on CCL
Yes, to run this test, one needs asdf-encodings installed next to asdf. I've added a check to disable the rest of the test when asdf-encodings is missing. I've also made many, many improvements to the runtime part of ASDF, so it provides things like backtraces, image dump and resume hooks, controlled conditions, etc. It all started as having to dig again deep into the pathname compatibility, then the run-program compatibility, and I finally decided to just move all the remaining general-purpose parts of XCVB-driver into a layer of ASDF called ASDF/DRIVER. And I'm putting it to good use in the test support and in bin/bump-version which was re-written from an unholy mix of shell and perl to Common Lisp. I'm homesteading the package nickname :D for asdf/driver. PS: You may or may not like the magic macro (d:asdf-debug). In other news, after a coding marathon fighting package surgery issues, the ASDF looks like it's working and mostly stable, and I'm again going to look into trying it with cl-test-grid. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org The truth of a proposition has nothing to do with its credibility. And vice versa.— Robert Heinlein, Time Enough For Love ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] News on the front
Dear Lisp hackers, I've completed yet another major pass of refactoring of ASDF. It is now divided into many files, that are concatenated together for single-file delivery. (An idea that I once rejected when James Anderson proposed it 3 years ago; he might have known better. The file has more than quadrupled in size since.) From a pristine git checkout, you can concatenate them from the command-line with make build/asdf.lisp or from lisp with a recent bootstrapped asdf.lisp with (asdf:operate 'asdf::concatenate-source-op :generate-asdf) About 45% of ASDF is utilities, and those are now available through a semi-independent system asdf-driver. See make wc wc-driver wc-asdf. I'have notably moved in run-program/ from xcvb-driver, and its native-namestring support, by popular demand, which increased this number. I brought in the condition-control code and image support from xcvb-driver as well; I'll be working to package them better. Hot upgrade is preserved through the heroic development of define-package, an extension to defpackage that makes things as declared from however they were, instead of throwing an error at the first discrepancy. You better know what you want. As a result from this and all the package declarations, plus the bundle and concatenate support, ASDF has swollen 60% in size since 2.26, or 42% since I merged in asdf-bundle in 2.26.7. I'll argue that the functionality is also much improved, including the fixing of the fundamental build model that I've discussed in previous emails. I won't release anything until all the packages in quicklisp work, and I'll have to install cl-test-grid for that, but I invite those of you who are interested to test it and/or comment on the changes. It looks like I mostly understand ASDF these days. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Every technique is first developed, then used, important, obsolete, normalized, and finally understood. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] News on the front
On Fri, Jan 11, 2013 at 12:26 PM, Raymond Toy toy.raym...@gmail.com wrote: Is the plan that asdf is still delivered as one giant file or will it eventually move to being delivered as multiple files? Just curious. ASDF will still be delivered as one giant file. That's what makes sense for bootstrap purposes. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Instead of loving your enemies, treat your friends a little better. — Edgar Watson Howe ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF shipped with the latest Quicklisp-client doesn't work on Allegro CL 8.1
Dear Xf, thanks for the patch. On allegro 8.1, is it only compile-file-pathname that refuses the :external-format argument, or compile-file as well? In the latter case, how does allegro 8.1 control encoding for input files? Does it rely on a special variable? Maybe I should somehow predicate the :external-format arguments on #+asdf-unicode? Also, considering how far apart the release and master branch are, maybe I can issue a 2.26.0.1 in the release branch if that helps. PS: for those who're following the adventure, my latest woes in HEAD is with how deeply unhappy my package frobbing is making CLISP. There are also bugs I found in the new run-program/ for lispworks, but that's should be easy to fix. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org No one has the right to a position; everyone has the right to positions being well filled. — Ernest Renan On Fri, Jan 11, 2013 at 11:02 PM, Xiaofeng Yang n.akr.aki...@gmail.com wrote: I'm sorry for this duplicated mail. I forgot to write the subject for the previous mail . Hi, all The ASDF shipped with latest Quicklisp-client doesn't work on Allegro CL 8.1 correctly. So I fixed it and made an ugly patch for it. I'm so sorry I don't know whether this is the right place to discuss this problem, so I will then add this issus to the quicklisp-bootstrap project. The problem and patch can also be found here: https://github.com/nakrakiiya/acl-patches/commit/86236e11d89765a15fe44c0ede40119ed4958c3c#8.1/quicklisp-client-2012112500/asdf.lisp FIX: `Illegal keyword given: :EXTERNAL-FORMAT.' while executing `(quicklisp-quickstart:install)'. Details: CL-USER (quicklisp-quickstart:install) ; Loading D:\Documents and Settings\nakra\quicklisp\setup.lisp Illegal keyword given: :EXTERNAL-FORMAT. [Condition of type PROGRAM-ERROR] Restarts: 0: [RETRY] Retry compiling #CL-SOURCE-FILE quicklisp package. 1: [ACCEPT] Continue, treating compiling #CL-SOURCE-FILE quicklisp package as having been successful. 2: [RETRY] retry the load of D:\Documents and Settings\nakra\quicklisp\setup.lisp 3: [SKIP] skip loading D:\Documents and Settings\nakra\quicklisp\setup.lisp 4: [RECOMPILE-DUE-TO-INCOMPATIBLE-FASL] recompile D:\Documents and Settings\nakra\quicklisp\setup.lisp 5: [RETRY] Retry SLIME REPL evaluation request. --more-- Backtrace: 0: (ERROR PROGRAM-ERROR :FORMAT-CONTROL Illegal keyword given: ~s. :FORMAT-ARGUMENTS (:EXTERNAL-FORMAT)) 1: (COMPILE-FILE-PATHNAME x.lisp ..) 2: (ASDF:COMPILE-FILE-PATHNAME* #PD:\\Documents and Settings\\nakra\\quicklisp\\quicklisp\\package.lisp :OUTPUT-FILE ..) 3: (ASDF:COMPILE-FILE* #PD:\\Documents and Settings\\nakra\\quicklisp\\quicklisp\\package.lisp :OUTPUT-FILE ..) 4: ((:INTERNAL (METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) 0)) 5: ((METHOD ASDF::CALL-WITH-AROUND-COMPILE-HOOK (ASDF:COMPONENT T)) #ASDF:CL-SOURCE-FILE quicklisp package #Closure (:INTERNAL (METHOD ASDF:PERFORM #) 0) @ #x2143fc7a) 6: ((METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) #ASDF:COMPILE-OP (:VERBOSE NIL) @ #x213d60c2 #ASDF:CL-SOURCE-FILE quicklisp package) 7: ((:INTERNAL (:EFFECTIVE-METHOD 2 NIL NIL NIL NIL) 0) #ASDF:COMPILE-OP (:VERBOSE NIL) @ #x213d60c2 #ASDF:CL-SOURCE-FILE quicklisp package) 8: ((METHOD ASDF::PERFORM-WITH-RESTARTS (T T)) #ASDF:COMPILE-OP (:VERBOSE NIL) @ #x213d60c2 #ASDF:CL-SOURCE-FILE quicklisp package) 9: ((METHOD ASDF::PERFORM-WITH-RESTARTS :AROUND (T T)) #ASDF:COMPILE-OP (:VERBOSE NIL) @ #x213d60c2 #ASDF:CL-SOURCE-FILE quicklisp package) 10: ((:INTERNAL (:EFFECTIVE-METHOD 2 NIL NIL T T) 0) #ASDF:COMPILE-OP (:VERBOSE NIL) @ #x213d60c2 #ASDF:CL-SOURCE-FILE quicklisp package) 11: ((FLET (METHOD ASDF::PERFORM-PLAN (LIST)) EXCL::CONTINUATION)) 12: ((METHOD ASDF::PERFORM-PLAN (LIST)) ..) 13: ((:INTERNAL (:EFFECTIVE-METHOD 1 T T NIL NIL) 0) ..) 14: ((:INTERNAL (METHOD ASDF:OPERATE (T T)) 0)) 15: (ASDF::CALL-WITH-SYSTEM-DEFINITIONS #Closure (:INTERNAL (METHOD ASDF:OPERATE #) 0) [LOAD-OP] @ #x213d36da) 16: ((METHOD ASDF:OPERATE (T T)) ASDF:LOAD-OP quicklisp :VERBOSE NIL) 17: ((:INTERNAL (:EFFECTIVE-METHOD 2 T NIL NIL NIL) 0) ASDF:LOAD-OP quicklisp . 1) 18: (ASDF:OOS ASDF:LOAD-OP quicklisp :VERBOSE NIL) 19: (LET ((*COMPILE-PRINT* NIL) (*COMPILE-VERBOSE* NIL) (*LOAD-VERBOSE* NIL) (*LOAD-PRINT* NIL)) (ASDF:OOS 'ASDF:LOAD-OP quicklisp :VERBOSE NIL)) --more-- The diff from the origin asdf.lisp file: $ git diff 6d465f92b240fe5ded55447f9a000a1e54a7a22a 86236e11d89765a15fe44c0ede40119ed4958c3c diff --git a/8.1/quicklisp-client-2012112500/asdf.lisp b/8.1/quicklisp-client-2012112500/asdf.lisp index 283ad86..2f9b98a 100644 --- a/8.1/quicklisp-client-2012112500/asdf.lisp +++ b/8.1/quicklisp-client-2012112500/asdf.lisp @@ -2478,7 +2478,10 @@ recursive calls to traverse.) c #'(lambda (rest flags) (apply *compile-op-compile-file-function* source-file
Re: [asdf-devel] ASDF shipped with the latest Quicklisp-client doesn't work on Allegro CL 8.1
Dear Xiaofeng, assuming it's indeed a bug in allegro 8.1's compile-file-pathname, can you try to edit the call to compile-file-pathname this way, in defun compile-file-pathname* ? (apply 'compile-file-pathname input-file (remove-keys `(#+(and allegro (not (version= 8 2))) :external-format ,@(unless output-file '(:output-file))) keys)) —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Philosophy is questions that may never be answered. Religion is answers that may never be questioned. On Sat, Jan 12, 2013 at 12:48 AM, Raymond Toy toy.raym...@gmail.com wrote: Fare == Far Far writes: Fare Dear Xf, Fare thanks for the patch. On allegro 8.1, is it only compile-file-pathname Fare that refuses the :external-format argument, or compile-file as well? Fare In the latter case, how does allegro 8.1 control encoding for input Fare files? Does it rely on a special variable? Is this not a bug in Allegro's compile-file-pathname. The CLHS says compile-file-pathname should accept all keywords accepted by compile-file. The docs for Allegro 8.1[1] says compile-file accepts :external-format. Ray [1] http://www.franz.com/support/documentation/8.1/ansicl/dictentr/compile-.htm ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] CCL build failure
On Tue, Jan 8, 2013 at 2:36 PM, Robert Goldman rpgold...@sift.info wrote: CCL 1.8 on Mac OS X fails to compile asdf as pulled just now. Not-very-helpful transcript snippet: COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] Toplevel Forms... Toplevel Forms... Toplevel Forms... Toplevel Forms... ions of (:METHOD PERFORM (LOAD-OP CL-SOURCE-FILE)), in this file Testsuite failed: ASDF compiled with ERRORS Interactively, interestingly, when I try to build from an asdf:*central-registry* with home:lisp;asdf; in it, I get this error: Error while trying to load definition for system asdf from pathname home:lisp;asdf;asdf.asd.newest: Illegal logical namestring /Users/rpg/lisp/asdf/asdf.asd [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR] No idea what that's about. When I use /Users/rpg/lisp/asdf/ instead, it works fine. Whoa. Something funky is happening. Mind the logical. Something quite illogical is happening as the result of an attempted merge of pathnames with a logical pathname, presumably the home: thing. Can you explain me how logical pathnames are used on your machine and in your ASDF configuration? It's quite possible that I may have gotten some host defaulting mixed up somewhere. PS: I've exploded asdf into bits. See branch exploded on git. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Politicians are like diapers: they must be changed often. And for the same reasons. [Also, adults don't need either of them. — Faré] ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] deprecating run-shell-command
On Tue, Jan 8, 2013 at 11:09 PM, Daniel Herring dherr...@tentpost.com wrote: On Sun, 6 Jan 2013, Faré wrote: I will add a concatenate-all-source-op that recursively descends into all system dependencies, concatenates all sources, and creates the output file asdf.lisp, also including defsystem fallback stubs to make upgrade easier, just like the current asdf defsystem fallback stub. This way, ASDF can enjoy the advantages of both a large set of small libraries and a single-file bootstrap solution. Also, adding new extensions to ASDF will be easier. It's done in branch exploded, which also creates one package per file, in the style of faslpath and/or quick-build. I can't merge it to master until I write a variant of defpackage that will make the thing survive hot upgrade, but it's already a major cleanup. For the first time ever, ASDF sources are well-organized and mostly readable — and they are much more correct/robust, too. That sounds like it could be a very useful feature in general. For example, it would allow any program to be distributed with its all dependencies in a single source file. Yes, with limitations: 1- you mustn't rely on load-time effects of previous files during the compile-time of your file, unless they've been explicitly wrapped in an eval-when. 2- all your files must have the same encoding. 3- if you have an around-compile hook, it must apply to all files, and be already defined in some specially loaded prelude. Also, I don't currently register fake/fallback systems for transcluded dependencies. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org If you don't like yourself, you *can't* like other people. — Robert Heinlein, Time Enough For Love ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ql-test
On Sun, Jan 6, 2013 at 5:59 AM, Anton Vodonosov avodono...@yandex.ru wrote: 06.01.2013, 08:02, Faré fah...@gmail.com: Dear ASDF developers, so as to not issue ASDF release candidates that are totally bogus anymore, I've written this program, ql-test, inspired by ql-mapper: ssh://common-lisp.net/home/frideau/git/ql-test.git Maybe some of you will be interested in this infrastructure. I'm currently grovelling its output to determine breakage is caused by ASDF 2.26.55. Already sent a patch to chipz. Will send more. Hello. ql-test resembles very closely what I do in cl-test-grid - try to load every system in quicklisp and run some tests. Sorry to tell it only after you implemented ql-test, I thought to factor out some lower level functions for you to use before proposing cl-test-grid. Dear Anton, Oh that would be nice. I wanted something quick and dirty, and that did it. But presumably, I should be using cl-test-grid instead in the future. BTW, I believe the lisp-invocation.asd way of invoking things is better: of course it allows one to specify paths to executables, but by default, it just relies on your using standard or semi-standard names for the executables, and having them in your $PATH. Presumably, if you have those implementations installed, you needed to set them up in your $PATH for them to be usable, anyway. That usually means less headache for configuration. Based on the above, it's also trivial to autodetect the presence of an implementation, by running some code that prints stuff and exiting. XCVB for instance prints various bits of information like *features* and asdf::implementation-string and path to image, etc., to identify the beast if present. See xcvb/extract-target-properties.lisp (which unlike lisp-invocation.asd hasn't been isolated from the rest of xcvb). This also minimizes the amount of configuration required. Less configuration is better. In the spirit of library consolidation, I also believe my lisp-invocation and your lisp-exe should be consolidated together. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org 'Need' now means wanting someone else's money. 'Greed' means wanting to keep your own. 'Compassion' is when a politician arranges the transfer. — Joseph Sobran ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] deprecating run-shell-command
Dear Robert, regarding ASDF and libraries, I think I have a solution that will satisfy everyone. I will adopt the plan once proposed by James Anderson, back when ASDF was one third the size that it is now: split ASDF into many parts, and programmatically reconstitute it into a single source file for bootstrapping purposes. Now that ASDF is bigger, this makes even more sense than it did then. Now that ASDF includes ASDF-BUNDLE, it is easier to do that it used to, in a way that is well-managed by ASDF itself. Therefore, I will split ASDF into several libraries. These libraries will each get their own .asd file, and can each be upgraded separately. I will add a concatenate-all-source-op that recursively descends into all system dependencies, concatenates all sources, and creates the output file asdf.lisp, also including defsystem fallback stubs to make upgrade easier, just like the current asdf defsystem fallback stub. This way, ASDF can enjoy the advantages of both a large set of small libraries and a single-file bootstrap solution. Also, adding new extensions to ASDF will be easier. XCVB's RUN-PROGRAM/ will be in one of these libraries. RUN-SHELL-COMMAND will be made a thin wrapper around it, and moved to a separate backward-compatibility file, where all functions are marked obsolete, do not use, and given an expiration date (say, two or three years afterwards). However, making sure everything in Quicklisp compiles properly and releasing 2.27 takes precedence over this refactoring. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org The last ten percent of any reform is the most difficult to achieve. Moreover, it is often harmful. — John McCarthy On Sun, Jan 6, 2013 at 11:45 AM, Robert Goldman rpgold...@sift.info wrote: I know why we have done this, but I deeply regret it. ASDF claims to be able to do things like build C code to be linked into lisp systems. It cannot do this without something like ASDF:RUN-SHELL-COMMAND. I understand that XCVB-DRIVER:RUN-PROGRAM is proposed as an alternative, but this adds a dependency chain to ASDF in a way that I feel to be unfortunate. Even though it will make ASDF bigger, I would like to see ASDF:RUN-SHELL-COMMAND (or RUN-PROGRAM) get undeprecated, possibly by having ASDF eat its own copy of XCVB-DRIVER:RUN-PROGRAM. I understand the history of CL enough to know why RUN-PROGRAM was not in the original ANSI spec, but now that CL has moved to general-purpose computers, I think it's something that we need to provide integrally. And putting it into ASDF is as close as we can come to doing that. [As an aside, I can see the tidiness advantage of shattering the full set of functions into a large set of smaller libraries. However, this makes configuring a reasonably sized CL software development project into a chore of herding a very large set of small libraries. This is not something that our community has the person-hour resources for -- many of our libraries fall into an un-maintained state. Philosophically, I have a bit of a beef with this position, too --- this is, after all Common Lisp, and not Scheme.] Cheers, r ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] An interesting ASDF conundrum
Unhappily, ASDF as it stands follows a plan then perform model that does not allow for interleaving dependency detection and computation. The best it can provide is to have two stages, with a second-stage system that :defsystem-depends-on the first-stage system for each step that requires such interleaving, with the loading of the first stage causing all the effects needed for the second stage. Unwieldy, but that's all you can do with ASDF. NB: in the new ASDF 2.27, OPERATION-DONE-P will be a boolean that complements the builtin stamp computations. Make it T normally, NIL if there's a reason *besides* timestamps to invalidate the previous computation. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org It may be bad manners to talk with your mouth full, but it isn't too good either if you speak when your head is empty. On Sun, Jan 6, 2013 at 5:24 PM, Robert Goldman rpgold...@sift.info wrote: This would be coupled (here's the icky part) with a PERFORM method that does nothing, because by the time it's invoked the make will already have run. That's not the icky part. The icky part is OPERATION-DONE-P lying to ASDF. I have been mulling this over, and here's what is interesting to me about this case: The ASDF protocol has OPERATION-DONE-P, which is used as NOT-OPERATION-NEEDS-DOING-P. I.e., if it returns a non-NIL value, when applied to operation O and component C, we may skip doing O on C. For my MADE-FILE, I cannot[*] compute the answer to this question: all I can do is compute a conservative bound on OPERATION-NEEDS-DOING-P. In fact, all I can compute is a degenerate bound: I assume that OPERATION-NEEDS-DOING-P is always true. Now, let's assume we have another operation, O', and component C', and we have to do O'(C') if O(C) did something. The problem here arises because ASDF assumes DID-SOMETHING-P(O,C) == OPERATION-NEEDS-DOING-P(O,C). That is, ASDF assumes that if it BELIEVED it needed to do O to C, then something will have changed AFTER it does O to C. In the case of a MADE-FILE (and some other possible ASDF components?), this is not the case. Since we are conservative about whether or not O(C) needs doing, sometimes we are wrong and after we apply O to C, nothing has changed. Furthermore, for MADE-FILE, it is possible to examine the filesystem *AFTER* O(C) and determine a *better answer* to the DID-SOMETHING-P query than we can for OPERATION-NEEDS-DOING. Unfortunately, there's no room in the ASDF protocol to do this. But it would not be impossible to modify the protocol to make it happen, and this could be done in a backwards-compatible way, by having OEPRATION-DID-SOMETHING return the value of OPERATION-DONE-P before the operation by default... I'm not sure that this is worth doing: it would depend on whether there are enough interesting cases where OPERATION-DONE-P (approximate!) and OPERATION-DID-SOMETHING diverge. cheers, r ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] asdf bundle and do-first
Dear CL hackers, this issue with needed-in-image vs not dependencies is solved in 2.26.51; a new refactoring of traverse was required, which led to new simplifications afterwards. It's simpler than ever despite doing more (and more correctly) than ever — see function traverse-action for the substance. POIU was updated, and once again, making POIU work helped make the ASDF code much better, and once again, some of antifuchs' code that I had once deleted anticipated things I ended up needing. I *really* hope 2.27 will be the last deep refactoring of ASDF internals that's ever needed. Now I'll go back to fixing any ASDF client that depends on obsolete behavior so I may release at long last. I hope this release can then make it to ECL, killing asdf-bundle and asdf-ecl, as well as to other implementations. PS: For very bad reasons, I resurrected the GCL 2.6 port, which sadly is lacking support for output-translations (lack for pathname-match-p). —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org When you've seen one nuclear war, you've seen them all. On Mon, Dec 31, 2012 at 12:57 PM, Faré fah...@gmail.com wrote: Another conceptual bug in ASDF. Checking the plans generated for load-fasl-op, I find that with my new ASDF 2.26.x (currently x=45), it systematically loads all the individual .fasl's before it loads the .system.fasl, defeating the purpose. This was not the case before: in 2.26.7 and earlier, the (separately distributed before 2.26.7) asdf-bundle has load-fasl-op depend-on fasl-op which depends-on compile-op, which doesn't depend-on load-op, but do-first's on it — so that the dependency is only considered but if the immediate timestamp of the fasl is older than the timestamp of its lisp source. If all fasl's satisfy this local timestamp check, nothing is recompiled, none of the do-first is triggered, and the load-op's are not attempted. But the old design also fails to propagate timestamp information from the other files that are depended-on, let alone do-firsted. Therefore, there is some notion in the old do-first that must be preserved in the new ASDF, even though the previous design was conceptually flawed overall. In the end, what must be preserved is that some dependencies need to have been performed in the current image, whereas other dependencies only need to have been performed in some previous (or current) image. This means a dependency can be walked over twice: once in without image-necessity, and a second time with it. Without image-necessity, only the timestamp matters; with image-necessity, whether it was performed in current image matters, too. Presumably, a node with output-files clears the image-necessity flag before checking timestamps, but re-traverses its dependencies with the flag if the timestamp check fails. A node with no output-files on the other hand is done for in-image effect, and heeds and propagates the image-necessity flag to its subnodes. I believe that it's possible to continue the current strategy of traversal without an explicit graph, though nodes may now be traversed twice: once without image-necessity, once with. Sigh. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Success is getting what you want. Happiness is wanting what you get. — Dale Carnegie ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 2.27 release candidate
Do you have failure logs I can inspect? I build each of the hundreds of Quicklisp systems in alphabetical order. Perhaps some state created by that mechanism is triggering the problem in a way that doesn't happen when building a system in isolation. I'll try to create an easy-to-reproduce test case that illustrates the failures I'm seeing. Dear Zach, Can you teach me how to use qlmapper to run the tests myself on my home machine? This way I can try every time I do a potentially incompatible change to ASDF, and before each release. PS: 2.26.50 fixes some issues with force and force-not, which were causing spurious attempts to rebuild sb-posix when required rather than loaded. It that was the symptom of your failures, please try again with the latest (currently 2.26.51). —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org An apple every eight hours will keep three doctors away. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] asdf bundle and do-first
Another conceptual bug in ASDF. Checking the plans generated for load-fasl-op, I find that with my new ASDF 2.26.x (currently x=45), it systematically loads all the individual .fasl's before it loads the .system.fasl, defeating the purpose. This was not the case before: in 2.26.7 and earlier, the (separately distributed before 2.26.7) asdf-bundle has load-fasl-op depend-on fasl-op which depends-on compile-op, which doesn't depend-on load-op, but do-first's on it — so that the dependency is only considered but if the immediate timestamp of the fasl is older than the timestamp of its lisp source. If all fasl's satisfy this local timestamp check, nothing is recompiled, none of the do-first is triggered, and the load-op's are not attempted. But the old design also fails to propagate timestamp information from the other files that are depended-on, let alone do-firsted. Therefore, there is some notion in the old do-first that must be preserved in the new ASDF, even though the previous design was conceptually flawed overall. In the end, what must be preserved is that some dependencies need to have been performed in the current image, whereas other dependencies only need to have been performed in some previous (or current) image. This means a dependency can be walked over twice: once in without image-necessity, and a second time with it. Without image-necessity, only the timestamp matters; with image-necessity, whether it was performed in current image matters, too. Presumably, a node with output-files clears the image-necessity flag before checking timestamps, but re-traverses its dependencies with the flag if the timestamp check fails. A node with no output-files on the other hand is done for in-image effect, and heeds and propagates the image-necessity flag to its subnodes. I believe that it's possible to continue the current strategy of traversal without an explicit graph, though nodes may now be traversed twice: once without image-necessity, once with. Sigh. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Success is getting what you want. Happiness is wanting what you get. — Dale Carnegie ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] trivial-timeout patch
Dear Gary, here is a patch to trivial-timeout to prevent unnecessary recompilation, now that ASDF actually propagates timestamp information based on static file dependencies. It basically fixes the .asd file to not reference non-existing files, so that the absence of those files doesn't cause ASDF to systematically force compilation of everything afterwards. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Tunes: because C is not the be all and end all of system programming languages a.diff Description: Binary data ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 2.27 release candidate
On Fri, Dec 28, 2012 at 10:55 AM, Zach Beane x...@xach.com wrote: Faré fah...@gmail.com writes: OK, so 2.26.45 is my new release candidate for ASDF 2.27. Please grab it and test it. It still breaks gbbopen and fset. Ouch. I will work with the authors to resolve these issues. FSet clearly relies on buggy behavior for no good reason, and the author was provided a simple patch. I'll work with the authors of each failing package to get a fix in before I release. It still seems to trigger the package-at-variance issue in weblocks and other projects. OK, I will try to build everything with qlmapper before I issue a new release candidate. If the new ASDF isn't backwards-compatible with existing projects, I'm not inclined to update the ASDF that Quicklisp fetches any time soon. Indeed and for good measure. I won't consider ASDF ready for release until all maintained packages work with it. Thanks for the testing and apologies for the brokenness. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 2.27 release candidate
GBBopen from svn trunk r1168 works fine for me using ASDF 2.26.45, with or without the attached cleanup patch. rlwrap sbcl --eval '(quote(#.(require asdf)#.(in-package :asdf)#.(upgrade-asdf)#.(load /home/tunes/quicklisp/setup.lisp)#.(progn(load-system :gbbopen))#.(cl-user::gbbopen-test)))' rlwrap sbcl --eval '(quote(#.(load /home/tunes/cl/asdf/asdf)#.(in-package :asdf)#.(upgrade-asdf)#.(load /home/tunes/quicklisp/setup.lisp)#.(progn(load-system :gbbopen))#.(cl-user::gbbopen-test)))' Note: the first cleanup in the patch, with subpathname, is not really necessary and depends on ASDF 2.018 from October 2011. What are you trying and what error are you getting? Granted, the build infrastructure of GBBopen dates from ASDF1 days, but really, a lot of it is just reinventing things that were done I believe better and for everyone in ASDF2, and GBBopen should probably adopt and embrace it. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org A real person has two reasons for doing anything ... a good reason and the real reason. On Fri, Dec 28, 2012 at 3:50 PM, Robert Goldman rpgold...@sift.info wrote: On 12/28/12 Dec 28 -9:55 AM, Zach Beane wrote: Faré fah...@gmail.com writes: OK, so 2.26.45 is my new release candidate for ASDF 2.27. Please grab it and test it. It still breaks gbbopen and fset. On the Mac with ACL and SBCL, the new ASDF works equally well/equally poorly (compared with the packaged ASDF) with GBBOpen from subversion: loading the system inappropriately dumps my SLIME repl into the SWANK package, and requires a call to (cl-user::gbbopen-user) to get into what seems like a sane state. But it seems to build fine. What's happening for you? r a.diff Description: Binary data ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] ASDF 2.27 release candidate
OK, so 2.26.45 is my new release candidate for ASDF 2.27. Please grab it and test it. Since last release candidate 2.26.24, * lots of work was done towards backwards compatibility, fixing bugs introduced or uncovered during the previous fixing of essential conceptual bugs through massive refactoring of internals. * tests were added for asdf-bundle, which now also runs on XCL, but not on ECL with bytecode compiler. * tests were ran on all platforms with a command line on Linux x86-64 and even on LispWorks Personal Edition and Genera that don't, and they all pass modulo a few implementation bugs that were #-'ed out. * upgrade tests were also made to pass everywhere that's meaningful * consequent minor fixes to warnings or corner case errors were issued for Allegro, CLISP, ECL, ECL with bytecode compiler, SBCL, XCL. * There was a fix for LispWorks Personal Edition. You need to update ironclad and nibbles to run with the new ASDF because of the dropped if-component-dep-fails feature, but all other software should continue to run unmodified. Since release 2.26, the main changes are as follows: * ASDF-BUNDLE was merged into ASDF. This notably means fewer headaches for users of ECL; it also means a new load-fasl-op feature for all users of a modern CL, making it easier to deliver software as a single fasl. All remnants of its predecessor asdf-ecl were removed. * *decades-old* bugs of notable significance were fixed: (a) changes in dependencies now trigger a rebuild across systems, and https://bugs.launchpad.net/asdf/+bug/479522 (b) timestamps are now correctly propagated https://bugs.launchpad.net/asdf/+bug/1087609 In olden days, some have argued for not rebuilding systems that :depend-on a modified one as a feature. It really isn't. On the other hand, if they want to explicitly prevent a rebuild, the actual feature :force-not is there to help them (released as part of 2.21 in April 2012). I will write about those bugs. * PREPARE-OP was introduced to fix a conceptual bug in the ASDF object model. It corresponds to loading the dependencies of a component and its parents and is explicitly depends-on'ed before to load or compile the component, instead of implicitly depending on it via magic in the TRAVERSE algorithm, which magic proved insufficient in cases revealed by the above bugs. It propagates upward in the component hierarchy, rather than downward, like the TRAVERSE algorithm used to systematically propagate dependencies. * TRAVERSE was gutted out and factored into reusable higher-order functions, which not only fixes the above conceptual bug, but makes for semantics that are simpler to implement, possible to understand, easier to extend, and less limited in expressivity. TRAVERSE doesn't automatically propagate operations downward the component hierarchy anymore; propagation is now implemented through methods on COMPONENT-DEPENDS-ON. * COMPONENT-DEPENDS-ON is now more powerful: it can express dependencies on arbitrary operation objects (i.e. operations of the same class can have different options) acting on arbitrary component objects (i.e. not necessarily siblings of the current component). The ASDF object model can now express arbitrary build graphs, with special magic no more for children components vs other dependencies. * Internals have been refactored, and some sorry features were excised. The semantics of OPERATION-DONE-P is simplified and now well-specified. The dubious DOFIRST mechanism is gone. FIND-COMPONENT will pass component objects through, and a corresponding FIND-OPERATION replaces MAKE-SUB-OPERATION. Several internal accessors were renamed. * IF-FEATURE is a new attribute of components that accepts an arbitrary feature expression such as (:and :sbcl (:or :x86 :x86-64)), which when defined is a precondition to the component being enabled; when the expression is false, the component is disabled, and dependencies to it are removed. It replaces the misguided :if-component-dep-fails attribute of modules and the accompanying :feature feature, which were dropped. They were not very expressive, clunky to use, and relied on baking conceptually dubious non-local behavior in the old TRAVERSE algorithm, which belied the object model and defeated other features. Unhappily, this breaks backwards compatibility for the few who used it, namely sb-grovel, nibbles and ironclad. A minimal compatibility layer allows ASDF 2.27 or later to load the SB-GROVEL of old versions of SBCL, but it won't suffice to load an old version of nibbles or ironclad; please upgrade them a recent version that was updated to support ASDF 2.27. * ASDF2.27 was added to the *features* so you can detect the presence of this massively updated ASDF and its new features with #+asdf2.27. This is
Re: [asdf-devel] failures with 2.26.36
In the meantime, I've moved the parent slot from child-component to component, to improve backward compatibility. With this change, hu.dwim.reiterate and lisp-executable-example also pass. Has the change been pushed yet? Oops. I've clearly been lacking in sleep. Pushed. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org In reviewing the history of the English Government, its wars and its taxes, a bystander, not blinded by prejudice nor warped by interest, would declare that taxes were not raised to carry on wars, but that wars were raised to carry on taxes. — Thomas Paine, Rights of Man ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] File type problem with the latest ASDF
Scott, here's a trivial patch that makes fset compile to me. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Suppose 2/3 Congress were incinerated, what would we lose to offset our gain of their salaries and the salaries of their parasites? — H. L. Mencken fset-asdf.diff Description: Binary data ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] File type problem with the latest ASDF
My bad. I tried to remove the default type on source-file; obviously, it's too late and many systems use it already. Restored it to nil in 2.26.35. For next time I'm ill-inspired like that, is there a way to load everything *that's suppose to work* in quicklisp? I found I could try to load everything with: (time (dolist (s (quicklisp-client::provided-systems t)) (quicklisp:quickload (ql-dist:name s but it fails with things like abort-ks-execution-example. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org When all lawful citizens are disarmed, will we have an omnipresent police state to protect us from armed criminals? On Wed, Dec 19, 2012 at 9:30 AM, Zach Beane x...@xach.com wrote: Zach Beane x...@xach.com writes: A number of projects fail to build with the latest ASDF from git. A few of them seem to be related to defining a custom file component class that has a custom file type. For example, see jwacs and portable aserve: [snip] CommonQT's failure: qt.asd: The slot TYPE is unbound in the object #MAKEFILE qt commonqt.pro. Zach ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] File type problem with the latest ASDF
The FSet failure is due to its using (:system misc-extensions) amongst its components. That's always been invalid, I wonder how it could ever possibly work, and I'm not willing to kluge ASDF into keeping supporting it. misc-extensions is already present in the depends-on, which is the correct place for it to be. Scott, can you fix that? Just remove that bogus component. PortableAserve and Jwacs and probably many others were failing because they use an ASDF1-only recipe for defining source-file type, unhappily propagated by the asdf.texinfo itself (mea culpa), which broke when I made system not inherit from module anymore. Sigh. I reluctantly restored system as a subclass of module for now (2.26.36), but I'll be contacting the authors so they fix their system definitions. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org For pretty much every writer, the big problem isn't piracy, it's obscurity. — Tim O'Reilly, as cited by Cory Doctorow ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] suggestion for aserve.asd
On Wed, Dec 19, 2012 at 4:57 PM, Robert Goldman rpgold...@sift.info wrote: You don't need acl-file any more. You can now use cl-source-file.cl, which is exported from ASDF. You can make legacy-acl-source-file inherit from cl-source-file.cl and cut the ACL-FILE class entirely. That will take care of using the .cl extension instead of .lisp. Actually, an acl-file is still required, because there's a method on perform. On the other hand, that method needs to be changed to play well with asdf-output-translations, and could simply be an :around method to (handler-bind (((or style-warning warning) #'muffle-warning)) (call-next-method)) or something (untested). —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Exploitation is a word often used but rarely defined. In its most literal meaning — I 'exploit' you if I in some way benefit from your existence — it is the reason human society exists. We all benefit from one another's existence. We all exploit each other. — D. Friedman, The Machinery of Freedom ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] prepare-op
On Tue, Dec 18, 2012 at 8:46 AM, Zach Beane x...@xach.com wrote: Faré fah...@gmail.com writes: On Mon, Dec 17, 2012 at 2:19 PM, Christophe Rhodes cs...@cantab.net wrote: Zach Beane x...@xach.com writes: Faré fah...@gmail.com writes: OK, this is now committed as of ASDF 2.26.21 and POIU 1.29.3. It's slightly smaller, it's much cleaner, and it all works. I hope I have not broken users — please test. Casualties of the cleanup were :feature and :if-component-dep-fails. They were just horrible things. FYI, the sb-rotate-byte contrib in SBCL uses :if-component-dep-fails. What is the correct way now to indicate that a file is part of a system, but should only be compiled if a given feature is present? It appears that the SBCL contrib SB-ROTATE-BYTE uses :IF-COMPONENT-DEP-FAILS. In the spirit of not breaking everyone's existing SBCL installation, I have implemented *limited* compatibility with :IF-COMPONENT-DEP-FAILS in ASDF 2.26.27, sufficient to cover the usage observed in the wild. I'm trying to build my software with 2.26.28, and I get this: ASDF could not load sb-cover because error opening #P/usr/local/lib/sbcl/sb-md5/md5-ASDF-TMP.fasl: Permission denied. What should I do? It works for me. I suspect you might not have compiled sb-md5 from clean, and due to that bug I fixed in 2.26.9 which required a substantial refactoring, ASDF can now see that file was not up-to-date, when it couldn't see it earlier. Can you recompile this contrib from clean, either in place (by getting proper access rights) or in another directly from which you reinstall afterwards? —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Nostalgia isn’t what it used to be. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] prepare-op
It works for me. I suspect you might not have compiled sb-md5 from clean, and due to that bug I fixed in 2.26.9 which required a substantial refactoring, ASDF can now see that file was not up-to-date, when it couldn't see it earlier. Can you recompile this contrib from clean, either in place (by getting proper access rights) or in another directly from which you reinstall afterwards? What does compile from clean mean? What's a way to *not* compile from clean? Good question. When you build SBCL from source, update it then build again, does it remove the fasls in the contrib before to build them, or does it rely on ASDF for only compiling what's needed? In the latter case, this will may produce an unclean installation. Then, because sb-md5.asd was recently updated, and ASDF now (since 2.26.21) sees that as requiring .fasls to be updated (in case the dependencies have changed in a crucial way). If you clean.sh then make.sh your SBCL, it should all work. Another explanation would be if the installation process of SBCL does not preserve timestamps, in which case ASDF will be very unhappy about it, which it wouldn't have been before if all fasl's happened to have been written at the same time as their lisp source file or before. I believe the tar and untar'ing by which things are installed preserves the timestamps, though (and was designed precisely for this purpose to be fulfilled portably without relying on GNU install). FYI, here's a simplified way to reproduce it. From the ASDF source directory, with the latest checkout: sbcl --non-interactive --no-userinit --load asdf.lisp --eval (require :sb-md5) This lands in the debugger with the permissions error on three different SBCL installations of mine. Am I doing something wrong? Note that indeed, one of my installations had to be recompiled that way, so whichever explanatino there is, I suppose the problem is pervasive with SBCL. I don't know what to say, except: if you've been installing SBCL from updated source, you might have to recompile some contrib. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org If all values are relative, then cannibalism is a matter of taste. — Leo Strauss ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] prepare-op
OK, I understand the bug that Xach found: There was an ancient bug whereby input-files for a module always returned a singleton list containing the module's component-pathname, its directory. That wasn't an issue then due to the even greater deep design flaw of timestamps not being propagated. Since the latter bug was fixed, the former popped its ugly head. Because SB-ROTATE-BYTE has a module (a fake one for the purpose of using :if-component-dep-fails), ASDF wanted to recompile it, which fails. If you have a fast compiler and you don't install, the entire thing can be compiled in under a second, and the timestamps for all the fasls and directory are the same. But after you install, the directory timestamp is older, and you are sure to lose. Anyway, this should be fixed in 2.26.33. My apologies for the breakage. Software is hard. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Truth comes as conqueror only to those who have lost the art of receiving it as friend. — Tagore ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] prepare-op
On Tue, Dec 18, 2012 at 5:01 PM, Faré fah...@gmail.com wrote: OK, I understand the bug that Xach found: There was an ancient bug whereby input-files for a module always returned a singleton list containing the module's component-pathname, its directory. That wasn't an issue then due to the even greater deep design flaw of timestamps not being propagated. Since the latter bug was fixed, the former popped its ugly head. Because SB-ROTATE-BYTE has a module (a fake one for the purpose of using :if-component-dep-fails), ASDF wanted to recompile it, which fails. If you have a fast compiler and you don't install, the entire thing can be compiled in under a second, and the timestamps for all the fasls and directory are the same. But after you install, the directory timestamp is older, and you are sure to lose. Anyway, this should be fixed in 2.26.33. My apologies for the breakage. Software is hard. Actually, the reason I wasn't seeing Zach's bug when running in SLIME is because I was running my asdf on top of the require'd asdf; now since input-files is not included in the list of redefined-functions, I was still benefitting from a method from the previous ASDF that explicitly overrode the default method, forcing modules to actually have no input-files. So it was actually my bug to have deleted this method instead of making it a method on parent-component. There. Mea culpa. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org It may be better to be a live jackal than a dead lion, but it is better still to be a live lion. And usually easier. — Robert Heinlein, Time Enough For Love ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] prepare-op
Casualties of the cleanup were :feature and :if-component-dep-fails. They were just horrible things. FYI, the sb-rotate-byte contrib in SBCL uses :if-component-dep-fails. I've contacted the SBCL maintainers. Hopefully they will revert to #+x86-64 and such until a new asdf is universal. But that begs the question: how do we support old versions... and should we try? I can imagine plenty of horribly klugy ways to make it work, but... ouch. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] prepare-op
On Mon, Dec 17, 2012 at 2:19 PM, Christophe Rhodes cs...@cantab.net wrote: Zach Beane x...@xach.com writes: Faré fah...@gmail.com writes: OK, this is now committed as of ASDF 2.26.21 and POIU 1.29.3. It's slightly smaller, it's much cleaner, and it all works. I hope I have not broken users — please test. Casualties of the cleanup were :feature and :if-component-dep-fails. They were just horrible things. FYI, the sb-rotate-byte contrib in SBCL uses :if-component-dep-fails. What is the correct way now to indicate that a file is part of a system, but should only be compiled if a given feature is present? It appears that the SBCL contrib SB-ROTATE-BYTE uses :IF-COMPONENT-DEP-FAILS. In the spirit of not breaking everyone's existing SBCL installation, I have implemented *limited* compatibility with :IF-COMPONENT-DEP-FAILS in ASDF 2.26.27, sufficient to cover the usage observed in the wild. The restrictions are as follows: (a) Only the :ignore behavior is implemented. :try-next (which is a misnomer since it tries all) is seen as :ignore. It is not possible to directly reproduce :try-next behavior in ASDF 2.27. If you want to fail when none of some features is present, you should explicitly use somewhere in your system: #-(or foo bar baz) (error unsupported implementation) (b) I only support :IF-COMPONENT-DEP-FAILS for dependencies on COMPILE-OP, which is what the only known (to me) users use. Please report any occurrence of a different usage pattern in the wild, if possible before release 2.27 (which I target around Christmas). :IF-COMPONENT-DEP-FAILS is still strongly deprecated, though its current pattern of use will still work: (:module foo :if-component-dep-fails :ignore :components ((:file x86-64-vm :in-order-to (compile-op (feature :x86-64) For legacy compatibility, I recommend either using the like of #+(and sbcl x86-64) (:file x86-64-vm) unless you insist on making the file part of the system object, as per Christophe's legitimate requirement. Going forward, when ASDF 2.27 becomes widespread, I recommend the future use of (:file x86-64-vm :if-feature (:and :sbcl :x86-64)) Note only that (a) :if-feature allows for boolean combinations of features with :and :or :not, unlike :if-component-dep-fails; (b) dependencies on a :if-feature component are automatically removed if removes when the component has been disabled by lack of feature; (c) the component still part of the component tree, which will make Christophe happy; (d) :if-feature does not involve multi-level special-case complexity in the traverse algorithm to invalidate the patent meaning of the graph, which makes *me* happy. There will be a feature #+asdf2.27 in case it is useful to detect the availability of the massively refactored ASDF internals. I apologize for the temporary breakage, but I suppose that's what testing before release is all for. Thanks a lot for bearing with me, thanks a lot to Xach for your prompt feedback, and thanks to stassats for quickly fixing SB-ROTATE-BYTE in SBCL HEAD (which retrospectively is not needed anymore - my apologies for the make work). PS: Only semi-relatedly, there is now a new generic function: RESOLVE-DEPENDENCY-COMBINATION (COMPONENT COMBINATION ARGUMENTS) called when (COMBINATION . ARGUMENTS) appears as the specification of a dependency to COMPONENT, so you can extend the dependency language. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Common Lisp makes it easy for you to grow your own language; however, it makes it difficult for that language to be the same as anyone else's. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Guidelines for ASDF system authors
Dear Felix, sorry for having taken so long getting back to you. On Mon, Dec 10, 2012 at 8:08 PM, Felix Lange f...@twurst.com wrote: Hi, I've been thinking a lot about the structure of Common Lisp projects lately and would like to turn those thoughts into a public discussion. I believe that some written guidelines for ASDF system authors could really improve how the Common Lisp ecosystem functions as a whole. That's very possible. I'm looking forward to reviewing any document you write, and I'm accepting patches to the ASDF documentation. The documentation on the ASDF website is comprehensive with respect to the capabilities of its implementation, but there are few guidelines on how developers are supposed to structure their systems. Indeed. Even links to existing systems would be nice. I perceive a need for a manual chapter or document that consolidates best practices advice and somehow documents the `intended' use of ASDFs countless features. This information is currently scattered all over the ASDF manual. Getting the big picture is possible but kind of difficult. The new section `Extensions' on the ASDF project website as well as the FAQ section in the manual are very much a step in the right direction. Some of the questions that I think need a documented solution which could also act as a community convention: - How to properly conditionalize on *FEATURES*. This is touched briefly in manual section 6.2.1.3 `Required features'. There's a note explaining that excluding components through the #+ syntax is a bad idea, and that the correct way of doing it i.e. (:file foo :depends-on (:feature :sbcl)) does not work at this time. In the meantime, Nikodemus has written MADEIRA-PORT for this exact purpose. A new, sensible, way of doing things has just been introduced in 2.26.22: :if-feature. The only downside is that it's not backwards compatible, so you have to make sure you and your user upgrade ASDF before you use it; or you should wait a few months for ASDF 2.27 to have been released and propagated. In the meantime I recommend using #+. :if-feature :foo is just like #+foo except that with #+foo you also have to annotate the dependency references. Not so with if-feature. - Implementing TEST-OP The manual tells me that `it has proven difficult to define how the test operation should signal its results' and that TEST-OP does nothing by default. Current practice seems to be defining TEST-OP as a method that loads another system and then somehow executes all tests, failing the operation when some test did not pass. This is noted in the FAQ section and should really be the official way. Yes, probably. - How to specify optional dependencies in the `correct' way? Suppose I'm working on a library that can use either IRONCLAD or CL+SSL to generate random bytes using a strong crypto algorithm. I don't want to clutter the final application image with both crypto libraries but rather use whatever happens to be the application developer's choice. I have several options to do this. 1) Use :WEAKLY-DEPENDS-ON to rely on the application's transient dependencies to load either one. This is obviously a nice solution, but I have to document the requirement of loading at least one of them in the README and figure out which one to use at runtime. 2) Define two systems, MY-LIBRARY-IRONCLAD and MY-LIBRARY-CL+SSL. This would force the user to require one of them in order to use the library. I also need to document this, but do not have to switch at runtime. 3) Solve the problem outside of ASDF 2 and/or 3 are the obvious only sensible choices. I am personally *STRONGLY AGAINST* :WEAKLY-DEPENDS-ON, and would NEVER have allowed this feature inside ASDF under my watch. It's just a booby trap waiting to explode in the face of users: it makes the meaning of your software depend on what was in environment at some earlier time on which you don't even always have control. It's the promise of endless hours of frustration due to build bugs. The only reason it still exists is that I lacked the care and energy to track down those who use it and LART them before I remove the feature. With or without ASDF, implementing your library in a parametric way and providing some default behavior configurable through hooks is the one and only proper way of writing software. If you want something to assemble programs out of other programs in a way that varies depending on various parameters, what you need is a layer on top of ASDF. And then, you might as well handle versions and compatibility constraints, in a way that ASDF never can and never will. - How much `formalization' of the build process pays off in the long run? ASDF could obviously have more uses if people followed a common guideline. What's the advantage of custom component classes vs. a custom operation that is hooked into COMPILE-OP via
[asdf-devel] Please test ASDF 2.26.24
Considering that I ran out of energy with respect to ASDF hacking following the marathons of refactoring last week, I'm declaring 2.26.24 a candidate for release of 2.27. Please test thoroughly, since this is quite a MAJOR release, with a lot of significant changes. The only reason I'm not bumping the version to ASDF 3 is that this would needlessly break compatibility with who depends-on (:version asdf 2.XXX) when ASDF 2.27 is probably compatible with most every system out there. There are a few incompatibilities, though. Here are the changes since 2.26: * ASDF-BUNDLE was merged into ASDF. This notably means fewer headaches for users of ECL; it also means a new load-fasl-op feature for all users of a modern CL, making it easier to deliver software as a single fasl. All remnants of its predecessor asdf-ecl were removed. * Two related significant *decades-old* bugs were fixed (see note 1): (a) changes in dependencies now trigger a rebuild across systems, and https://bugs.launchpad.net/asdf/+bug/479522 (b) timestamps are now correctly propagated https://bugs.launchpad.net/asdf/+bug/1087609 In olden days, some have argued for not rebuilding systems that :depend-on a modified one as a feature. It really isn't. On the other hand, if they want to explicitly prevent a rebuild, the actual feature :force-not is there to help them (released as part of 2.21 in April 2012). * In the process, an essential bug in the ASDF object model was resolved, by introducing a new operation PREPARE-OP corresponding to loading the dependencies of a component and its parents and required before to load or compile the component, instead of depending on the implicit behavior of the TRAVERSE algorithm, which was breaking down in the above bugs. * The TRAVERSE algorithm was gutted out. The above conceptual bug was fixed, and instead it has been factored into reusable higher-order functions. It no longer assumes all operations propagate their dependencies downwards, which is not the case with PREPARE-OP where they propagate upwards. Instead, operations can easily propagate whichever way they want using a one-liner defmethod to COMPONENT-DEPENDS-ON. * COMPONENT-DEPENDS-ON is now more powerful: it can express dependencies on arbitrary operation objects (i.e. operations of the same class can have different options) acting on arbitrary component objects (i.e. not necessarily siblings of the current component). The ASDF object model can now express arbitrary build graphs, with special magic no more for children components vs other dependencies. * Many internals have been refactored, and some sorry features were excised. The semantics of OPERATION-DONE-P is now well-specified. The dubious DOFIRST mechanism is gone. FIND-COMPONENT will pass component objects through, and a corresponding FIND-OPERATION replaces MAKE-SUB-OPERATION. Some internal accessors were renamed. * The dubious :feature and :if-component-dep-fails :try-next features were removed. They were not very expressive, clunky to use, and relied on baking conceptually buggy behavior in the old TRAVERSE algorithm. Unhappily, this breaks backwards compatibility for the few who used it. Happily, a much cleaner :if-feature component option was added. However, if you use it you then depend on a recent ASDF 2.27 or later. * POIU was updated. It is still an extension not distributed with ASDF. It is now much simplified and made more correct by construction by reusing the new TRAVERSE infrastructure of ASDF and now being able to assume the ASDF object model is a complete description of dependencies. On SBCL it will handle deferred warnings from background compilations. On platforms that cannot fork it will gracefully fall back to serial compilation. * The documentation was updated a little. The test suite was updated. * There were some portability updates for ABCL, CMUCL, MKCL. Happy hacking! Notes 1- ASDF inherited those long-standing dependency bug from MK-DEFSYSTEM, which probably inherited it from its predecessors, and so these related bugs have probably lived for over 30 years, for as long as defsystem existed! I haven't seen the proprietary defsystems used by e.g. Allegro or LispWorks, but the fact that e.g. LispWorks has caused-by and requires dependencies (akin to in-order-to and do-first in asdf) makes it very suspect in my eyes. And yet, it all hasn't seem to affect people too much — certainly not so much that they would go a-hunting and a-fixing them! Indeed, if you're working a single system at a time, until it works, without interrupting the build (instead fixing the code and using a restart after errors), without leaving and restarting your image, then the bug won't hit you. If you occasionally abort a build, but no file depends on a modified macro or other compile-time state that wasn't itself modified to accommodate the change, then you won't hit. Therefore, it might never have been seen by a normal Lisp Machine
[asdf-devel] if-component-dep-fails
Dear Nathan, at least as far as quicklisp-included software goes, your ironclad and nibbles seem to be the only user of ASDF's :if-component-dep-fails and :feature features. These features are a crock and I'd like to plainly remove them. In the future, I might provide a better-thought-out replacement that actually works. In the meantime, the backwards-compatible solution would be to use #+sbcl and such; yes it breaks an abstraction barrier — but at least it doesn't require ASDF itself to break its own abstraction barrier internally. Could you fix your .asd's to not use these features I'd like to drop? Does any other person who cares about ASDF cares about these features? —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org If you make people think they're thinking, they'll love you; but if you really make them think, they'll hate you. — Don Marquis ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] if-component-dep-fails
On Fri, Dec 14, 2012 at 12:15 PM, Nathan Froyd froy...@gmail.com wrote: I can probably do that, yes. Why do you say they're a crock? They're very useful for defining what's supposed to happen at a higher level than scattering #+/- about source files everywhere. Oh, they serve a useful purpose, but they do it in a very roundabout way, and they break the normal meaning of the dependency graph. I also strongly dislike weakly-depends-on for the same reason, though at least if can be thought of, just like #+, as a preprocessing phase before the building of the dependency graph, rather than something that magically escapes from the graph to a magic special case in a specific traversal algorithm — what more only at traversal time, unlike what the name suggests. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org A programming language is low level when its programs require attention to the irrelevant. — Alan Perlis ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 3? WAS Re: if-component-dep-fails
rpgoldman: I think, if we remove :if-component-dep-fails and replace it with something better (a choice I heartily applaud), and also add your prepare-op, that sounds to me like a big enough change to the API to warrant calling this ASDF 3 sometime soon There are enough API differences that I think being able to say #+asdf3 might be useful... Problem: asdf's current versioning scheme will declare that asdf 3 is incompatible with asdf 2, so anyone who tries (asdf:version-satifies 3.0 2.26) is in for a big disappointment. As long as we reasonably don't break compatibility, I propose we keep the asdf 2 series going indefinitely. And if we are going to break compatibility, we know where to find xcvb, quick-build, etc. — Question authority! — Yeah, says who? ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 3? WAS Re: if-component-dep-fails
Problem: asdf's current versioning scheme will declare that asdf 3 is incompatible with asdf 2, so anyone who tries (asdf:version-satifies 3.0 2.26) is in for a big disappointment. As long as we reasonably don't break compatibility, I propose we keep the asdf 2 series going indefinitely. That's a good point. If we are going to stick to ASDF 2 indefinitely, would it be a problem to move to an xx.yy.zz format of versioning, where delta(yy) = change in API and delta(zz) = patch? The problem is what constitues a change in API; as long as we preserve what's documented, that can be in the eye of the beholder, and we failed to document much. That said, I agree there should probably be a #+asdf2.27 or something, since I'm introducing some several major changes: asdf-bundle, building those who depend-on a modified system, proper timestamps, yet another complete rewrite of traverse, removal of :feature and :if-component-fails, etc. The reason I suggest this is that it might be easier to keep track of the way in which the xx's correspond to features you need that way. Most people who are worried about whether their ASDF system definitions will work could safely ignore the zz's. I don't think that will work any the better than now. You will still have to look at the debian/changelog or git log to see when a feature was introduced or removed. Personally, I have pretty much lost track of when features I need were added to ASDF. If you care to specify the proper version of asdf to depend on, the release-to-release debian/changelog and the commit-to-commit git log are here to help. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org What is mind? No matter! What is matter? Never mind! — Bertrand Russell's Grand Mother, In Karl Popper, The Unended Quest ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] prepare-op
OK, this is now committed as of ASDF 2.26.21 and POIU 1.29.3. It's slightly smaller, it's much cleaner, and it all works. I hope I have not broken users — please test. Casualties of the cleanup were :feature and :if-component-dep-fails. They were just horrible things. Another, disabled, :feature feature could replace it: it was never working in ASDF 1, but I fixed it some time ago and it's there behind a cerror waiting to be used. On the other hand, there are many new features for those who extend ASDF or inspect its results. ASDF and POIU are now officially equivalent, using the exact same traversal functions, just with different production functions: ASDF drops information and creates a linear list, POIU keeps all the information and builds a graph representation. If you want to examine the graph, you can. component-depends-on is now more powerful: it faithfully describes the graph without any implicit inherited dependency, it allows you to express operations that do not flow down the component hierarchy, but instead go up or sideways or don't flow (like test-op), or skip merrily around whichever way you prefer. It may return component objects as well as designators relative to the argument component's parent, and the resolve-dependency-spec is made available to you for custom operations. component-self-dependencies and the default input-files method were fixed to handle more cases. force is implemented via a simple method on prepare-op, and the mechanism it and force-not use has been factored in a way that it could be reused for other interesting future uses. A whole slew of special cases were done away with. For the first time, ever, I can say that ASDF has a design that makes sense. It's not perfect, it's not ideal, but it does make sense. I may write for Dan Barlow his ASDF apology. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org There are two kinds of pacifists: those who try to disarm the criminals, and those who try to disarm the victims. On Fri, Dec 14, 2012 at 2:48 AM, Faré fah...@gmail.com wrote: I have finally fixed an essential dependency problem of ASDF by introducing a new operation parent-load-op which I'm going to rename prepare-op. This in turns opens the way for many many improvements to the internals, which will make ASDF easier to explain and extend, so expect some work there — and I'm postponing any 2.27 release until that's stable. However, any and all changes introduces potential backwards-incompatibility, and I'll be searching through packages available in quicklisp for any potential such incompatibility before I go ahead with renaming internals. Some details: In 2.26.14, I introduced an operation called parent-load-op, which ensures the dependencies of the parent are loaded before the child is compiled. This ensures the graph produced by following component-depends-on isn't missing crucial dependencies instead of relying on the specifics of the TRAVERSE algorithm (and at long last I really understand what rpgoldman was telling me while we were writing the ASDF 2 paper). I had to tweak traverse, because parent-load-op trickles upward, not downward, the component hierarchy: you depend-on the parent-load-op of your parents, but not on that of your children (that would create a circular dependency). So I had to add a check in TRAVERSE (now — 2.26.20 — in its nice and short visit-children helper) to not automatically propagate subclasses of parent-op dependencies downward. I started thinking about a theory of parent-op and child-op dependencies and how to rewrite the current hierarchy, and as I was doing it found that actually, parent-load-op is not parent-specific: it's actually a dependency-op or prepare-op, that ensures that the image is prepared to compile or load the component, by having already loaded all the dependencies, and it could do it for the normal case, too: instead of having load-op or compile-op depend on the load-op of all the dependencies, they could simply depend on prepare-op. Then, we don't need to have traverse know anything about propagating dependencies either downward or upward, it can all be done with two methods on component-depends-on! [which is one of the many misnomers in ASDF: components don't depend on anything, it's (operation . component) pairs, which I'm calling actions, like in Kent Pitman's article), that are nodes in the dependency graph]. It was all quite a revelation. And so I'll be working on drastically cutting down ASDF, and making the basic dependency graph cleaner, which will make ASDF much simpler and more reliable to extend. Some change I'd like to make if no one uses these internals (or only use them without relying on the current setup to define methods, in which case I can define an alias]: module == make it a subclass of both child-component and parent-component system == is a parent but not a child, and thus not a module. component-depends
[asdf-devel] :if-feature
ASDF 2.26.21 removed the horribly clunky :if-component-dep-fails. ASDF 2.26.22 added a much more meaningful :if-feature. Any component can use the :if-feature option, which can be an arbitrary keyword expression, just like #+. The difference is that unlike #+ it doesn't magically change the *package* to keyword, so you have to include the colons, as in :if-feature (:and :sbcl :x86-64) The upside is that its semantics is simple, doesn't break the object model, and allows for arbitrary expressions. The downside is that it is not backwards compatible. It will be released with 2.27 only. (If you have a better name than :if-feature, now is the time to suggest it.) Hopefully, I will remember to include a #+asdf2.27 before I release. Please test asdf 2.27 and give me feedback. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org The worst thing that can happen to a good cause is, not to be skillfully attacked, but to be ineptly defended. — F. Bastiat ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 3? WAS Re: if-component-dep-fails
On Fri, Dec 14, 2012 at 6:40 PM, Robert Goldman rpgold...@sift.info wrote: On 12/14/12 Dec 14 -3:13 PM, Faré wrote: Personally, I have pretty much lost track of when features I need were added to ASDF. If you care to specify the proper version of asdf to depend on, the release-to-release debian/changelog and the commit-to-commit git log are here to help. Ah. Thanks. I don't use the debian packaged version, so it didn't occur to me to look in debian/ Any chance of promoting the changelog to the root directory? No, that's where debian wants it, I don't want to do double work. I don't suppose symlinking works happily, especially for folks on Windows Nope. I could include a note in the README... Having a changelog probably makes it less critical to distinguish api changes from patch releases. I have a minor feeling that it's tidier to do so, but that's probably just being obsessive. It's important to distinguish releases. Things break during development, some commits are checkpoints of work in progress, and more testing happens before (or sadly, after) release. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Of course, Third World leaders love you. By ascribing third world ills to First World sins, you absolve them of blame for their countries' failure to advance. — John McCarthy ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] P.S. re patch...
I intend to release 2.27 next week. Can people test on their systems and their implementations? Xach, are things all clear with Quicklisp now? There is an unusual issue with the periods library that I can't quite puzzle out. It does not have any trouble with ASDF 2.26, but it fails to load from FASL, under some circumstances, with the latest commit to master. It seems like something in my build environment is triggering it, but I can't reproduce it reliably enough to figure it out. I'll keep you posted. Do you logs of some of these failures? Maybe I can reproduce at home, or, looking at the .asd and knowing what I changed, figure a scenario that explains the failure. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] P.S. re patch...
Also, I'd like to know if any package in Quicklisp relies on some ASDF internals I'd like to rename. This is especially harder when users define methods on a generic function — you can't rename the function, then. Is there an easy way to download EVERYTHING (excluding old versions) so I may grep the results? —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Democracy is a pathetic belief in the collective wisdom of individual ignorance. — H.L. Mencken On Thu, Dec 13, 2012 at 9:27 AM, Zach Beane x...@xach.com wrote: Faré fah...@gmail.com writes: I intend to release 2.27 next week. Can people test on their systems and their implementations? Xach, are things all clear with Quicklisp now? There is an unusual issue with the periods library that I can't quite puzzle out. It does not have any trouble with ASDF 2.26, but it fails to load from FASL, under some circumstances, with the latest commit to master. It seems like something in my build environment is triggering it, but I can't reproduce it reliably enough to figure it out. I'll keep you posted. Do you logs of some of these failures? Maybe I can reproduce at home, or, looking at the .asd and knowing what I changed, figure a scenario that explains the failure. http://report.quicklisp.org/periods/2012-12-12/failtail.txt is the typical failure log. The use of the SERIES package is conditionalized on the :PERIODS-USE-SERIES feature, and I can't find any place where that is in effect. Zach ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
