[ Please, Cc: me as I'm not on the mailing list ]
Hi,
I'm trying to upgrade my CL configuration to ASDF 2, and I have several questions:
1/ why isn't "source-registry.conf" named "asdf-source-registry.conf" ?
2/ Should we understand that the convention of having a "systems" directory with .asd files symlinked there is now obsolete ? I still prefer to keep that because I can select which of the installed sources I do want to be seen. I guess you could also use exclude patterns for doing so, but it seems way more complicated. Comments ?
3/ The following contents for source-registry.conf fails:
(:source-registry (:directory (merge-pathnames "share/common-lisp/systems/" (user-homedir-pathname))) (:directory "/usr/local/share/common-lisp/systems") (:directory "/usr/share/common-lisp/systems") :inherit-configuration)
Am I to understand that this file cannot really contain Lisp code (and so I couldn't use #'merge-pathnames)? Because in that case, this sucks. I have several machines on which $HOME is different (e.g. /home/ or /Users/, and no, I don't want to create a /home/ -> /Users/ symlink on my Macs)
4/ I'm also struggling with the output translations.
I'm happy with the default settings (using .cache/blabla) except for one case. For lisp files located under ~/Science/Source/Common Lisp/ (recursively), I want the compiled files to remain at the same place, under an implementation-specific subdirectory, like asdf-binary-locations did for me before.
For instance, ~/Science/Source/Common Lisp/foo/bar/baz.lisp would produce somthing like: ~/Science/Source/Common Lisp/foo/bar/sbcl-1.0.32.30-linux-x86-64/baz.fasl
I tried this:
(:output-translations ("/Users/didier/Science/Source/Common Lisp/" (:current-directory :implementation)) :inherit-configuration)
but this doesn't work. SBCL says:
This is SBCL 1.0.42.52, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/.
SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. ; loading system definition from ; /usr/local/lib/sbcl/sb-bsd-sockets/sb-bsd-sockets.asd into #<PACKAGE "ASDF0"> ASDF could not load sb-grovel because :CURRENT-DIRECTORY fell through ETYPECASE expression. Wanted one of ((EQL :DEFAULT-DIRECTORY) (EQL :SYSTEM-CACHE) (EQL :USER-CACHE) (EQL :HOME) (EQL :ROOT) CONS STRING PATHNAME).. ASDF could not load asdf-install because Error while trying to load definition for system sb-bsd-sockets from pathname /usr/local/lib/sbcl/sb-bsd-sockets/sb-bsd-sockets.asd: :CURRENT-DIRECTORY fell through ETYPECASE expression. Wanted one of ((EQL :DEFAULT-DIRECTORY) (EQL :SYSTEM-CACHE) (EQL :USER-CACHE) (EQL :HOME) (EQL :ROOT) CONS STRING PATHNAME)..
debugger invoked on a LOAD-SYSTEM-DEFINITION-ERROR: Error while trying to load definition for system sb-bsd-sockets from pathname /usr/local/lib/sbcl/sb-bsd-sockets/sb-bsd-sockets.asd: :CURRENT-DIRECTORY fell through ETYPECASE expression. Wanted one of ((EQL :DEFAULT-DIRECTORY) (EQL :SYSTEM-CACHE) (EQL :USER-CACHE) (EQL :HOME) (EQL :ROOT) CONS STRING PATHNAME).
So what's the magick ?
5/ Finally, I would like confirmation that ASDF now handles outdated fasl's correctly, and we don't need to do the black magick ourselves.
Thanks a lot !
I wrote:
[ Please, Cc: me as I'm not on the mailing list ]
here's another one:
In ASDF 1, (component-pathname (find-system ...)) returned the system's *directory*, which was coherent because the system is a module, so its pathname is a directory just like for any other sub-module.
In ASDF 2, it seems to return the .asd file instead. Is this intentional ?
here's another one:
In ASDF 1, (component-pathname (find-system ...)) returned the system's *directory*, which was coherent because the system is a module, so its pathname is a directory just like for any other sub-module.
In ASDF 2, it seems to return the .asd file instead. Is this intentional ?
This is bug lp#620421 which was fixed in 2.121 and released in 2.006.
That said, whatever you're doing that is hitting that bug is probably itself a mistake. There is no reason for you to ever use (component-pathname (find-system ...)) Instead, you should be using (system-relative-pathname ...) or some such thing.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Nobility measures the distance that separates current political rulers from the usurpers who founded their power. A revolution brings that distance back down to zero. A democracy keeps it permanently there.
Faré fahree@gmail.com wrote:
That said, whatever you're doing that is hitting that bug is probably itself a mistake. There is no reason for you to ever use (component-pathname (find-system ...)) Instead, you should be using (system-relative-pathname ...) or some such thing.
Yup. In fact, I never used "(component-pathname (find-system ...))" (that was a simplification for the email). I hit the bug in a generic function doing (component-pathname <component>) in which <component> would occasionally be a system.
On 23 September 2010 11:37, Didier Verna didier@lrde.epita.fr wrote:
[ Please, Cc: me as I'm not on the mailing list ]
I already replied to all your questions on c.l.l but I'll reply again here.
1/ why isn't "source-registry.conf" named "asdf-source-registry.conf" ?
Because it's not used solely by ASDF, but also by XCVB.
2/ Should we understand that the convention of having a "systems" directory with .asd files symlinked there is now obsolete ? I still prefer to keep that because I can select which of the installed sources I do want to be seen. I guess you could also use exclude patterns for doing so, but it seems way more complicated. Comments ?
It is still supported by ASDF2 and will remain supported for ASDF2. But yes, we recommend new users to move to the new way. You can still select sources with the new way, e.g. using :directory instead of :tree.
3/ The following contents for source-registry.conf fails:
(:source-registry (:directory (merge-pathnames "share/common-lisp/systems/" (user-homedir-pathname))) (:directory "/usr/local/share/common-lisp/systems") (:directory "/usr/share/common-lisp/systems") :inherit-configuration)
Am I to understand that this file cannot really contain Lisp code (and so I couldn't use #'merge-pathnames)? Because in that case, this sucks. I have several machines on which $HOME is different (e.g. /home/ or /Users/, and no, I don't want to create a /home/ -> /Users/ symlink on my Macs)
3a- Use #.
3b- A future version will use the path designator DSL from output-translations in the source-registry, at which point you can specify (:home "share/common-lisp/systems/")
4/ I'm also struggling with the output translations.
I'm happy with the default settings (using .cache/blabla) except for one case. For lisp files located under ~/Science/Source/Common Lisp/ (recursively), I want the compiled files to remain at the same place, under an implementation-specific subdirectory, like asdf-binary-locations did for me before.
For instance, ~/Science/Source/Common Lisp/foo/bar/baz.lisp would produce somthing like: ~/Science/Source/Common Lisp/foo/bar/sbcl-1.0.32.30-linux-x86-64/baz.fasl
I tried this:
(:output-translations ("/Users/didier/Science/Source/Common Lisp/" (:current-directory :implementation)) :inherit-configuration)
but this doesn't work. SBCL says:
This is SBCL 1.0.42.52, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/.
SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. ; loading system definition from ; /usr/local/lib/sbcl/sb-bsd-sockets/sb-bsd-sockets.asd into #<PACKAGE "ASDF0"> ASDF could not load sb-grovel because :CURRENT-DIRECTORY fell through ETYPECASE expression. Wanted one of ((EQL :DEFAULT-DIRECTORY) (EQL :SYSTEM-CACHE) (EQL :USER-CACHE) (EQL :HOME) (EQL :ROOT) CONS STRING PATHNAME).. ASDF could not load asdf-install because Error while trying to load definition for system sb-bsd-sockets from pathname /usr/local/lib/sbcl/sb-bsd-sockets/sb-bsd-sockets.asd: :CURRENT-DIRECTORY fell through ETYPECASE expression. Wanted one of ((EQL :DEFAULT-DIRECTORY) (EQL :SYSTEM-CACHE) (EQL :USER-CACHE) (EQL :HOME) (EQL :ROOT) CONS STRING PATHNAME)..
debugger invoked on a LOAD-SYSTEM-DEFINITION-ERROR: Error while trying to load definition for system sb-bsd-sockets from pathname /usr/local/lib/sbcl/sb-bsd-sockets/sb-bsd-sockets.asd: :CURRENT-DIRECTORY fell through ETYPECASE expression. Wanted one of ((EQL :DEFAULT-DIRECTORY) (EQL :SYSTEM-CACHE) (EQL :USER-CACHE) (EQL :HOME) (EQL :ROOT) CONS STRING PATHNAME).
So what's the magick ?
:current-directory was removed as non sensical on many Lisp implementations.
Try this entry: ((:home "Science/Source/Common Lisp/") (:home "Science/Source/Common Lisp/" #p"**" :implementation #p"*.*"))
5/ Finally, I would like confirmation that ASDF now handles outdated fasl's correctly, and we don't need to do the black magick ourselves.
I'm not sure what you mean, so I'd say probably not. If you have "black magick" that you think should be part of ASDF, please submit it here, and/or as an ASDF bug on launchpad.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Microphones, liberating singers from having to be loud to be heard, gave back to each language a music that matches its own prosody.
Faré fahree@gmail.com wrote:
5/ Finally, I would like confirmation that ASDF now handles outdated fasl's correctly, and we don't need to do the black magick ourselves.
I'm not sure what you mean, so I'd say probably not. If you have "black magick" that you think should be part of ASDF, please submit it here, and/or as an ASDF bug on launchpad.
Sorry for being too vague. For ASDF 1, I had a plug to automatically recompile outdated fasls (I probably found it on the internet years ago; don't remember):
(defmethod asdf:perform :around ((o asdf:load-op) (c asdf:cl-source-file)) (handler-case (call-next-method o c) (#+sbcl sb-ext:invalid-fasl #+cmu ext:invalid-fasl #+allegro excl::file-incompatible-fasl-error #+lispworks conditions:fasl-error #-(or sbcl cmu allegro lispworks) error () (asdf:perform (make-instance 'asdf:compile-op) c) (call-next-method))))
... and I was wondering if ASDF 2 did something like this on its own.
Thanks !
On 9/30/10 Sep 30 -1:05 PM, Didier Verna wrote:
Faré fahree@gmail.com wrote:
5/ Finally, I would like confirmation that ASDF now handles outdated fasl's correctly, and we don't need to do the black magick ourselves.
I'm not sure what you mean, so I'd say probably not. If you have "black magick" that you think should be part of ASDF, please submit it here, and/or as an ASDF bug on launchpad.
Sorry for being too vague. For ASDF 1, I had a plug to automatically recompile outdated fasls (I probably found it on the internet years ago; don't remember):
(defmethod asdf:perform :around ((o asdf:load-op) (c asdf:cl-source-file)) (handler-case (call-next-method o c) (#+sbcl sb-ext:invalid-fasl #+cmu ext:invalid-fasl #+allegro excl::file-incompatible-fasl-error #+lispworks conditions:fasl-error #-(or sbcl cmu allegro lispworks) error () (asdf:perform (make-instance 'asdf:compile-op) c) (call-next-method))))... and I was wondering if ASDF 2 did something like this on its own.
I'd love to see a version of this patch installed in ASDF2.
In its present form it seems a little yucky. Ideally, it seems to me, the OPERATION-DONE-P test for the COMPILE-OP should fail on an incompatible fasl. That's a lot cleaner than the solution that involves a direct outside call to PERFORM, which really breaches the API. This leads to a potential for error. For example, I'm pretty sure that the the ASDF:COMPILE-OP instance here is not built correctly --- it should be inheriting its initargs from the top-level operation instance, which is the way things are normally done in ASDF.
That said, I do not know how to probe a file to test whether it has a compatible FASL type, aside from trying to load it. Anyone know if this is possible?
Moving this discussion to launchpad bug.
https://bugs.launchpad.net/asdf/+bug/657825
This seems well worth doing, but it would be good to do it right, if possible.
best, r
-
Didier Verna -
Faré -
Robert Goldman