Re: [asdf-devel] distributing asdf
Faré fah...@gmail.com writes: 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. fare-matcher fails because FARE-UTILS does not designate any package. This affects weblocks and other projects. Zach ___ 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
Faré fah...@gmail.com writes: 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). By the way, this steady stream of oops, ooops, oops, oops, is causing me a huge, huge, huge headache. The short life of asdf-utils is causing me a huge headache. The incompatibilities introduced in ASDF are causing me a huge headache. 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. Zach ___ 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] distributing asdf
Faré fah...@gmail.com writes: 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); Also, Quicklisp is just a subset of the CL code out there; not breaking stuff in Quicklisp is good, but not breaking anything at all is good too. Zach ___ 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
