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

[asdf-devel] Feature Request: Better Error Reporting
by Seth Burleigh 11 Sep '10

11 Sep '10

I was wondering if it was possible for some better error reporting. For example, when i was compiling kenny's cl-opengl, this is what i get: ; compiling (DEFVAR *OPENGL-DLL* ...) ; compiling (DEFUN CL-OPENGL-LOAD ...) ; compiling (CL-OPENGL-LOAD) ; compiling (DEFUN GL-BOOLEAN-TEST ...) ; compiling (DFENUM STORAGETYPE ...) ; compiling (DFENUM FILTERTYPES ...) ; /home/seth/install/lisp/cello/cl-opengl/sbcl-1.0.38-linux-x86/cl-opengl.fasl written ; compilation finished in 0:00:00.045 WARNING: COMPILE-FILE warned while performing #<COMPILE-OP NIL {CB49DA9}> on #<CL-SOURCE-FILE "cl-opengl" {BD132C1}>. And then i get thrown into the slime debugger with a very nonhelpful error: compile-opp nil? Cant asdf give us the actual error thrown? This has happened multiple times on many libraries.

4 14

[asdf-devel] CMUCL error
by Devon Sean McCullough 06 Sep '10

06 Sep '10

Today's bleeding-edge ASDF fails to compile in CMUCL 1 compiler notes: ../asdf/asdf.lisp:3371:1: error: (during macroexpansion) Error in FDEFINITION: the function MODULE-COMPONENTS-BY-NAME is undefined. Compilation failed. Peace --Devon /~\ \ / Health Care X not warfare / \ PS: compiles fine in ACL

2 1

[asdf-devel] spurious warnings patch for CMUCL
by Devon Sean McCullough 06 Sep '10

06 Sep '10

Fix two unreachable code removal warnings in CMUCL: diff -Bbdur old/asdf/asdf.lisp new/asdf/asdf.lisp --- old/asdf/asdf.lisp 2010-05-21 17:18:04.000000000 -0400 +++ new/asdf/asdf.lisp 2010-05-22 17:01:06.000000000 -0400 @@ -492,7 +492,7 @@ (let* ((specified (pathname specified)) (defaults (pathname defaults)) (directory (pathname-directory specified)) - #-sbcl (directory (if (stringp directory) `(:absolute ,directory) directory)) + #-(or cmu sbcl) (directory (if (stringp directory) `(:absolute ,directory) directory)) (name (or (pathname-name specified) (pathname-name defaults))) (type (or (pathname-type specified) (pathname-type defaults))) (version (or (pathname-version specified) (pathname-version defaults)))) @@ -734,7 +734,7 @@ (directory (pathname-directory p))) (when (typep p 'logical-pathname) (return p)) (ignore-errors (return (truename p))) - #-sbcl (when (stringp directory) (return p)) + #-(or cmu sbcl) (when (stringp directory) (return p)) (when (not (eq :absolute (car directory))) (return p)) (let ((sofar (ignore-errors (truename (pathname-root p))))) (unless sofar (return p)) Peace --Devon /~\ \ / Health Care X not warfare / \ PS: Is this a good venue for patches?

2 1

[asdf-devel] ASDF 2.000 released!
by Faré 31 May '10

31 May '10

Dear Common Lispers, I have finally released ASDF 2, officially starting with release 2.000. http://common-lisp.net/project/asdf/ ASDF 2 is an evolution of ASDF that tries to be backwards compatible with previous releases and their many extensions, while at the same time improving the user experience in many important ways. I have worked hard towards reaching the current state, which I believe is now suitable for release and for inclusion in all Common Lisp implementations. I thank all those who helped develop and test this release, including Robert P. Goldman, James Anderson, Juan-Jose Garcia-Ripoll, and many more. We welcome bug reports on our launchpad site: https://launchpad.net/asdf I'm using ASDF 2 at ITA. Recent versions are already included in ABCL, CCL, CMUCL, ECL. Several hackers have tried building plenty of packages with it. While it's far from my ideal of perfection, and admittedly only a relatively small limited of previous code, I believe it's enough of an advance over the previous generation of ASDF that I'd like to get it out to the world. The code has been extensively cleaned up while preserving previous semantics everywhere that it was well-defined. Our testing has revealed no regressions from ASDF 1. What has changed since ASDF 1 is documented at the following page: http://common-lisp.net/project/asdf/asdf/FAQ.html Improvements include: * portable naming of files wrt directory, type, host/device, etc. * a builtin user-configurable output translation mechanism, superseding asdf-binary-locations and previous hacks in common-lisp-controller and cl-launch. * a user-configurable source registry system for finding systems (the old *central-registry* is still available). * improved portability to many implementations. * improved support for Windows. * many bug fixes * better documentation * the test suite, while still largely incomplete, covers more cases and is more robust across implementations. * substantial performance improvements when processing large systems with thousands of components. * API improvements: load-system, system-relative-pathname, etc. * a sensible versioning system for ASDF 2 itself. * ASDF can be now be upgraded in a running lisp image. Using this in-place upgrade, ASDF releases can be decoupled from implementation releases. * better support for various extensions used by ECL and ABCL, and also by POIU, ASDF-DEPENDENCY-GROVEL. Pitfalls include: * Output translations is enabled by default. This may surprise some users, most of them in pleasant way (we hope), a few of them in an unpleasant way. It is trivial to disable output translations. Simply put (ASDF:DISABLE-OUTPUT-TRANSLATIONS) in a Lisp startup file. * Some systems in the large have been known not to play well with asdf output translations. They were easy to fix. The most likely issue is to have chaining of operations (e.g., a preprocessing before a load) where the INPUT-FILES of one operation are related to the OUTPUT-FILES of another. In this case many issues can be avoided by simply making the OUTPUT-FILES primary, and having later operations' INPUT-FILES be defined in terms of the OUTPUT-FILES of other operations instead of directly defining the INPUT-FILES. It is also easy to disable output translations or override its configuration. * ASDF 2 output translations do not work with ASDF-Binary-Locations. They replace A-B-L, and include a compatibility mode to emulate your previous A-B-L configuration. See ENABLE-ASDF-BINARY-LOCATIONS-COMPATIBILITY. But you shouldn't load ABL on top of ASDF 2. * A notable performance bug on SBCL (and possibly other implementations, too): the recursive search of configured paths in your source-registry with (DIRECTORY "/configured/path/**/*.asd") can waste a few seconds when initially searching for asd files (depending on your configuration). If it is essential for you to avoid this pause, you should override the default source-registry and only use non-recursive :DIRECTORY options (or shallow trees). Or just keep the default directory hierarchies being searched empty. * Windows support may have been insufficiently well tested. As to how to best include ASDF in your implementation, here is an excerpt from the FAQ section of our manual: 12.3.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?" Starting with current candidate releases of ASDF 2, it should always be a good time to upgrade to a recent version of ASDF. You may consult with the maintainer for which specific version they recommend, but the latest RELEASE should be correct. We trust you to thoroughly test it with your implementation before you release it. If there are any issues with the current release, it's a bug that you should report upstream and that we will fix ASAP. In order to report bugs, please use the launchpad bug tracker. Information about launchpad is contained in the manual. As to how to include ASDF, we recommend the following: * If ASDF isn't installed yet, then (require :asdf) should load the version of ASDF that is bundled with your system. You may have it load some other version configured by the user, if you allow such configuration. * If your system provides a mechanism to hook into CL:REQUIRE, then it would be nice to add ASDF to this hook the same way that SBCL, ECL, CMUCL, CCL and ABCL do. * You may, like SBCL, have ASDF be implicitly used to require systems that are bundled with your Lisp distribution. If you do have a few magic systems that come with your implementation in a precompiled way such that one should only use the binary version that goes with your distribution, like SBCL does, then you should add them in the beginning of wrapping-source-registry. Please consult with the ASDF maintainers about that. * If you have magic systems as above, then we explicitly ask you to NOT distribute asdf.asd as part of those magic systems. You should still include the file asdf.lisp in your source distribution and precompile it in your binary distribution, but asdf.asd if included at all, should be secluded from the magic systems, in a separate file hierarchy, or you may otherwise rename the system and its file to e.g. asdf-ecl and asdf-ecl.asd, or sb-asdf and sb-asdf.asd. If you make asdf.asd a magic system, then users will no longer be able to upgrade ASDF using ASDF itself. It is helpful to be able to do this in order for users to be able to use an ASDF version of their own choosing that they maintain independently from your Lisp distribution. * If you do not have any such magic systems, or have other non-magic systems that you want to bundle with your implementation, then you may add them to the default-source-registry, and you are welcome to include asdf.asd amongst them. * Please send us upstream any patches you make to ASDF itself, so we can merge them back in for the benefit of your users when they upgrade to the upstream version. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Chuangtse and Hueitse had strolled onto the bridge over the Hao, when the former observed, ``See how the small fish are darting about! That is the happiness of the fish.'' ``You are not a fish yourself,'' said Hueitse. ``How can you know the happiness of the fish?'' ``And you not being I,'' retorted Chuangtse, ``how can you know that I do not know?'' — Chuangtse, circa 300 B.C.

1 0

[asdf-devel] question about relative pathname to point to parent directory
by Robert Goldman 26 May '10

26 May '10

What's the right syntax for specifying a relative pathname for a module whose files should live in the parent directory instead of in a subdirectory? E.g., if I have (:module foo :components ((:file "bar") (:file "baz")) :pathname ???? ) what goes in there if I do NOT want the files to live in foo/, but with all the other files? I could put a FAQ about this in the manual... best, r

2 6

[asdf-devel] Question about pathnames discussion in the manual
by Robert Goldman 26 May '10

26 May '10

Currently, the manual's discussion about logical pathnames states: "Moreover, the `asdf-output-translation' layer will avoid trying to resolve and translate logical-pathnames, so you can define yourself what translations you want to use with the logical pathname facility." IIUC, since a-o-t does not handle logical pathnames, it's not so much that you /can/ define the translations you want to use with the l-p facility as that you /must/ define the translations, or your binaries will go untranslated. Do I understand this correctly? If so, any objection to my strengthening the wording here? I am making some minor tweaks to this section, which I was just in because I was on irc the other day helping Stellian and Raymond with some pathname issues in ASDF 2 compatibility. Best, r

2 1

[asdf-devel] Planning to release ASDF 2 next monday
by Faré 25 May '10

25 May '10

I found and fixed a bug last Friday, which is why I didn't release yet. If no new bug is found, I'd like to release ASDF 2 next monday. In the meantime, can you all test the latest ASDF (current: 1.728) with your favorite Lisp implementation, packages, etc. ? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Clothes make the man. Naked people have little or no influence on society. — Mark Twain

1 0

[asdf-devel] ASDF2: Bug in merge-pathnames*
by Jean-Claude Beaudoin 19 May '10

19 May '10

Here is a patch against 1.720 that fixes a weakness in merge-pathnames*. This was a show stopper in my system. It seems that merge-pathnames* assumes that *default-pathname-defaults* has some interesting value to contribute which is not always the case. In my system and in a few others (clisp comes to mind) the usual value of *default-pathname-defaults* is #P"" which ends up giving (pathname-directory *default-pathname-defaults*) => nil Then, (append nil (cdr directory)) is probably not a "valid pathname directory". In clisp passing this not so "valid pathname directory" to make-pathname will result in a visit in the debugger... I want also to insist again on the issue of accessing the process current directory. Assuming that *default-pathname-defaults* is a substitute for the process current directory is not portable ANSI Common Lisp code. The following definition is very likely to be wrong on at least one ANSI Common Lisp conforming implementation: (defun current-directory () (truenamize (pathname-directory-pathname *default-pathname-defaults*))) Cheers, Jean-Claude Beaudoin ------- > diff asdf-1.720/asdf.lisp asdf.lisp 519c520,522 < (append (pathname-directory defaults) (cdr directory)) --- > (if (pathname-directory defaults) > (append (pathname-directory defaults) (cdr directory)) > directory)

2 3

[asdf-devel] :exclude in source-registry.conf getting ignored.
by szergling 16 May '10

16 May '10

Hi list, Is it intended that :exclude in ~/.config/common-lisp/source-registry.conf should come before the :tree directive(s)[1]? To me, the manual seems to specify that the order in which the directives are provided does not matter. I'm using asdf version "1.720". To set the context, and perhaps as another question, I was originally investigating if it was possible to exclude a specific tree (sure, matching a pattern works and is good enough) or directory, or have some other way to suppress the loading of duplicated systems (usually repo branches). Yong. [1] Compare: With this in the user config file, (:source-registry (:exclude "asdf-exclude") (:tree "/home/tyc20/lisp/") :ignore-inherited-configuration) > (flatten-source-registry) ==>((#P"/home/tyc20/lisp/imp/sbcl-1.0.29-x86-linux/install/lib/sbcl/" :RECURSE T :EXCLUDE (".bzr" ".cdv" "~.dep" "~.dot" "~.nib" "~.plst" ".git" ".hg" ".pc" ".svn" "CVS" "RCS" "SCCS" "_darcs" "_sgbak" "autom4te.cache" "cover_db" "_build")) (#P"/home/tyc20/lisp/" :RECURSE T :EXCLUDE ("asdf-exclude"))) With this in the config file instead: (:source-registry (:tree "/home/tyc20/lisp/") (:exclude "asdf-exclude") :ignore-inherited-configuration) > (flatten-source-registry) ==>((#P"/home/tyc20/lisp/imp/sbcl-1.0.29-x86-linux/install/lib/sbcl/" :RECURSE T :EXCLUDE (".bzr" ".cdv" "~.dep" "~.dot" "~.nib" "~.plst" ".git" ".hg" ".pc" ".svn" "CVS" "RCS" "SCCS" "_darcs" "_sgbak" "autom4te.cache" "cover_db" "_build")) (#P"/home/tyc20/lisp/" :RECURSE T :EXCLUDE (".bzr" ".cdv" "~.dep" "~.dot" "~.nib" "~.plst" ".git" ".hg" ".pc" ".svn" "CVS" "RCS" "SCCS" "_darcs" "_sgbak" "autom4te.cache" "cover_db" "_build")))

3 4

[asdf-devel] 1.721
by Faré 11 May '10

11 May '10

I made an incompatible change in 1.721: before that, it was a *convention* that configuration files in configuration directories :include'd by the source-registry or the output-translations configuration should have :type "conf". This interacted poorly with backup files stored in same directory by default by various editors. There was also the confusing issue that "*.*" would match anything on some implementations (e.g. SBCL) but only files with a . in their name in others (e.g. CLISP). So I made the convention something enforced and this should change the problem, at the cost of backwards incompatibility with whoever started using that feature while defying the convention. Otherwise, I've made a few changes based on feedback from various people, whom I thank. I also strongly disrecommend releases 1.714 to 1.718 that have a bug in an incomplete cleanup that prevent them from loading some systems that use symbols to name components, such as fiveam and many more. My apologies for the change. The same cleanup seems to have broken ASDF-INSTALL (one line change needed, oops), and anyone who previously defined methods on the internal function find-component (in retrospect, I should have changed the name of the function.) [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] If normative judgments cannot be rational, then science is actually useless. — François Guillaumat

1 0

[asdf-devel] Fwd: Re: [Openmcl-devel] asdf 2 imported into trunk
by Robert Goldman 08 May '10

08 May '10

This was in the openmcl-devel list. Question: should we bundle a version of ASDF-INSTALL that's known to be compatible? Is there someone we should be talking to who maintains ASDF-INSTALL? cheers, r -------- Original Message -------- Subject: Re: [Openmcl-devel] asdf 2 imported into trunk Date: Fri, 07 May 2010 17:27:53 -0400 From: Raffael Cavallaro <raffaelcavallaro(a)mac.com> To: openmcl-devel <openmcl-devel(a)clozure.com> On May 5, 2010, at 10:53 PM, R. Matthew Emerson wrote: > I just updated the trunk's bundled ASDF from upstream. > > http://common-lisp.net/project/asdf/ > > The ASDF maintainers consider this version of ASDF to > be a release candidate. > > http://common-lisp.net/project/asdf/asdf/FAQ.html includes > an entry describing what has changed since ASDF 1. > > One notable pitfall: ASDF 2 is not compatible with > asdf-binary-locations. ASDF 2 now includes similar > functionality itself. Please read the FAQ link above > for more information. > > Please test it out on your systems. If you find a bug, > please report it at https://launchpad.net/asdf or use the asdf > mailing list: http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel FWIW, I ran into an issue with the new version of asdf (i.e., asdf 2) and the latest asdf-install. There's a simple, one line fix to the most recent asdf-install to make it work with the asdf 2. In the file installer.lisp which is part of asdf-install, an around method for the generic function find-component has an incompatible lambda list. The latest version of installer.lisp from asdf-install has this: (defmethod asdf:find-component :around ((module (eql nil)) name &optional version) (declare (ignore version)) ... just remove the &optional parameter and the subsequent declaration: (defmethod asdf:find-component :around ((module (eql nil)) name) ... and now asdf-install will load and work properly. (well, it still doesn't pass its own test suite because it tries to use an illegal character in a filename when writing its report, but it does successfully install asdf-installable systems). warmest regards, Ralph Raffael Cavallaro raffaelcavallaro(a)me.com _______________________________________________ Openmcl-devel mailing list Openmcl-devel(a)clozure.com http://clozure.com/mailman/listinfo/openmcl-devel

3 2

[asdf-devel] ccl nit-picking
by R. Matthew Emerson 07 May '10

07 May '10

ccl:getenv and ccl:*module-provider-functions* are exported symbols. In wrapping-output-translations, there are other options to using (ccl::ccl-directory). The pathname #p"ccl:" always refers to the ccl directory, so it'd probably be nicer to use that.

1 0

[asdf-devel] [bugfix] Fix ABCL loading ASDF definitions from jars under Windows
by Mark Evenson 06 May '10

06 May '10

Attached please find a patch which fixes problems pointed out by Carlos Ungil when ABCL would catastrophically fail to translate the output location for ASDF systems located within jar files under Windows. We've fixed this in the version of ASDF 1.679 which we are planning to ship as part of abcl-0.20.0 in the next week. After ASDF goes through the shakedown of your code-freeze over the next two weeks, we'll pick up the end result to ship as part abcl-0.21.0, if this seems reasonable to the ASDF developers. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 4

[asdf-devel] Including ASDF 2 in the next CLISP release
by Faré 04 May '10

04 May '10

Dear CLISP developers, could you test for inclusion with your implementation the current release candidate of ASDF 2 (version 1.715 as of this writing)? http://common-lisp.net/project/asdf/ ASDF 2 is an evolution of ASDF that tries to be backwards compatible with previous releases and their many extensions, while at the same time improving the user experience in many important ways. I have worked hard towards reaching the current state, which I believe is now suitable for release. Could you please send us fixes for any glaring bugs, and otherwise include ASDF 2 in any alpha-testing release channel for users of your implementation? I think it's mostly ready, and I'd like to have it widely tested before the actual release, which I hope will happen this month of May 2010, hopefully without any code change (except maybe for some tweaks to enhance support for some Lisp implementations on some operating systems), and with slightly enhanced documentation (notably based on your feedback). I'm using ASDF 2 at ITA. Recent versions are already included in ECL and ABCL. Several hackers have tried building plenty of packages with it. While it's far from my ideal of perfection, and admittedly only a relatively small limited of previous code, I believe it's enough of an advance over the previous generation of ASDF that I'd like to get it out to the world. The code has been extensively cleaned up while preserving previous semantics everywhere that it was well-defined. Our testing has revealed no regressions from ASDF 1. What has changed since ASDF 1 is documented at the following page: http://common-lisp.net/project/asdf/asdf/FAQ.html Improvements include: * portably handle naming of files wrt directory, type, host/device, etc. * a builtin user-configurable output translation mechanism, superseding asdf-binary-locations and previous hacks in common-lisp-controller and cl-launch. * a user-configurable source registry system for finding systems (the old *central-registry* is still available). * improved portability to many implementations. * improved support for Windows (though we still lack implementation-dependent configuration support except on LispWorks). [NOTE: I couldn't parse this item. I juggled the sentence structure, but I still don't get it. What kind of configuration support is needed for Windows? What aspects of configuration that we have on other OSes is missing from Windows?] * many bug fixes * better documentation * the test suite, while still largely incomplete, covers more cases and is more robust across implementations. * substantial performance improvements when processing large systems with thousands of components. * API improvements: load-system, system-relative-pathname, etc. * a sensible versioning system for ASDF 2 itself. * ASDF can be now be upgraded in a running lisp image. Using this in-place upgrade, ASDF releases can be decoupled from implementation releases. * better support for various extensions used by ECL and ABCL, and also by POIU, ASDF-DEPENDENCY-GROVEL. Pitfalls include: * Output translations is enabled by default. This may surprise some users, most of them in pleasant way (we hope), a few of them in an unpleasant way. It is trivial to disable output translations. Simply put (ASDF:DISABLE-OUTPUT-TRANSLATIONS) in a lisp startup file. * Some systems in the large have been known not to play well with asdf output translations. They were easy to fix. The most likely issue is to have chaining of operations (e.g., a preprocessing before a load) where the INPUT-FILES of one operation are related to the OUTPUT-FILES of another. In this case many issues can be avoided by simply making the OUTPUT-FILES primary, and having later operations' INPUT-FILES be defined in terms of the OUTPUT-FILES of other operations instead of directly defining the INPUT-FILES. It is also easy to disable output translations or override its configuration. * ASDF 2 output translations do not work with ASDF-Binary-Locations. They replace A-B-L, and include a compatibility mode to emulate your previous A-B-L configuration. See ENABLE-ASDF-BINARY-LOCATIONS-COMPATIBILITY. But you shouldn't load ABL on top of ASDF 2. * A notable performance bug on SBCL (and possibly other implementations, too): the recursive search of configured paths in your source-registry with (DIRECTORY "/configured/path/**/*.asd") can waste a few seconds when initially searching for asd files (depending on your configuration). If it is essential for you to avoid this pause, you should override the default source-registry and only use non-recursive :DIRECTORY options (or shallow trees). * On Windows, when not using cygwin, only LispWorks has proper defaults for configuration pathnames. Other implementations make do. Patches welcome. * Windows support has not been sufficiently well tested. As to how to best include ASDF in your implementation, here is an excerpt from the FAQ section of our manual: 12.3.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?" Starting with current candidate releases of ASDF 2, it should always be a good time to upgrade to a recent version of ASDF. You may consult with the maintainer for which specific version they recommend, but the latest RELEASE should be correct. We trust you to thoroughly test it with your implementation before you release it. If there are any issues with the current release, it's a bug that you should report upstream and that we will fix ASAP. In order to report bugs, please use the launchpad bug tracker. Information about launchpad is contained in the manual. As to how to include ASDF, we recommend the following: * If ASDF isn't installed yet, then (require :asdf) should load the version of ASDF that is bundled with your system. You may have it load some other version configured by the user, if you allow such configuration. * If your system provides a mechanism to hook into CL:REQUIRE, then it would be nice to add ASDF to this hook the same way that SBCL, CCL and ABCL do. * You may, like SBCL, have ASDF be implicitly used to require systems that are bundled with your Lisp distribution. If you do have a few magic systems that come with your implementation in a precompiled way such that one should only use the binary version that goes with your distribution, like SBCL does, then you should add them in the beginning of wrapping-source-registry. Please consult with the ASDF maintainers about that. * If you have magic systems as above, then we explicitly ask you to NOT distribute asdf.asd as part of those magic systems. You should still include the file asdf.lisp in your source distribution and precompile it in your binary distribution, but asdf.asd if included at all, should be secluded from the magic systems, in a separate file hierarchy, or you may otherwise rename the system and its file to e.g. asdf-ecl and asdf-ecl.asd, or sb-asdf and sb-asdf.asd. If you make asdf.asd a magic system, then users will no longer be able to upgrade ASDF using ASDF itself. It is helpful to be able to do this in order for users to be able to use an ASDF version of their own choosing that they maintain independently from your Lisp distribution. * If you do not have any such magic systems, or have other non-magic systems that you want to bundle with your implementation, then you may add them to the default-source-registry, and you are welcome to include asdf.asd amongst them. * Please send us upstream any patches you make to ASDF itself, so we can merge them back in for the benefit of your users when they upgrade to the upstream version. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "Necessity is the mother of invention" is a silly proverb. "Necessity is the mother of futile dodges" is much nearer the truth. — Alfred North Whitehead

1 0

[asdf-devel] Including ASDF 2 in the next SBCL release
by Faré 04 May '10

04 May '10

Dear SBCL developers, could you test for inclusion with your implementation the current release candidate of ASDF 2 (version 1.715 as of this writing)? http://common-lisp.net/project/asdf/ ASDF 2 is an evolution of ASDF that tries to be backwards compatible with previous releases and their many extensions, while at the same time improving the user experience in many important ways. I have worked hard towards reaching the current state, which I believe is now suitable for release. Could you please send us fixes for any glaring bugs, and otherwise include ASDF 2 in any alpha-testing release channel for users of your implementation? I think it's mostly ready, and I'd like to have it widely tested before the actual release, which I hope will happen this month of May 2010, hopefully without any code change (except maybe for some tweaks to enhance support for some Lisp implementations on some operating systems), and with slightly enhanced documentation (notably based on your feedback). I'm using ASDF 2 at ITA. Recent versions are already included in ECL and ABCL. Several hackers have tried building plenty of packages with it. While it's far from my ideal of perfection, and admittedly only a relatively small limited of previous code, I believe it's enough of an advance over the previous generation of ASDF that I'd like to get it out to the world. The code has been extensively cleaned up while preserving previous semantics everywhere that it was well-defined. Our testing has revealed no regressions from ASDF 1. What has changed since ASDF 1 is documented at the following page: http://common-lisp.net/project/asdf/asdf/FAQ.html Improvements include: * portably handle naming of files wrt directory, type, host/device, etc. * a builtin user-configurable output translation mechanism, superseding asdf-binary-locations and previous hacks in common-lisp-controller and cl-launch. * a user-configurable source registry system for finding systems (the old *central-registry* is still available). * improved portability to many implementations. * improved support for Windows (though we still lack implementation-dependent configuration support except on LispWorks). [NOTE: I couldn't parse this item. I juggled the sentence structure, but I still don't get it. What kind of configuration support is needed for Windows? What aspects of configuration that we have on other OSes is missing from Windows?] * many bug fixes * better documentation * the test suite, while still largely incomplete, covers more cases and is more robust across implementations. * substantial performance improvements when processing large systems with thousands of components. * API improvements: load-system, system-relative-pathname, etc. * a sensible versioning system for ASDF 2 itself. * ASDF can be now be upgraded in a running lisp image. Using this in-place upgrade, ASDF releases can be decoupled from implementation releases. * better support for various extensions used by ECL and ABCL, and also by POIU, ASDF-DEPENDENCY-GROVEL. Pitfalls include: * Output translations is enabled by default. This may surprise some users, most of them in pleasant way (we hope), a few of them in an unpleasant way. It is trivial to disable output translations. Simply put (ASDF:DISABLE-OUTPUT-TRANSLATIONS) in a lisp startup file. * Some systems in the large have been known not to play well with asdf output translations. They were easy to fix. The most likely issue is to have chaining of operations (e.g., a preprocessing before a load) where the INPUT-FILES of one operation are related to the OUTPUT-FILES of another. In this case many issues can be avoided by simply making the OUTPUT-FILES primary, and having later operations' INPUT-FILES be defined in terms of the OUTPUT-FILES of other operations instead of directly defining the INPUT-FILES. It is also easy to disable output translations or override its configuration. * ASDF 2 output translations do not work with ASDF-Binary-Locations. They replace A-B-L, and include a compatibility mode to emulate your previous A-B-L configuration. See ENABLE-ASDF-BINARY-LOCATIONS-COMPATIBILITY. But you shouldn't load ABL on top of ASDF 2. * A notable performance bug on SBCL (and possibly other implementations, too): the recursive search of configured paths in your source-registry with (DIRECTORY "/configured/path/**/*.asd") can waste a few seconds when initially searching for asd files (depending on your configuration). If it is essential for you to avoid this pause, you should override the default source-registry and only use non-recursive :DIRECTORY options (or shallow trees). * On Windows, when not using cygwin, only LispWorks has proper defaults for configuration pathnames. Other implementations make do. Patches welcome. * Windows support has not been sufficiently well tested. As to how to best include ASDF in your implementation, here is an excerpt from the FAQ section of our manual: 12.3.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?" Starting with current candidate releases of ASDF 2, it should always be a good time to upgrade to a recent version of ASDF. You may consult with the maintainer for which specific version they recommend, but the latest RELEASE should be correct. We trust you to thoroughly test it with your implementation before you release it. If there are any issues with the current release, it's a bug that you should report upstream and that we will fix ASAP. In order to report bugs, please use the launchpad bug tracker. Information about launchpad is contained in the manual. As to how to include ASDF, we recommend the following: * If ASDF isn't installed yet, then (require :asdf) should load the version of ASDF that is bundled with your system. You may have it load some other version configured by the user, if you allow such configuration. * If your system provides a mechanism to hook into CL:REQUIRE, then it would be nice to add ASDF to this hook the same way that SBCL, CCL and ABCL do. * You may, like SBCL, have ASDF be implicitly used to require systems that are bundled with your Lisp distribution. If you do have a few magic systems that come with your implementation in a precompiled way such that one should only use the binary version that goes with your distribution, like SBCL does, then you should add them in the beginning of wrapping-source-registry. Please consult with the ASDF maintainers about that. * If you have magic systems as above, then we explicitly ask you to NOT distribute asdf.asd as part of those magic systems. You should still include the file asdf.lisp in your source distribution and precompile it in your binary distribution, but asdf.asd if included at all, should be secluded from the magic systems, in a separate file hierarchy, or you may otherwise rename the system and its file to e.g. asdf-ecl and asdf-ecl.asd, or sb-asdf and sb-asdf.asd. If you make asdf.asd a magic system, then users will no longer be able to upgrade ASDF using ASDF itself. It is helpful to be able to do this in order for users to be able to use an ASDF version of their own choosing that they maintain independently from your Lisp distribution. * If you do not have any such magic systems, or have other non-magic systems that you want to bundle with your implementation, then you may add them to the default-source-registry, and you are welcome to include asdf.asd amongst them. * Please send us upstream any patches you make to ASDF itself, so we can merge them back in for the benefit of your users when they upgrade to the upstream version. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] There are just two rules of governance in a free society: Mind your own business. Keep your hands to yourself. — P. J. O'Rourke

1 0

[asdf-devel] asdf2 reloads already loaded fasls
by Alan Ruttenberg 04 May '10

04 May '10

Situation: abcl there is a newer compiled file than source file calling load-op on the system with this file causes the fasl to be repeatedly loaded. The reason, it appears: (defmethod perform ((o load-op) (c cl-source-file)) #-ecl (mapcar #'load (input-files o c)) #+ecl (loop :for i :in (input-files o c) :unless (string= (pathname-type i) "fas") :collect (let ((output (compile-file-pathname (lispize-pathname i)))) (load output)))) compared to (defmethod perform ((o load-source-op) (c cl-source-file)) (let ((source (component-pathname c))) (setf (component-property c 'last-loaded-as-source) (and (load source) (get-universal-time))))) i.e. the last loaded-time is recorded only when the source is loaded. -Alan

2 4

[asdf-devel] ASDF 2 frozen
by Faré 02 May '10

02 May '10

OK, so ASDF 1.711 is officially our release candidate. Consider the git master frozen for anything but bug fixes and documentation. Please use branches for any other development. My next task is to find someone responsible for every implementation to 1- test it on each supported OS 2- actually commit it downstream Below is the message I want to send to each implementation's vendor support mailing-list. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The naturalistic fallacy: "if it's natural, it's good." The anti-naturalistic fallacy: "if it's natural, it's bad." The a-naturalistic fallacy: "nature has no relationship to good and bad." ------>8------>8------>8------>8------>8------>8------>8------>8------>8------ Dear <vendor developers>, could you test the current release candidate of ASDF 2 (version 1.711) with your implementation, send us fixes for any glaring bug, and otherwise include it in any alpha-testing release channel for users of your implementation? I think it's mostly ready, and I'd like to have it widely tested before actual release. ASDF 2 is an evolution of ASDF that tries to be backwards compatible with previous releases and their many extensions, while at the same time improving the user experience. ASDF 2 is in pre-release mode. Hopefully we'll release it in May 2010 without any code change (except maybe for some tweaks to enhance support for some Lisp implementations on some operating systems), and with slightly enhanced documentation (notably based on your feedback). I'm using it ITA; recent versions are already included in ECL and ABCL; several hackers have tried building plenty of packages with it. While it's far from perfect and only a relatively small evolution, I believe it's already notably better enough than the previous generation of ASDF that I'd like to get it out to the world, and doesn't have any egregious regression from ASDF 1. What has changed since ASDF 1 is documented at the following page: http://common-lisp.net/project/asdf/asdf/FAQ.html Improvements include: * portably handle naming of files wrt directory, type, host/device, etc. * a builtin user-configurable output translation mechanism, superseding asdf-binary-locations and previous hacks in common-lisp-controller and cl-launch. * a user-configurable source registry system for finding systems (the old *central-registry* is still available) * improved portability to many implementations. * improved support for Windows (though configuration is still lacking implementation-dependent support except on LispWorks) * many bug fixes * the test suite while still largely incomplete covers more cases and is more robust across implementations. * notable performance fixes for large systems with thousands of components * API improvements: load-system, system-relative-pathname, etc. * better documentation * a sensible versioning system for ASDF 2 itself, that can be now be upgraded in a running system. This allows in the future to more easily decouple the releases of ASDF and those of your implementation. * better support various extensions as used by ECL and ABCL, and also by POIU, ASDF-DEPENDENCY-GROVEL. Main pitfalls include: * Output translations is enabled by default. This may surprise some users, most of them in pleasant way (we hope), a few of them in an unpleasant way. It is trivial to disable output translations. * Some systems in the large have been known not to play well with asdf output translations. They were easy to fix. It is also easy to disable output translations or override its configuration. * ASDF 2 output translations do not work with ASDF-Binary-Locations. They replace A-B-L, and include a compatibility mode to emulate your previous A-B-L configuration. But you shouldn't load ABL on top of ASDF 2. * A notable performance bug on SBCL: (directory "**/*.asd") can make things slower than desired when initially searching for asd files (depending on your configuration). * On Windows, when not using cygwin, only LispWorks has proper defaults for configuration pathnames. Other implementations make do. Patches welcome. Windows support is largely under-tested, too. As to how to best include ASDF in your implementation, here is an excerpt from the FAQ section of our manual: 12.3.2 “I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?” Starting with current candidate releases of ASDF 2, it should always be a good time to upgrade to a recent version of ASDF. You may consult with the maintainer for which specific version they recommend, but the latest RELEASE should be correct. We trust you to thoroughly test it with your implementation before you release it. If there are any issues with the current release, it's a bug that you should report upstream and that we will fix ASAP. As to how to include ASDF, we recommend the following: * If ASDF isn't installed yet, then (require :asdf) should load the version of ASDF that is bundled with your system. You may have it load some other version configured by the user, if you allow such configuration. * If your system provides a mechanism to hook into CL:REQUIRE, then it would be nice to add ASDF to this hook the same way that SBCL, CCL and ABCL do it. * You may, like SBCL, have ASDF be implicitly used to require systems that are bundled with your Lisp distribution. If you do have a few magic systems that come with your implementation in a precompiled way such that one should only use the binary version that goes with your distribution, like SBCL does, then you should add them in the beginning of wrapping-source-registry. * If you have magic systems as above, like SBCL does, then we explicitly ask you to NOT distribute asdf.asd as part of those magic systems. You should still include the file asdf.lisp in your source distribution and precompile it in your binary distribution, but asdf.asd if included at all, should be secluded from the magic systems, in a separate file hierarchy, or you may otherwise rename the system and its file to e.g. asdf-ecl and asdf-ecl.asd, or sb-asdf and sb-asdf.asd. Indeed, if you made asdf.asd a magic system, then users would no longer be able to upgrade ASDF using ASDF itself to some version of their preference that they maintain independently from your Lisp distribution. * If you do not have any such magic systems, or have other non-magic systems that you want to bundle with your implementation, then you may add them to the default-source-registry, and you are welcome to include asdf.asd amongst them. * Please send us upstream any patches you make to ASDF itself, so we can merge them back in for the benefit of your users when they upgrade to the upstream version. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Merely having an open mind is nothing; the object of opening the mind, as of opening the mouth, is to shut it again on something solid. — G.K. Chesterton

2 1

[asdf-devel] translate-jar-pathname : The value NIL is not of type (OR PATHNAME STRING FILE-STREAM).
by james anderson 01 May '10

01 May '10

given: [1] CL-USER(69): (lisp-implementation-type) "Armed Bear Common Lisp" [2] CL-USER(70): (lisp-implementation-version) "0.19.1" [3] CL-USER(73): asdf::*asdf-version* "1.666" asdf fails to compile alexandria. translate-jar-pathname applies namestring to the null device component of a pathname and fails. CL-USER(68): (asdf:load-system :bordeaux-threads) 0: (ASDF-UTILITIES:COERCE-NAME :BORDEAUX-THREADS) 0: COERCE-NAME returned "bordeaux-threads" 0: (ASDF-UTILITIES:COERCE-NAME "bordeaux-threads") 0: COERCE-NAME returned "bordeaux-threads" 0: (ASDF-UTILITIES:COERCE-NAME "bordeaux-threads") 0: COERCE-NAME returned "bordeaux-threads" 0: (ASDF-UTILITIES:COERCE-NAME "bordeaux-threads") 0: COERCE-NAME returned "bordeaux-threads" 0: (ASDF-UTILITIES:COERCE-NAME "bordeaux-threads") 0: COERCE-NAME returned "bordeaux-threads" 0: (ASDF::TRAVERSE #<ASDF:LOAD-OP {CF5006}> #<ASDF:SYSTEM {1F7DBD8}>) 1: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1F7DBD8}>) 1: COMPONENT-PARENT returned NIL 1: (ASDF-UTILITIES:COERCE-NAME "bordeaux-threads") 1: COERCE-NAME returned "bordeaux-threads" 1: (ASDF:FIND-COMPONENT NIL "bordeaux-threads" NIL) 2: (ASDF-UTILITIES:COERCE-NAME "bordeaux-threads") 2: COERCE-NAME returned "bordeaux-threads" 2: (ASDF-UTILITIES:COERCE-NAME "bordeaux-threads") 2: COERCE-NAME returned "bordeaux-threads" 2: (ASDF-UTILITIES:COERCE-NAME "bordeaux-threads") 2: COERCE-NAME returned "bordeaux-threads" 2: (ASDF-UTILITIES:COERCE-NAME "bordeaux-threads") 2: COERCE-NAME returned "bordeaux-threads" 2: (ASDF-UTILITIES:COERCE-NAME "bordeaux-threads") 2: COERCE-NAME returned "bordeaux-threads" 1: FIND-COMPONENT returned #<ASDF:SYSTEM {1F7DBD8}> 1: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1F7DBD8}>) 1: COMPONENT-PARENT returned NIL 1: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1F7DBD8}>) 1: COMPONENT-PARENT returned NIL 1: (ASDF::TRAVERSE #<ASDF:COMPILE-OP {AE4F8B}> #<ASDF:SYSTEM {1F7DBD8}>) 2: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1F7DBD8}>) 2: COMPONENT-PARENT returned NIL 2: (ASDF-UTILITIES:COERCE-NAME :ALEXANDRIA) 2: COERCE-NAME returned "alexandria" 2: (ASDF:FIND-COMPONENT NIL "alexandria" NIL) 3: (ASDF-UTILITIES:COERCE-NAME "alexandria") 3: COERCE-NAME returned "alexandria" 3: (ASDF-UTILITIES:COERCE-NAME "alexandria") 3: COERCE-NAME returned "alexandria" 3: (ASDF-UTILITIES:COERCE-NAME "alexandria") 3: COERCE-NAME returned "alexandria" 3: (ASDF-UTILITIES:COERCE-NAME "alexandria") 3: COERCE-NAME returned "alexandria" 3: (ASDF-UTILITIES:COERCE-NAME "alexandria") 3: COERCE-NAME returned "alexandria" 2: FIND-COMPONENT returned #<ASDF:SYSTEM {1768B0A}> 2: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1F7DBD8}>) 2: COMPONENT-PARENT returned NIL 2: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1768B0A}>) 2: COMPONENT-PARENT returned NIL 2: (ASDF::TRAVERSE #<ASDF:COMPILE-OP {1E8614A}> #<ASDF:SYSTEM {1768B0A}>) 3: (ASDF::TRAVERSE #<ASDF:COMPILE-OP {1E8614A}> #<ASDF:STATIC-FILE {7E05C4}>) 4: (ASDF:OUTPUT-FILES #<ASDF:COMPILE-OP {1E8614A}> #<ASDF:STATIC-FILE {7E05C4}>) 4: OUTPUT-FILES returned NIL T 3: TRAVERSE returned NIL 3: (ASDF::TRAVERSE #<ASDF:COMPILE-OP {1E8614A}> #<ASDF:STATIC-FILE {1AC8B37}>) 4: (ASDF:OUTPUT-FILES #<ASDF:COMPILE-OP {1E8614A}> #<ASDF:STATIC-FILE {1AC8B37}>) 4: OUTPUT-FILES returned NIL T 3: TRAVERSE returned NIL 3: (ASDF::TRAVERSE #<ASDF:COMPILE-OP {1E8614A}> #<ASDF:CL- SOURCE-FILE {F2DB2D}>) 4: (ASDF:OUTPUT-FILES #<ASDF:COMPILE-OP {1E8614A}> #<ASDF:CL-SOURCE-FILE {F2DB2D}>) 5: (ASDF:COMPONENT-PATHNAME #<ASDF:CL-SOURCE-FILE {F2DB2D}>) 6: (ASDF:COMPONENT-RELATIVE-PATHNAME #<ASDF:CL-SOURCE- FILE {F2DB2D}>) 7: (ASDF:COMPONENT-PARENT #<ASDF:CL-SOURCE-FILE {F2DB2D}>) 7: COMPONENT-PARENT returned #<ASDF:SYSTEM {1768B0A}> 7: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1768B0A}>) 7: COMPONENT-PARENT returned NIL 7: (ASDF:COMPONENT-PARENT #<ASDF:CL-SOURCE-FILE {F2DB2D}>) 7: COMPONENT-PARENT returned #<ASDF:SYSTEM {1768B0A}> 7: (ASDF:COMPONENT-PATHNAME #<ASDF:SYSTEM {1768B0A}>) 8: (ASDF:COMPONENT-RELATIVE-PATHNAME #<ASDF:SYSTEM {1768B0A}>) 9: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1768B0A}>) 9: COMPONENT-PARENT returned NIL 9: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1768B0A}>) 9: COMPONENT-PARENT returned NIL 8: COMPONENT-RELATIVE-PATHNAME returned #P"/ebs/ source/library/net/common-lisp/alexandria/" 8: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1768B0A}>) 8: COMPONENT-PARENT returned NIL 8: (ASDF-UTILITIES:TRUENAMIZE #P"/ebs/source/ metadata/net/common-lisp/bordeaux-threads/") 8: TRUENAMIZE returned #P"/ebs/source/metadata/net/ common-lisp/bordeaux-threads/" 8: (PATHNAME #P"/ebs/source/library/net/common- lisp/alexandria/") 8: PATHNAME returned #P"/ebs/source/library/net/ common-lisp/alexandria/" 8: (PATHNAME #P"/ebs/source/metadata/net/common- lisp/bordeaux-threads/") 8: PATHNAME returned #P"/ebs/source/metadata/net/ common-lisp/bordeaux-threads/" 8: (PATHNAME-DEVICE #P"/ebs/source/library/net/ common-lisp/alexandria/") 8: PATHNAME-DEVICE returned NIL 7: COMPONENT-PATHNAME returned #P"/ebs/source/ library/net/common-lisp/alexandria/" 7: (PATHNAME #P"/ebs/source/library/net/common-lisp/ alexandria/") 7: PATHNAME returned #P"/ebs/source/library/net/ common-lisp/alexandria/" 7: (PATHNAME-DEVICE #P"/ebs/source/library/net/ common-lisp/alexandria/") 7: PATHNAME-DEVICE returned NIL 6: COMPONENT-RELATIVE-PATHNAME returned #P"./ package.lisp" 6: (ASDF:COMPONENT-PARENT #<ASDF:CL-SOURCE-FILE {F2DB2D}>) 6: COMPONENT-PARENT returned #<ASDF:SYSTEM {1768B0A}> 6: (ASDF:COMPONENT-PATHNAME #<ASDF:SYSTEM {1768B0A}>) 7: (ASDF:COMPONENT-RELATIVE-PATHNAME #<ASDF:SYSTEM {1768B0A}>) 8: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1768B0A}>) 8: COMPONENT-PARENT returned NIL 8: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1768B0A}>) 8: COMPONENT-PARENT returned NIL 7: COMPONENT-RELATIVE-PATHNAME returned #P"/ebs/ source/library/net/common-lisp/alexandria/" 7: (ASDF:COMPONENT-PARENT #<ASDF:SYSTEM {1768B0A}>) 7: COMPONENT-PARENT returned NIL 7: (ASDF-UTILITIES:TRUENAMIZE #P"/ebs/source/ metadata/net/common-lisp/bordeaux-threads/") 7: TRUENAMIZE returned #P"/ebs/source/metadata/net/ common-lisp/bordeaux-threads/" 7: (PATHNAME #P"/ebs/source/library/net/common-lisp/ alexandria/") 7: PATHNAME returned #P"/ebs/source/library/net/ common-lisp/alexandria/" 7: (PATHNAME #P"/ebs/source/metadata/net/common-lisp/ bordeaux-threads/") 7: PATHNAME returned #P"/ebs/source/metadata/net/ common-lisp/bordeaux-threads/" 7: (PATHNAME-DEVICE #P"/ebs/source/library/net/ common-lisp/alexandria/") 7: PATHNAME-DEVICE returned NIL 6: COMPONENT-PATHNAME returned #P"/ebs/source/library/ net/common-lisp/alexandria/" 6: (PATHNAME #P"./package.lisp") 6: PATHNAME returned #P"./package.lisp" 6: (PATHNAME #P"/ebs/source/library/net/common-lisp/ alexandria/") 6: PATHNAME returned #P"/ebs/source/library/net/common- lisp/alexandria/" 6: (PATHNAME-DEVICE #P"/ebs/source/library/net/common- lisp/alexandria/") 6: PATHNAME-DEVICE returned NIL 5: COMPONENT-PATHNAME returned #P"/ebs/source/library/ net/common-lisp/alexandria/package.lisp" 5: (ASDF::LISPIZE-PATHNAME #P"/ebs/source/library/net/ common-lisp/alexandria/package.lisp") 5: LISPIZE-PATHNAME returned #P"/ebs/source/library/net/ common-lisp/alexandria/package.lisp" 5: (COMPILE-FILE-PATHNAME #P"/ebs/source/library/net/ common-lisp/alexandria/package.lisp") 5: COMPILE-FILE-PATHNAME returned #P"/ebs/source/library/ net/common-lisp/alexandria/package.abcl" 5: (ASDF:APPLY-OUTPUT-TRANSLATIONS #P"/ebs/source/ library/net/common-lisp/alexandria/package.abcl") 6: (ASDF-UTILITIES:TRUENAMIZE #P"/ebs/source/library/ net/common-lisp/alexandria/package.abcl") 7: (PATHNAME-DEVICE #P"/ebs/source/library/net/ common-lisp/alexandria/package.abcl") 7: PATHNAME-DEVICE returned NIL 7: (PATHNAME #P"ebs/") 7: PATHNAME returned #P"ebs/" 7: (PATHNAME #P"/") 7: PATHNAME returned #P"/" 7: (PATHNAME-DEVICE #P"/") 7: PATHNAME-DEVICE returned NIL 7: (PATHNAME #P"source/") 7: PATHNAME returned #P"source/" 7: (PATHNAME #P"/ebs/") 7: PATHNAME returned #P"/ebs/" 7: (PATHNAME-DEVICE #P"/ebs/") 7: PATHNAME-DEVICE returned NIL 7: (PATHNAME #P"library/") 7: PATHNAME returned #P"library/" 7: (PATHNAME #P"/ebs/source/") 7: PATHNAME returned #P"/ebs/source/" 7: (PATHNAME-DEVICE #P"/ebs/source/") 7: PATHNAME-DEVICE returned NIL 7: (PATHNAME #P"net/") 7: PATHNAME returned #P"net/" 7: (PATHNAME #P"/ebs/source/library/") 7: PATHNAME returned #P"/ebs/source/library/" 7: (PATHNAME-DEVICE #P"/ebs/source/library/") 7: PATHNAME-DEVICE returned NIL 7: (PATHNAME #P"common-lisp/") 7: PATHNAME returned #P"common-lisp/" 7: (PATHNAME #P"/ebs/source/library/net/") 7: PATHNAME returned #P"/ebs/source/library/net/" 7: (PATHNAME-DEVICE #P"/ebs/source/library/net/") 7: PATHNAME-DEVICE returned NIL 7: (PATHNAME #P"alexandria/") 7: PATHNAME returned #P"alexandria/" 7: (PATHNAME #P"/ebs/source/library/net/common-lisp/") 7: PATHNAME returned #P"/ebs/source/library/net/ common-lisp/" 7: (PATHNAME-DEVICE #P"/ebs/source/library/net/ common-lisp/") 7: PATHNAME-DEVICE returned NIL 7: (PATHNAME #P"/ebs/source/library/net/common-lisp/ alexandria/package.abcl") 7: PATHNAME returned #P"/ebs/source/library/net/ common-lisp/alexandria/package.abcl" 7: (PATHNAME #P"/ebs/source/library/net/common-lisp/ alexandria/") 7: PATHNAME returned #P"/ebs/source/library/net/ common-lisp/alexandria/" 7: (PATHNAME-DEVICE #P"/ebs/source/library/net/ common-lisp/alexandria/package.abcl") 7: PATHNAME-DEVICE returned NIL 6: TRUENAMIZE returned #P"/ebs/source/library/net/ common-lisp/alexandria/package.abcl" 6: (PATHNAME-MATCH-P #P"/ebs/source/library/net/common- lisp/alexandria/package.abcl" #P"/home/asdf/.cache/common-lisp/ armedbear-0.19.1-linux-unknown/**/*.*") 7: (PATHNAME #P"/ebs/source/library/net/common-lisp/ alexandria/package.abcl") 7: PATHNAME returned #P"/ebs/source/library/net/ common-lisp/alexandria/package.abcl" 7: (PATHNAME #P"/home/asdf/.cache/common-lisp/ armedbear-0.19.1-linux-unknown/**/*.*") 7: PATHNAME returned #P"/home/asdf/.cache/common- lisp/armedbear-0.19.1-linux-unknown/**/*.*" 6: PATHNAME-MATCH-P returned NIL 6: (PATHNAME-MATCH-P #P"/ebs/source/library/net/common- lisp/alexandria/package.abcl" #P"/:jar:file/**/*.*") 7: (PATHNAME #P"/ebs/source/library/net/common-lisp/ alexandria/package.abcl") 7: PATHNAME returned #P"/ebs/source/library/net/ common-lisp/alexandria/package.abcl" 7: (PATHNAME #P"/:jar:file/**/*.*") 7: PATHNAME returned #P"/:jar:file/**/*.*" 6: PATHNAME-MATCH-P returned NIL 6: (PATHNAME-MATCH-P #P"/ebs/source/library/net/common- lisp/alexandria/package.abcl" #P"jar:file:/**/*.jar!/**/*.*") 7: (PATHNAME #P"/ebs/source/library/net/common-lisp/ alexandria/package.abcl") 7: PATHNAME returned #P"/ebs/source/library/net/ common-lisp/alexandria/package.abcl" 7: (PATHNAME #P"jar:file:/**/*.jar!/**/*.*") 7: PATHNAME returned #P"jar:file:/**/*.jar!/**/*.*" 6: PATHNAME-MATCH-P returned T 6: (PATHNAME-DEVICE #P"/ebs/source/library/net/common- lisp/alexandria/package.abcl") 6: PATHNAME-DEVICE returned NIL 6: (NAMESTRING NIL) Debugger invoked on condition of type TYPE-ERROR: The value NIL is not of type (OR PATHNAME STRING FILE-STREAM). Restarts: 0: RETRY Retry loading component :ALEXANDRIA. 1: RETRY Retry loading component "bordeaux-threads". 2: TOP-LEVEL Return to top level. [3] CL-USER(64): asdf::*output-translations* (((#P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux-unknown/**/ *.*" #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux-unknown/ **/*.*") (#P"/:jar:file/**/*.*" #P"/home/asdf/.cache/common-lisp/ armedbear-0.19.1-linux-unknown/**/*.*") (#P"jar:file:/**/*.jar!/**/ *.*" #<FUNCTION ASDF::TRANSLATE-JAR-PATHNAME {170B6D}>) (#P"/**/*.*" #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux-unknown/**/ *.*")))

2 2