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

[asdf-devel] ASDF test-op question
by Robert Goldman 19 Oct '09

19 Oct '09

I have been backporting Gary's markdown documentation to texinfo, and came across this: This operation should test the specified component. ASDF does not (currently) provide a method for returning a value from the test-op (or any other operation), so the implementor must ensure that executing test-op has the side effect of printing useful information about the tests to the CL stream *standard-output*. Question: do we want to specify *standard-output* as the destination for test-op output? I find that to be undesirable because on many CL implementations, it leads to test output being interspersed with lots of messages from compilation and loading, which makes it hard to find the test output you're looking for. I don't like specifying *standard-output* as the destination because it seems to me to be committing us to a bad solution. I think here /not/ specifying a destination is better than specifying a bad destination. I've never found a satisfactory solution to this problem. One suggestion would be to have the test-op take an init arg that specifies a stream (or a filename?) to which test output should be written. It would be left to test op implementers to figure out how to get their test output to go to that destination. I imagine this would typically be achieved by having the PERFORM method dynamically bind some variable that designates the destination. So, two proposals: 1. Delete the specification of *standard-output* as destination. 2. Add an initarg and slot for test-op and specify that output should go there. These are actually two somewhat independent proposals. A 'Yes' on 2 entails a 'Yes' on 1, but it's possible to say 'Yes' to 1 and 'No' to 2. Best, R

9 31

[asdf-devel] Announce : ASDF 1.367
by Gary King 19 Oct '09

19 Oct '09

commit bc11c0c786712020262239a95960c417c8c54547 Author: Gary King <gwking(a)franz.com> Date: Sun Oct 18 22:29:22 2009 -0400 update ASDF version to 1.367 commit 7ef572de9f2585ec5536fe212399afbd7bab2d4f Author: Gary King <gwking(a)franz.com> Date: Sun Oct 18 22:28:58 2009 -0400 safe-file-write-date and better symlink handling * Added and used `safe-file-write-date` to make things more self consistent * Made sure to use *load-pathname* and *load-truename* appropriately so that symlink resolution doesn't become a kerfuffle. commit 0be782a40ad9a98a4ece78306f8741921fb0e641 Author: Gary King <gwking(a)franz.com> Date: Wed Oct 14 09:27:46 2009 -0400 * add `asdf-extensions` package and start to flesh it out * apply patch to better handle relative source-file types (from Fare Rideau) * improve logic of tag updating in bump-revision-and-tag.sh * make test output nicer (from Fare Rideau) * improve test-module-pathnames (from Fare Rideau) -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter

1 0

[asdf-devel] optimization settings
by Faré 18 Oct '09

18 Oct '09

While developing XCVB, I was reminded that when you declaim or compile-toplevel proclaim optimization settings, these settings may (ccl, allegro) or may not (cmucl, sbcl) persist beyond the compilation of the current file. To make the build deterministic, XCVB now resets the settings before every operation. And then I remembered that in building QRes at ITA, I had similarly had to reset settings around every system if not every file, so that one library's preferred settings would not pollute the build of each and every other subsequent piece of compiled code. The most directly relevant piece of code we use is as follows: (defmethod asdf:perform :around ((op asdf:compile-op) (system asdf:system)) (with-local-compilation-settings () (proclaim-optimization-settings-for system) (call-next-method))) (defmethod asdf:perform :around ((op asdf:load-op) (system asdf:system)) (with-local-compilation-settings () (proclaim-optimization-settings-for system) (call-next-method))) I tend to think that this should be around every component on not just systems (and that's what XCVB does) but in the above modification I was conservative. Would you agree to include code to this effect in the upstream ASDF? Otherwise, the effects of proclaim and declaim beyond the current file become implementation-dependent and that sucks, and/or people have to use declare (maybe locally) instead, which also sucks. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A mathematician is a machine for converting coffee into theorems. [A co-mathematician is a machine for converting cotheorems into fee.]

2 1

[asdf-devel] loading component problem
by "Богдан Иванюк" 17 Oct '09

17 Oct '09

Hi, I'm using asdf-install over the clisp and have problem with loading already installed components. Thats looks like asdf and asdf-install successfully installed. This is my initialization file (~/.clisprc): #-:asdf (load "/home/bohdan/asdf/") (pushnew "/home/bohdan/asdf/registry/" asdf:*central-registry* :test #'equal) #-:asdf-install (asdf:operate 'asdf:load-op :asdf-install) I installed package cl-smtp with the next command: (asdf-install:install :cl-smtp) cl-smtp works after installation. After relaunching clisp can't load it: [1]> (asdf:oos 'asdf:load-op :cl-smtp) *** - component "cl-smtp" not found The following restarts are available: ABORT :R1 Abort main loop Also I can't load any file from ~/.asdf-install-dir/systems ... ~/.asdf-install-dir/systems$ ls cl-base64.asd cl-smtp.asd flexi-streams.asd mel-base.asd split-sequence.asd usocket.asd Can you help me with this issue? Maybe I do something wrong? Thank you. Bohdan.

1 0

[asdf-devel] New draft of the ASDF texinfo manual
by Robert Goldman 15 Oct '09

15 Oct '09

I have finally finished a new draft of the ASDF texinfo manual. At the same time, I have ground my way (mostly) through the Pro Git book and have a better sense of what's expected of me as contributing to a git project. So I have pushed my version of asdf, with the asdf.texinfo changes, to the git repository at http://github.com/rpg/ASDF Gary --- you should be able to cleanly pull my changes from this ASDF repository and apply them to the main repository. I have tried to make rather a larger number of small, understandable changes, instead of one big comm it that contains the whole mess. Please, anyone who is interested, feel free to review my changes here. I /think/ they bring the manual up-to-date by incorporating the changes that Gary's made in the markdown version of the docs, and by pruning some stuff that seems not to be implemented. Please also note that there are a number of places marked with FIXME that indicate places where more information is needed or there are otherwise opportunities for immediate improvement. Cheers, r

1 0

[asdf-devel] ASDF Maintainership
by Faré 14 Oct '09

14 Oct '09

Gary obviously doesn't have enough time to maintain ASDF and commit (or reject) patches as fast as they come. Gary, would you mind nominating other maintainers? If no one else is eager to do it, I'm willing to commit bug fixes when they come. ("New" features like TEST-OP and DOC-OP or whatnot I'll be way more conservative and would rather defer to consensus or more daring maintainters.) [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] No man would listen to you talk if he didn't know it was his turn next. -- Edgar Watson Howe

3 2

[asdf-devel] summary proposal for COMMON_LISP_PATH and system search changes
by Gary King 08 Oct '09

08 Oct '09

Here is a summary of what I've heard and what I think we should do. # Proposal Summary These are independent but make the most sense if taken as a whole. * Specify new defaults for `*central-registry*`, * use an environment variable named `COMMON_LISP_PATH` to override ASDF's defaults, * use `*central-registry*` to find and load an ASDF configuration file (if present) and * modify the default behavior of `sysdef-central-registry-search` to search deeply. ## default value for *central-registry* COMMON_LISP_PATH environment variable with syntax like path[;path]* This is used by ASDF to help build the default value for `*central-registry*`. If not specified, `*central-registry*` defaults to (on *nix-like systems): (list *default-pathname-defaults* (merge-pathnames (make-pathname :directory '(:relative ".common-lisp")) (user-homedir-pathname))) (merge-pathnames (make-pathname :directory '(:relative ".local" "share" "common-lisp")) (user-homedir-pathname))) (make-pathname :directory '(:absolute "usr" "local" "share" "common-lisp")) (make-pathname :directory '(:absolute "usr" "share" "common- lisp")) ) (The last two would need to be different for Windows-based systems.) ## modification for `sysdef-central-registry-search` Currently `sysdef-central-registry-search` searches in the top-level of each directory in `*central-registry*` to find systems. If we use the above, then a more useful approach would be to search in the top-level and in a sub-directory named `systems`. An even more useful approach would to search in all sub-directories of each entry. ## configuration file When ASDF starts, it will: 1. setup `*central-registry*` using its own defaults and the `COMMON_LISP_PATH` environment variable. 2. look for (and load if it is found) a file named `asdf-config.lisp` in each of these paths traversed in _reverse_ order (so that user settings take precedence overs system ones). Note that the ASDF package will exist when this file is read. I.e., I'm suggesting that we go the "user settings overwrite system settings" route rather than the "if there are any user settings, then ignore the system settings" one. -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter

8 20

[asdf-devel] commit emails
by Nikodemus Siivola 07 Oct '09

07 Oct '09

Do we have these? If not, can we get them? Cheers, -- Nikodemus

4 4

[asdf-devel] Note on ASDF getting started guide...
by Robert Goldman 06 Oct '09

06 Oct '09

A couple of points I noticed while doing my backport to info: 1. We start by saying "you can just use require," but then we say "you only need to load asdf.lisp." I think it would be better to say "if this require trick works, you can skip over the section about loading asdf." 2. We might want to say "you might want to install ASDF yourself if you want to get a particular version of ASDF." HtH, r

3 4

Re: [asdf-devel] Recognizing directories in a component name
by Faré 28 Sep '09

28 Sep '09

2009/9/27 Gary King <garywarrenking(a)gmail.com>: > This is _finally_ out; please let me know if anything seems amiss. Thanks a lot! What you have does the trick for me wrt directories in the name, but now that I think of it, to fully solve the problem of source-file-type being NIL (for e.g. static-file) as experienced by several other hackers (and me before I tweaked my .asd files), a cleaner and more effective version should be as attached. I also updated the test script to actually work, as opposed to dying after the first quit-on-error (that also quits without error). I also renamed the fasl directory to .cache/common-lisp/ which you might want to undo. I added newlines in the script-support results. I moved around a function to remove an annoying "undefined function" (actually forward reference) message when loading asdf on SBCL. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Time and money spent in helping men to do more for themselves is far better than mere giving. -- Henry Ford

1 0