- asdf-devel - mailman3.common-lisp.net

[asdf-devel] bad interaction with new ASDF 2.015 and Quicklisp
by Nikodemus Siivola 14 May '11

14 May '11

Steps to reproduce: 1. Get ASDF 2.015 or .1 2. Install Quicklisp, (ql:quickload "flexi-streams") 3. Install Flexi-Streams outside quicklisp as well. (For the purposes of bug reproduction, putting a copy of flexi-streams.asd into eg ~/tmp is enough.) 4. Go to the directory with the non-Quicklisp copy of flexi-streams.asd. 5. In lisp: (push "./" asdf:*central-registry*) (asdf:load-system "flexi-streams") ...endless recursion that eventually blows either stack or heap. What is happening is approximately this: ASDF starts loading ~/tmp/flexi-streams.asd DEFSYSTEM FLEXI-STREAMS is ok. During processing of DEFYSTEM FLEXI-STREAMS-TEST, FIND-SYSTEM is called for FLEXI-STREAM-TEST -- ironically _after_ it has been registered and its pathname set. Source-registry doesn't find it because there is no file flexi-stream-test.asd, and neither does SYSTEM-FIND-ASDF, but Quicklisp which _does_ find it: ASDF starts loading quicklisp/.../flexi-streams.asd ...you can guess where this leads. But even without the endless recursion this find is bogus. This did not happen with prior versions of ASDF. This is really messing up things for me -- enough so that I'm contemplating reverting the SBCL provided ASDF to 2.014. Cheers, -- Nikodemus

4 10

[asdf-devel] (no subject)
by Sean Bryant 11 May '11

11 May '11

Hello asdf, This is cross posted on the sbcl mailing list (I asked there first since this has to do with an sbcl specific feature.) Project names were changed to protect their identities. I'm a fairly new lisper and I'm running into trouble trying to generate coverage reports (using sb-cover, obviously) for a specific system in my project. I tried to just add the (declaim (optimization sb-cover:store-coverage-data)) after loading the system, but then I realized I made a horrible mistake as sbcl uses that optimization declaration to add tracing data to the compiled code. I then naively decided it would be a good idea to just force a recompile of the system. To my horror, I ended up recompiling everything sbcl touched, cl-sql, bordeaux threads, and more. The good news is that I managed to generate the coverage report but only with tons of external dependencies being included in the report as well. As much as I like knowing these things, it's not exactly useful. The solution I'm trying to come up with is creating a new type of operation in asdf conveniently called cover-op. I haven't had much luck in getting this working (I've only spent an hour on this, so not really surprising given my exposure to asdf). Currently, I like the setup with asdf:test-system and then just specialize perform to run the tests. I would like to do the same thing to generate coverage reports, but the compilation step is proving the be a problem. I'm wondering what other asdf users do to ensure coverage reports are generating for only the "interesting" aspects of your applications? Thanks, Sean

1 0

[asdf-devel] load-source-op broken in 2.015, fixed in 2.015.1
by Faré 09 May '11

09 May '11

Oops. I broke stuff in 2.014.13. Martin Simmons found the bug, I fixed it, but too late for 2.015. I committed 2.015.1, with a regression test. Apparently we weren't testing that functionality before. Is it OK to have load-source-op be broken for that while? If not, should I release 2.016 now, or tell people to use 2.015.1 instead of 2.015? e.g. I could push 2.015.1 to the "release" branch. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Microphones, liberating singers from having to be loud to be heard, gave back to each language a music that matches its own prosody.

1 0

[asdf-devel] asdf 2.015
by Faré 07 May '11

07 May '11

I promoted 2.014.17 as 2.015. Since 2.014, we have the following improvements: * Portability: support cormanlisp, xcl; fixes for cmucl, ecl; tweaks for abcl, allegro, clisp, genera, lispworks. * Feature: un-cerror and fix the :force '(sys1 sys2 sys3) feature, introduced in 2002 and never working before. * Feature: classes asdf:cl-source-file.cl and asdf:cl-source-file.lsp for people who use these file type extensions. * Semantic change: the source-registry eagerly gathers a list of .asd, rather than querying the filesystem over and over again. * API change: exposing function asdf:search-for-system-definition as looking through asdf:*system-definition-search-functions* for either pathnames *or* (new feature) system objects. Should make quicklisp happier. * Better support for asdf upgrading itself, with new function asdf:upgrade-asdf that knows to invalidate old systems when necessary, and is magically invoked before building any system that :depends-on asdf. Make upgrade smoother some cases that were previously broken. * More robust handling of version strings. * Declaring function asdf:system-definition-pathname obsolete, but still supporting it for now, as an alias for asdf:system-source-file. * Various refactorings of internals. Splitting a function asdf::perform-plan out of the default asdf:operate method. asdf::register-system now takes only one argument. * Added tests to prevent the many regressions experienced during this development cycle * Tried and reverted: attempts to make asdf more verbose when it's verbose, but not verbose by default. Thanks for testing. Please update your implementations and distributions to include the latest stable ASDF, currently 2.015. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Eric Schmidt rule of management: always assume that the other person is as intelligent as you are.

1 0

[asdf-devel] Added tests
by Robert Goldman 02 May '11

02 May '11

I added some tests for Faré's new cl-source-file subclasses, cribbing the old tests for changing the source-file-type by hand. And, indeed, I found a typo! Please pull updates and run the tests on your lisps! best, r

1 0

[asdf-devel] 2.015 soon - please test.
by Faré 02 May '11

02 May '11

I would like to release 2.015 this weekend - consider 2.014.13 a release candidate. Please test. A lot. So I don't have to release 2.015.1 next week. I have no current plans to hack more on ASDF, as there are no pending bugs that I think are fixable in 2.0. Hopefully, I can move on to other projects at long last. But I've said it before, and have come back to hacking ASDF and fixing its bugs (including writing new ones). [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "I'm not a procrastinator, I'm temporally challenged"

1 1

[asdf-devel] asdf verbosity
by Faré 02 May '11

02 May '11

On 26 April 2011 12:36, Zach Beane <xach(a)xach.com> wrote: >> PPS: I just made asdf more verbose in verbose mode. However, verbose >> mode is the default, so this may or may not be annoying. Please tell >> me. > > Now that I've seen it, I do find it both annoying and confusing. > OK. Should I turn verbose off by default, or should I make verbose less verbose, or introduce several degrees of verbosity? > Before: > > * (require 'sb-rotate-byte) > ("SB-ROTATE-BYTE" "ASDF") > > After: > > * (require 'sb-rotate-byte) > > ; Loading #<CL-SOURCE-FILE "sb-rotate-byte" "package"> > ; Loading #<CL-SOURCE-FILE "sb-rotate-byte" "compiler"> > ; Loading #<CL-SOURCE-FILE "sb-rotate-byte" "vm" "x86-64-vm"> > ; Loading #<MODULE "sb-rotate-byte" "vm"> > ; Loading #<CL-SOURCE-FILE "sb-rotate-byte" "rotate-byte"> > ; Loading #<SYSTEM "sb-rotate-byte"> > ("SB-ROTATE-BYTE") > > More than one project has something like this in the .asd: > > #+sbcl > (require 'some-sbcl-thing) > > There isn't a good way to intercede to make these non-verbose, is there? > We could make require explicitly use :verbose nil. Probably should, too. Only reason I didn't do it before was out of conservatism. > I would prefer to see nothing at all in that circumstance, except the > return value. > Is T a proper return value? > Also, the display of the object as a "CL-SOURCE-FILE" is confusing. It's > actually loading the FASL. (I know why it prints the way it does, but > it's still confusing.) > I suppose I could specialize the description for source files and for modules. What about the following when we're verbose: ; Loading FASL for #<CL-SOURCE-FILE "sb-rotate-byte" "package"> ; Loading FASL for #<CL-SOURCE-FILE "sb-rotate-byte" "compiler"> ; Loading FASL for #<CL-SOURCE-FILE "sb-rotate-byte" "vm" "x86-64-vm"> ; Loaded #<MODULE "sb-rotate-byte" "vm"> ; Loading FASL for #<CL-SOURCE-FILE "sb-rotate-byte" "rotate-byte"> ; Loaded #<SYSTEM "sb-rotate-byte"> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] No woman ever falls in love with a man unless she has a better opinion of him than he deserves. — Edgar Watson Howe

6 19

[asdf-devel] 2.014.8
by Faré 26 Apr '11

26 Apr '11

Following previous discussions on this list and on #lisp, I pushed yet another change to ASDF. The patch includes better support for system-finding functions, and caching of source-registry data so we only hit the filesystem the first time around. I hope this will make Xach happy. I'll export any symbol he wants supported before the next release, if he asks me. The patch also handles self-upgrades more correctly. It will only work if the *old* ASDF is 2.014.8 or later, though. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I have not yet begun to procrastinate

6 21

[asdf-devel] 2.014.7
by Faré 14 Apr '11

14 Apr '11

Fixed several issues in 2.014.7. Should make Xach's quicklisp happier, especially on ECL. Incompatibility: I deleted system-definition-pathname. As an exported function, it is redundant with system-source-file. As an internal function, it is replaced by search-for-system-definition, which can return a system object as well as a pathname. A cursory googling shows that system-definition-pathname is used by bese qbook's publish-op. Should I reinstate system-definition-pathname as an alias for system-source-file, or should I expect qbook to be updated if anyone ever uses it again? Xach: please tell me which symbols you'd like exported. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Non Omnis Moriar (Not Everything In Me Will Die). — Dr. José P. Rizal

2 2

[asdf-devel] Subtle bug when upgrading asdf
by Faré 13 Apr '11

13 Apr '11

I had warned before that one limitation of upgrading asdf was that it had to be done before to load anything that depends on the new asdf. Well, I've been bitten by it, badly, when trying to build xcvb on a new machine. What is surprising is that I haven't been bit by it earlier. Symptom: on that machine, when you loaded xcvb, it failed the first time to compile ironclad (recently uncommented as a dependency) because the :around method on perform that changes the readtable wasn't executed. On the second attempt at the REPL, it worked, though (from a script, no second attempt possible). Introspection of the perform gf showed the method was present during the first (failed) attempt. Why oh why? Cause: because xcvb depends on a recent asdf, it tries to make sure that asdf is up to date, which it was trying to do from xcvb.asd (we are not building xcvb with xcvb right now, pending some serious refactoring and extensions). But that is too late, since that means that the old asdf is running to compile and load xcvb and its dependencies, not the new one. Therefore, the old asdf loads the new asdf. The new asdf shadows problematic functions including perform (i.e. uninterns the symbols). Ironclad defines a method on the new gf. But it's still the old asdf trying to load ironclad, and its gf hasn't been extended. Oops. Why it didn't happen on my main machine: because I had been developing cl-launch at the same time as asdf, and upping the minimal version required for cl-launch faster than implementations had been updated; therefore, cl-launch happened to be always be upgrading asdf from the implementation-provided to the latest in the source-registry; by the time xcvb was loaded, asdf was already the latest, and there was no asdf upgrade while loading xcvb. On the other machine, with an older cl-launch and recent sbcl, cl-launch was happy with the asdf provided by sbcl, and therefore not upgrading it to the latest in the source-registry, causing the above bug to surface. Solution: make triple damn sure that asdf has been upgraded *before* it tries to load xcvb. 1- modify cl-launch so it always upgrades asdf whenever asdf is used. 2- have the makefile always load asdf before it tries to load xcvb, even when running on an old cl-launch, 3- in xcvb.asd, error out if asdf was not already the latest (and of a sufficient version) when xcvb.asd was loaded. What it means for you: if your code, or any code it depends on, itself depends on a recent asdf, you cannot rely on asdf to upgrade itself during the asdf-driven build of your code; you must upgrade it specially *before*. Potential cure to make it idiot-proof? In asdf:operate, always start by reloading asdf then funcall'ing (find-symbol* :operate :asdf) if its version changed? What do you think of such a change? Would it cause more grief than it relieves, as it quickly reveals bad configurations with older asdf's in their source-registry than otherwise loaded? Many thanks to Peter Keller, who assisted me while I was totally baffled by this bug. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Who released the most slaves? The one who spent his wealth buying them back? Or the capitalist who found a way to power mills with water?

1 0