[asdf-devel] defsystem behaviour
Apologies for the complete lack of references headers in this mail, but I'm not subscribed to asdf-devel and only see this message in the common-lisp.net archive. On 9/13/10 Sep 13 -8:05 AM, Serhiy Yakovyn wrote: Is this done intentionally? Robert Goldman rpgoldman at sift.info wrote: Yes, this is done intentionally. Canonical (i.e., what you get when you translate a symbol) names for ASDF systems (and other ASDF components) are downcased. I /suspect/ (I am not privy to the intentions of the original developer) that this is because the downcased names --- this policy is applied not just to systems, but to other components as well --- map better to the way people use modern file-systems. This is, or was once, or should be, a matter of record. I don't know where asdf is currently hosted nor how far back the revision history there goes, but if you look at a sufficiently ancient version of asdf/README you should find something like 122 *** Component Attributes 123 124 A name (required) 125 126 This is a string or a symbol. If a symbol, its name is taken and 127 lowercased. The name must be a suitable value for the :name initarg 128 to make-pathname in whatever filesystem the system is to be found. 129 130 The lower-casing-symbols behaviour is unconventional, but was selected 131 after some consideration. Observations suggest that the type of 132 systems we want to support either have lowercase as customary case 133 (unix, mac, windows) or silently convert lowercase to uppercase 134 (lpns), so this makes more sense than attempting to use :case :common, 135 which is reported not to work on some implementations -dan ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 2 questions
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 ? -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 2 questions
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 | ReflectionCybernethics | 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. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 2 questions
On 23 September 2010 11:37, Didier Verna did...@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
Re: [asdf-devel] ASDF 2 questions
Faré fah...@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 ! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] Old revisions of ASDF in the wild.
Which legacy versions of ASDF should we support? Xach and/or one of his users had trouble with ASDF from SBCL 1.0.38. # git show sbcl_1_0_38:contrib/asdf/asdf.lisp /tmp/asdf-from-sbcl-1.0.38.lisp # sha1sum /tmp/asdf-from-sbcl-1.0.38.lisp fd7eab8cd8e5eaeb34264896d62a8bb3847b4d00 We can identify which revision this came from with: # git log sbcl_1_0_38 -- contrib/asdf/asdf.lisp It was 1.0.29.50 by nikodemus which claims to have imported it from git. Of course, whichever revision is latest in asdf.git at that point was not in master when nikodemus pulled, and # for i in $(git rev-list HEAD -- asdf.lisp) ; do echo $i $(git show $i:asdf.lisp | sha1sum) ; done | grep fd7eab8cd8e5eaeb34264896d62a8bb3847b4d00 replies nothing. How come we can't see the same version anywhere in the asdf git repo? Let's find the version with least differences... # for i in $(git rev-list HEAD -- asdf.lisp) ; do echo $i $(git show $i:asdf.lisp | diff -uab - /tmp/asdf-from-sbcl-1.0.38.lisp | grep '^[+-]' | wc -l) ; done | sort -k2 | head -n 1 3ef18cd49ef82c6a2dd92034972019721458d22c 0 What, no difference? Yeah, it's SBCL whitespace canonicalization at work. So the good version was a commit by gwking on 2009-06-09. I'm too lazy to do anything systematic about it right now, but I wanted to record that for posterity. Maybe at some point I'll scum around the SBCL sources and try to extract a few versions of ASDF that we may want to support. Are there any other implementations than SBCL, ECL and ABCL that used to distribute copies of ASDF? We may want to do something similar, and integrate that in our test suite. Now to make sure that upgrades work from ALL these versions, before we release 2.009... soupirs (le sigh). [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] Good girls are bad girls that never get caught. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Old revisions of ASDF in the wild.
On 9/30/10 Sep 30 -7:53 PM, Faré wrote: Which legacy versions of ASDF should we support? Xach and/or one of his users had trouble with ASDF from SBCL 1.0.38. # git show sbcl_1_0_38:contrib/asdf/asdf.lisp /tmp/asdf-from-sbcl-1.0.38.lisp # sha1sum /tmp/asdf-from-sbcl-1.0.38.lisp fd7eab8cd8e5eaeb34264896d62a8bb3847b4d00 We can identify which revision this came from with: # git log sbcl_1_0_38 -- contrib/asdf/asdf.lisp It was 1.0.29.50 by nikodemus which claims to have imported it from git. Of course, whichever revision is latest in asdf.git at that point was not in master when nikodemus pulled, and # for i in $(git rev-list HEAD -- asdf.lisp) ; do echo $i $(git show $i:asdf.lisp | sha1sum) ; done | grep fd7eab8cd8e5eaeb34264896d62a8bb3847b4d00 replies nothing. How come we can't see the same version anywhere in the asdf git repo? Let's find the version with least differences... # for i in $(git rev-list HEAD -- asdf.lisp) ; do echo $i $(git show $i:asdf.lisp | diff -uab - /tmp/asdf-from-sbcl-1.0.38.lisp | grep '^[+-]' | wc -l) ; done | sort -k2 | head -n 1 3ef18cd49ef82c6a2dd92034972019721458d22c 0 What, no difference? Yeah, it's SBCL whitespace canonicalization at work. So the good version was a commit by gwking on 2009-06-09. I'm too lazy to do anything systematic about it right now, but I wanted to record that for posterity. Maybe at some point I'll scum around the SBCL sources and try to extract a few versions of ASDF that we may want to support. Are there any other implementations than SBCL, ECL and ABCL that used to distribute copies of ASDF? We may want to do something similar, and integrate that in our test suite. Now to make sure that upgrades work from ALL these versions, before we release 2.009... soupirs (le sigh). What do we mean by support? I /think/ I understand: since all of our ASDF versions are intended to be compatible, what we mean by supported is that it should be possible to successfully upgrade all of these versions to the latest release. Is that correct? I claim also that we only need to worry about supporting (in this sense) ASDF versions that have been bundled with an implementation. If you have a version of ASDF that's not bundled with your implementation, then you can simply replace it --- it doesn't need to be hot-patched. Does this sound right? Best, r ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
