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
Re: [asdf-devel] ASDF 2.27 release candidate
Faré fah...@gmail.com writes: Dear Zach, : Faré OK, so 2.26.45 is my new release candidate for ASDF 2.27. Please grab it and test it. : Zach Beane It still breaks gbbopen and fset. It still seems to trigger the package-at-variance issue in weblocks and other projects. Did you actually update ASDF when you re-ran the tests? I can't reproduce the failure with either gbbopen, weblocks, or any of the previously-mentioned projects. With weblocks, compilation does complain about a few undefined variables and functions — but not more so than ASDF 2.26 and earlier, and whatever tests there are pass for me. I did have to fix asdf-system-connections to avoid unnecessarily recompilations (especially now that ASDF correctly propagates dependencies from system to system), but that 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. Zach ___ 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
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. It still seems to trigger the package-at-variance issue in weblocks and other projects. 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. Zach ___ 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
