asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[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

[asdf-devel] asdf and xcl
by Azamat S. Kalimoulline 04 Apr '11

04 Apr '11

On xcl it print me "getenv not available on your implementation". But xcl have implementation of getenv: CL-USER(1): (getenv "HOME") "/home/turtle" -- Azamat S. Kalimoulline

2 1

[asdf-devel] moving old to new asdf
by Antony 04 Apr '11

04 Apr '11

Hi I have tried to use the newer version of asdf (been using 1.x for long time). I put in (asdf:initialize-source-registry (list :source-registry (list :tree #P"C:/git/") :inherit-configuration)) (asdf:initialize-output-translations (list :output-translations (list "C:/temp/.fasl/") :inherit-configuration )) I like all of my fasls to go under appropriate subdirs of C:/temp/.fasl/ But, they are all going to c:/Users/Antony/AppData/Roaming/common-lisp/cache... I do not want to create any config files. What code would do that. -Antony

3 2

[asdf-devel] System naming conventions
by David Wang 03 Apr '11

03 Apr '11

Hello, QUESTION: 1. Could someone add a system naming convention section to the ASDF documentation, to help future users with similar problems? 2. If someone knows whether my rules-of-thumb (below) are right or wrong, let me know. EXPLANATION: I've been porting a large code base from Franz/Allegro's defsystem to ASDF 2.012. I was originally writing the .ASD files on Windows and recently tried testing the build with the same .ASD files on the Linux variant, Fedora 14, but had some problems with various missing-components. I realized the problem had something to do with the treatment of case in filenames, and ended up fixing problem by examining the ASDF code and inventing some rules-of-thumb: 1. When using Strings to name a system, make sure the filename of the ASD file, the name of the system defined in that file, and any uses of the system-name in other ASD files all have the same case. i.e.: In the file "SyStEmA.asd": (asdf:defsystem "SyStEmA" ...) In the file "SyStEmB.asd" (asdf:defsystem "SyStEmB" :depends-on ("SyStEmA")) 2. If you ever want to use a Symbol to name a system, make sure the filename of the ASD file is all lowercase. The name of the system defined in that file and any uses of the system-name in other ASD files should either be a symbol or a lowercase string. In the file "systema.asd": (asdf:defsystem #:SYSTEMA ...) In the file "systemb.asd" (asdf:defsystem "systemb" :depends-on ("systema")) I don't know if they are correct for all combinations of OSes, CL-variants, and system names, but from my limited knowledge of ASDF's code I think they'll work well. - Thanks! - David Wang P.S. Thanks for helping develop ASDF. I couldn't imagine a [Lisp] world in which it didn't exist.

2 1

[asdf-devel] (asdf:load-system :iterate) loads :iterate-pg & :iterate-tests
by Frank 02 Apr '11

02 Apr '11

Hello there, I've been using iterate for a short while. I noticed that it always loads :iterate-pg and :iterate-tests on (asdf:load-system :iterate). Do those modules have to be pulled in for just the basic :iterate part? I'm using ccl-1.6 and the quicklisp iterate version. Thanks Frank

2 1

[asdf-devel] ASDF 2.014 released
by Faré 31 Mar '11

31 Mar '11

Dear ASDF users, I just blessed ASDF 2.013.7 as 2.014. As compared to 2.013, it includes a significant quality item that makes it essential for everyone who distributes ASDF without an implementation (e.g. Quicklisp). It also includes better SCL support, cosmetic improvements, and robustification of some corner cases. Tests have been added to prevent the regressions observed in the 2.013 release. * Fixed bug preventing upgrade from 2.000 to 2.008 (test added) * Better support for URL pathnames on SCL (test added) * Robustified defsystem-depends-on * Cosmetic changes: * better more portably readable error messages. * remove forward references, again (test added) * canonicalize system names earlier (slight robustness improvement) As usual, I invite people who distribute ASDF to update the version they ship, be it with their implementations, with their software distribution, etc. Happy Happy Joy Joy [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." — Howard Aiken

2 7

[asdf-devel] ASDF and XCL
by Azamat S. Kalimoulline 31 Mar '11

31 Mar '11

XCL has realization of getenv CL-USER(1): (getenv "HOME") "/home/turtle" But ASDF says that no. -- WBR Turtle//BAZON Group

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel