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

[asdf-devel] Does anyone still moderate asdf-devel?
by Robert Goldman 06 Sep '11

06 Sep '11

I have multiple email addresses and am increasingly getting bounces as a result. I'd like to fix this, but don't have the foggiest idea how to do so. If a moderator sees this email, please contact me off-list. best, r

1 0

[asdf-devel] Pushed proposed fix for Xach's bug
by Robert Goldman 06 Sep '11

06 Sep '11

Passes all of the unit tests (including the new one based on Xach's test case). Please, all of you, have a peek at the diffs (possibly I should have squashed the changeset to make this easier, sorry), and the commit message, and test it as soon as possible. I have not bumped the version number, as this is still a work in progress subject to review. best, r

2 4

Re: [asdf-devel] Unexpected behavior when loading different versions of a system
by Daniel Herring 03 Sep '11

03 Sep '11

On Fri, 2 Sep 2011, Robert P. Goldman wrote: > I can see that I didn't explain this as well as I might. It is too late for me to try again now, but I will have a whack sometime over the long weekend. The short answer is that Xach's test case actually revealed that the reuse of old component objects could leave ASDF in a very bad state (modified components with some old attributes, components that were obsolete retained, etc.). Don't do the write-up just for me. It looks like you have good reasons for this change, and that other solutions would be unnecessarily complex. Thanks, Daniel

1 0

[asdf-devel] Unexpected behavior when loading different versions of a system
by Zach Beane 03 Sep '11

03 Sep '11

Say I download version 1 of the FOO library and put it in /tmp/foo-1/, so it looks like this: /tmp/foo-1/foo.asd /tmp/foo-1/a.lisp foo.asd has this: (asdf:defsystem #:foo :serial t :components ((:file "a"))) Then I add the path to the central registry and load it: (push #p"/tmp/foo-1/" asdf:*central-registry*) (asdf:load-system "foo") Everything loads fine. Oops, I need to upgrade, I better get version 2 and put it in /tmp/foo-2/, which looks like this: /tmp/foo-2/foo.asd /tmp/foo-2/a.lisp /tmp/foo-2/b.lisp foo.asd looks like this: (asdf:defsystem #:foo :serial t :components ((:file "a") (:file "b"))) Then I add the path to central registry: (push #p"/tmp/foo-2/" asdf:*central-registry*) It seems to find the new system: (asdf:system-source-directory "foo") => #p"/tmp/foo-2/" However, when I try this: (asdf:load-system "foo") I end up with this error, which I don't really understand: failed to find the TRUENAME of /tmp/foo-1/b.lisp: No such file or directory Why does that happen? What's the best way to work around it? I'm using ASDF 2.017 and a very recent SBCL from git. You can reproduce my scenario by unpacking http://xach.com/tmp/foofail.tgz and loading "foofail.lisp". Thanks, Zach

5 7

[asdf-devel] Testing before release 2.017 ?
by Faré 26 Jul '11

26 Jul '11

There hasn't been much change since last month's flamewar. I'd like to release ASDF 2.017 next weekend. Can testers test 2.016.3 as release candidate? Thanks! It passes all my tests, of course, but experience shows they are far from sufficient to guarantee workingness in the field. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

2 4

Re: [asdf-devel] Small ASDF extension to show dependency DAG
by Faré 09 Jul '11

09 Jul '11

On 9 July 2011 15:48, Scott L. Burson <Scott(a)ergy.com> wrote: > Hi Faré! > > Here's a little hack I just wrote because I wanted to see the > dependency DAG for a system I'm working on: > > (in-package :asdf) > > (defun* show-dependencies (system-name &key descriptions?) > (let ((seen (make-hash-table :test #'equal))) > (labels ((rec (system-name depth) > (let ((nm (if (and (listp system-name) (eq (car system-name) ':version)) > (coerce-name (cadr system-name)) > (coerce-name system-name)))) > (if (gethash nm seen) > (format t "~v@T[~A]~%" (* depth 2) nm) > (progn > (let ((sys (cdr (gethash nm *defined-systems*)))) > (if (null sys) > (format t "~v@T~A??~%" (* depth 2) nm) > (progn > (format t "~v@T~A~@[: ~A~]~%" (* depth 2) nm > (and descriptions? > (slot-boundp sys 'description) > (slot-value sys 'description))) > (setf (gethash nm seen) t) > (dolist (dep (component-load-dependencies sys)) > (rec dep (1+ depth))))))))))) > (rec system-name 0)))) > > I thought you might want to include this in asdf.lisp. Sample output > is below. When a name is in brackets, that means the system and its > dependencies have already appeared earlier in the listing. > (Adding asdf-devel as destination.) It is cool. I think it deserves to be published. But I don't think the already way too big asdf.lisp is the right place. Our goal is to keep asdf.lisp itself minimal, and move anything not strictly needed for system bootstrap into extensions. At the same time, we don't yet have an "official" repository for such extensions. Maybe it's time to start one. Any taker? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > -- Scott > > osb > clsql > clsql-postgresql > [clsql] > clsql-uffi > [clsql] > uffi > clsql-postgresql-socket > [clsql] > md5 > [uffi] > sb-bsd-sockets > sb-grovel > weblocks > closer-mop > hunchentoot > chunga > trivial-gray-streams > cl-base64 > cl-fad > sb-posix > [sb-grovel] > cl-ppcre > flexi-streams > [trivial-gray-streams] > cl+ssl > cffi > alexandria > trivial-features > babel > [trivial-features] > [alexandria] > [trivial-gray-streams] > [flexi-streams] > [sb-posix] > [md5] > rfc2388 > trivial-backtrace > usocket > [sb-bsd-sockets] > bordeaux-threads > [alexandria] > puri > cl-json > cl-who > parenscript > [cl-ppcre] > anaphora > [cl-fad] > fare-matcher > fare-utils > cl-cont > [closer-mop] > [alexandria] > metatilities > metatilities-base > moptilities > [closer-mop] > cl-containers > [metatilities-base] > metabang-bind > asdf-system-connections > [cl-ppcre] > [md5] > [anaphora] > f-underscore > [bordeaux-threads] > salza2 > html-template > trivial-timeout > [trivial-backtrace] > weblocks-clsql > [closer-mop] > [metatilities] > [clsql] > [weblocks] > cl-oauth > ironclad > sb-rotate-byte > [cl-base64] > [babel] > [closer-mop] > [alexandria] > [anaphora] > [f-underscore] > split-sequence > trivial-garbage > fiveam > arnesi > drakma > [puri] > [cl-base64] > [chunga] > [flexi-streams] > [usocket] > [cl+ssl] > [puri] > [hunchentoot] > [cl-ppcre] > cl-smtp > [usocket] > [trivial-gray-streams] > [flexi-streams] > [cl-base64] > [cl+ssl] > monkeylib-bcrypt > [cffi] > fset > gmap >

1 0

[asdf-devel] Package definition for each file in :components?
by Matus Kmit 27 Jun '11

27 Jun '11

Hi i have some basic question: Let's say, i have defined a system where with four files: system.asd, packages.lisp, file1.lisp, file2.lisp, where file1 and file2 share the same package and are split more or less only for better organisation purpose. So in packages.lisp i define only one package and use the respective in-package expression for it in the beginning of the two files. Besides that file1 should be loaded before file2. In my asd file i have something like this: (defsystem "system" :depends-on ("ext-system") :serial t :components ((:file "packages") (:file "file1") (:file "file2"))) Trying to load this system with (ql:quickload "system") i get an error, that there is no package for file1. i discovered that when i define a package for file1, although never use it, things work as i want. Does one have to define a package for each file listed in :components? Is there some other, more suitable way to fulfil my purpose (use the same package in both files? Thanks for any help Matus

2 2

[asdf-devel] Disabling "built-in" output translation
by Mark Evenson 21 Jun '11

21 Jun '11

ASDF contains some specialized code for ABCL that enable the translation of ASDF systems whose source is packaged into jar files to locate the corresponding object files in ASDF's user cache. In trying to figure out the correct mechanism to allow for "binary" ASDF distribution under ABCL that would include both the source and the fasls in the same jar file, I need to disable the jar file translation mechanism. I expected that invoking DISABLE-OUTPUT-TRANSLATIONS would clear this built-in translation mechanism, but it doesn't seem to do this. Only invoking CLEAR-OUTPUT-TRANSLATIONS seems to actually change the output translation map. To wit: ASDF> (disable-output-translations) ((T T) (#P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*" T) (#P"/___jar___file___root___/**/*.*" #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*") (#P"jar:file:/**/*.jar!/**/*.*" #<FUNCTION TRANSLATE-JAR-PATHNAME {771931F8}>) (T #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*")) ASDF> (output-translations) ((#P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*" T) (#P"/___jar___file___root___/**/*.*" #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*") (#P"jar:file:/**/*.jar!/**/*.*" #<FUNCTION TRANSLATE-JAR-PATHNAME {771931F8}>) (T T) (T #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*")) ASDF> (disable-output-translations) ((T T) (#P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*" T) (#P"/___jar___file___root___/**/*.*" #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*") (#P"jar:file:/**/*.jar!/**/*.*" #<FUNCTION TRANSLATE-JAR-PATHNAME {771931F8}>) (T #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*")) ASDF> (output-translations) ((#P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*" T) (#P"/___jar___file___root___/**/*.*" #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*") (#P"jar:file:/**/*.jar!/**/*.*" #<FUNCTION TRANSLATE-JAR-PATHNAME {771931F8}>) (T T) (T #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*")) ASDF> (clear-output-translations) ; No value ASDF> (output-translations) NIL ASDF> Should DISABLE-OUTPUT-TRANSLATIONS actually push that (T T) list into the beginning of that (OUTPUT-TRANSLATION) list or does the API expect that the user use it something like ASDF> (setf (output-translations) (disable-output-translations)) Should ASDF under ABCL strip out the jar translation mechanism as well, or should the ASDF API expect that the user would actual issue a (CLEAR-OUTPUT-TRANSLATIONS)? I confess that I am a bit confused when one would ever use DISABLE-OUTPUT-TRANSLATIONS as opposed to CLEAR-OUTPUT-TRANSLATIONS. Once I understand the ASDF API here a bit better, I will work on the necessary ABCL specific ASDF patches if necessary. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 6

Re: [asdf-devel] [Sbcl-devel] Logical pathnames vs ASDF & SBCL
by Zach Beane 17 Jun '11

17 Jun '11

"Scott L. Burson" <Scott(a)sympoiesis.com> writes: > On Mon, Jun 13, 2011 at 6:17 AM, Faré <fahree(a)gmail.com> wrote: >> I don't see why you believe that ASDF 1.x isn't a viable option. > > I'm not among those having trouble with ASDF v2, but I would just > point out that going back to v1 has been made rather unattractive by > the tremendous usefulness of Quicklisp, which AFAIK depends on v2. No, it doesn't. When I started sharing Quicklisp, some implementations didn't ship ASDF at all, so it made sense to bundle a copy and load it if necessary. ASDF2 seemed like the reasonable thing to bundle. The feature of ASDF2 that makes Quicklisp work better is implementation FASL segregation enabled by default. Zach

1 0

[asdf-devel] Logical pathnames vs ASDF & SBCL
by Faré 17 Jun '11

17 Jun '11

TL;DR: ASDF currently doesn't play so well with logical pathnames. I'm seeking advice on how to make things better — or on whether it's worth the trouble. Dear all, Pascal's recent plight with logical pathnames on SBCL once again rises the issue of how much ASDF (or SBCL) should support logical pathname users, and how they should behave to make logical pathname users happy. With case-sensitivity issues, things only get worse! (Note: personally inviting James Anderson to the discussion, since he's the only strong proponent and user of logical pathnames I know.) REMINDER ABOUT LOGICAL PATHNAMES (LPNs) So, the CLHS says LPNs are case-converted to upper-case, portably restricted to such upper-case characters, and get translated to physical pathnames in an implementation-dependent way. On Unix, with its case-sensitive filesystems and lower-case conventions, the useful thing is then downcasing names. At least SBCL and CLISP follow both the standard and the useful pathname mapping convention. SBCL goes on to length to throw an error when non-portable code tries to break the standard restrictions on logical-pathnames; CLISP will let you manually make-pathname a LPN with lower-case or mixed-case characters, but will still downcase them at the end (the latest CLISP 2.49 also seems to not want to create a logical pathname with parse-namestring). CCL tries to make users happy by leaving the logical pathname host case-insensitive (per the standard) but case-preserving, and being case-sensitive in the rest of the pathname (if you want upper-case, you know where to find it). To collect and analyze the behavior of each of 14 implementations is left as an exercise to the logical-pathname loving reader [M20]. To devise, document and get implementations to adopt a common behavior that would be universally accepted by all is left as another exercise [50]. ASDF NAMING OF SYSTEMS Similarly, when naming an ASDF system, to allow to designate systems with symbols (CL legacy), which are case-converted, yet map them to a unixy lower-case name, and still allow systems with all kind of cases, symbols are downcased whereas strings preserved. Then the filesystem is queried with the resulting normalized string name (see function coerce-name). Now with its good old central-registry, ASDF used to query each directory every time a system was requested. This works great with logical pathnames, as it defers all case handling to the last minute, and allows .asd files to be loaded with a LPN as the *load-pathname*. However, this was somewhat slow, and it didn't scale to recursively searching directories, and so came the habit of creating "link farms", single directories with plenty of symlinks to adequate .asd files. Of course, symlinks are both not so portable (not very well supported in Windows, if at all, though later versions of ASDF recognize Windows shortcuts as a substitute), and a maintenance nightmare (unlike Macintosh aliases, they are not automatically updated when a system is installed, moved or deleted). Therefore link farms were not a good interface to end-users. For ASDF 2, I implemented a new way to manage system files: the source-registry. It allows you to specify trees to search recursively as well as single directories. Whether the registry is searched lazily (when a system is requested) or eagerly (one the first time around) or yet something else, was left unspecified. In my first implementation of it, I built upon the previous central-registry, and at initialization time I was looking for which subdirectories in the specified trees did contain .asd files, then saved these in a list that I consulted in the very same way as the central-registry. (Note: the central registry is still there, and consulted first.) However, DIRECTORY returns fully resolved TRUENAMEs, and any portable way of searching inside subdirectories is doomed to squash away logical pathnames. Currently, any use of :tree in source-registry will resolve into physical pathnames (PPNs) on most implementations, and always did. However, entries with :directory used to preserve LPNs. Not so with 2.014.7, where, prompted by a Quicklisp feature request, I implemented eager caching of ASDF systems. So I query DIRECTORY and save the results in a hash-table indexed by pathname-name. The table is case-sensitive, to reflect the case-sensitive names of ASDF. One consequence is that :directory entries do not preserve LPNs anymore. Another more subtle consequence is that things may go wrong if your filesystem is case-insensitive but case-preserving. In the old way of doing things (still available with the central-registry), you'd typically be looking for the file with lower-case name, and you would find it even if named in different cases on disk. With the old way, you'll record the name in its case mix, and will never match it against the (lowercase) name. So some systems that depend on this behavior will disappear. POTENTIAL SOLUTIONS An easy way out is to declare that ASDF from now on shall be case-insensitive, using EQUALP to compare system names and in hash-tables that cache system files. Another way out is to declare that ASDF is still case sensitive, and that the only case allowed is lower-case for physical filenames. Any system that doesn't work with this new interpretation probably didn't work portably with the old one, anyway. A harder way out would be to assume case-sensitivity in the filesystem (since some filesystems are case-sensitive, and any asd file that depends on case-insensitivity is non-portable and deserves to lose), and make extra effort when using DIRECTORY against logical pathnames to always reconstitute LPNs from the PPNs given by directory, and drop the reconstituted results if they don't resolve to the same thing. But is it worth the pain? Finally, I could do nothing, and assume that people who go through the pain of setting up logical pathnames before they run ASDF can just as well setup the *central-registry* and have LPNs be recognized in the good old way. If you use the source-registry, your LPNs will be squashed, and nothing will break in the code since code works fine with PPNs, just like most everyone use it, but your debug information will be stored according to the PPN, not the LPN. Meh. Zach (if you're still reading), do any systems in the wild use anything but lower-case names for system files? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Two members of the Political Police salute a giant portrait of our Great Leader - Comrade, do you think the same as I do? inquires the first one, with a sincere gaze pleeing into his colleagues' eyes. - Comrade, the second one replies and returns the same gaze: yes, I do. - In that case, comrade, you're under arrest! concludes the first one.

7 10