Regarding RMCL and logical pathnames, please test 2.016.2. I introduce some non-trivial pathname changes. On RMCL, ASDF sees strings as "/posix/namestrings/" in its configuration. if you want OS9-style pathnames, they are #p"that:a:way:". You can thus both trivially share your configuration with other implementations, and just as trivially use MCL-specific paths. For logical pathnames, I implemented my "harder way" plan from previous email:
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.
In other words, if I compute (directory #p"FOO:CL;BAR;"), and find a file #p"/home/baz/cl/bar/quux.asd", the file will be kept only if (make-pathname :name "quux" :type "asd" :defaults #p"FOO:CL;BAR;") has the previous as its truename. And similarly when walking directories. I believe this restriction is not a problem in practice, and will keep things somewhat sane. And no, it's probably still not a good idea to try mix logical pathnames and mixed-case physical pathnames, as the result is highly non-portable. Also removed *system-cache* and getuid, which were bad ideas that never worked (and if anyone is using either, he'll thank me for making him stop). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I believe in God, only I spell it Nature. — Frank Lloyd Wright
On 12 Jun 2011, at 07:12, Faré wrote:
Regarding RMCL and logical pathnames, please test 2.016.2. I introduce some non-trivial pathname changes.
On RMCL, ASDF sees strings as "/posix/namestrings/" in its configuration. if you want OS9-style pathnames, they are #p"that:a:way:". You can thus both trivially share your configuration with other implementations, and just as trivially use MCL-specific paths.
For logical pathnames, I implemented my "harder way" plan from previous email:
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.
In other words, if I compute (directory #p"FOO:CL;BAR;"), and find a file #p"/home/baz/cl/bar/quux.asd", the file will be kept only if (make-pathname :name "quux" :type "asd" :defaults #p"FOO:CL;BAR;") has the previous as its truename. And similarly when walking directories. I believe this restriction is not a problem in practice, and will keep things somewhat sane.
I'm not sure if I understand all the implications of this change, so I'm hesitating to applaud this. I don't think it should be ASDF's job to fix this particular problem. Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
In other words, if I compute (directory #p"FOO:CL;BAR;"), and find a file #p"/home/baz/cl/bar/quux.asd", the file will be kept only if (make-pathname :name "quux" :type "asd" :defaults #p"FOO:CL;BAR;") has the previous as its truename. And similarly when walking directories. I believe this restriction is not a problem in practice, and will keep things somewhat sane.
I'm not sure if I understand all the implications of this change, so I'm hesitating to applaud this. I don't think it should be ASDF's job to fix this particular problem.
There are legitimate reasons in general for the truename to not commute with the setting of name and type: symlinks and clever pathname mappings to wholly different files; mapping of type fasl to implementation-specific type, etc. But for the specific sake of searching for .asd files, these reasons do not apply, and it's safer to avoid such cases: indeed, since the name of a .asd file has to match the name of the defsystem inside it, it's probably best to avoid looking for system "foo" in a file named "bar.c". Therefore, I think it's not wholly inappropriate for ASDF to do this filtering. As for filtering directory names — a bit ugly, but required by the behavior of DIRECTORY. If you think you must fix the spec and all implementations — good luck. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You have the capacity to learn from mistakes. You'll learn a lot today.
On 12 Jun 2011, at 17:42, Faré wrote:
If you think you must fix the spec and all implementations — good luck.
I have had very good and very positive experiences in that regard, as part of my work on Closer to MOP. Thank you very much. Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
Hi, Faré I don't think the new feature for RMCL really working: ? (compile-asdf) ;Compiling "Macintosh HD:users:binghe:Lisp:packages:asdf:asdf.lisp"... #P"Macintosh HD:users:binghe:Lisp:packages:asdf:asdf.cfsl" NIL NIL ? (load *) ;Loading #P"Macintosh HD:users:binghe:Lisp:packages:asdf:asdf.cfsl"... #P"Macintosh HD:users:binghe:Lisp:packages:asdf:asdf.cfsl" ? (pushnew "/Users/binghe/Lisp/usocket/branches/0.5.x/" asdf:*central-registry* :test #'equal) ("/Users/binghe/Lisp/usocket/branches/0.5.x/") ? ) ; Warning: Ignoring extra ")" on #<LISTENER "Listener" #x5CDDE1E> . ; While executing: #<Anonymous Function #x5A52A9E> NIL ? (asdf:load-system :usocket)
Error: While searching for system "usocket": "/Users/binghe/Lisp/usocket/branches/0.5.x/" evaluated to "/Users/binghe/Lisp/usocket/branches/0.5.x/" which is not a directory. While executing: ASDF::SYSDEF-CENTRAL-REGISTRY-SEARCH Type Command-. to abort. See the Restarts… menu item for further choices. 1 > Aborted ? asdf::*asdf-version* "2.016.2"
As above test shows, I started a clean RMCL without ASDF and then manually compile&load ASDF 2.016.2, pushing only one system directory (as POSIX namestring) to asdf:*central-registry* and it fails to interpret ... How can I debug this? Regards, Chun Tian (binghe) 在 2011-6-12，13:12， Faré 写道：
Regarding RMCL and logical pathnames, please test 2.016.2. I introduce some non-trivial pathname changes.
On RMCL, ASDF sees strings as "/posix/namestrings/" in its configuration. if you want OS9-style pathnames, they are #p"that:a:way:". You can thus both trivially share your configuration with other implementations, and just as trivially use MCL-specific paths.
For logical pathnames, I implemented my "harder way" plan from previous email:
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.
In other words, if I compute (directory #p"FOO:CL;BAR;"), and find a file #p"/home/baz/cl/bar/quux.asd", the file will be kept only if (make-pathname :name "quux" :type "asd" :defaults #p"FOO:CL;BAR;") has the previous as its truename. And similarly when walking directories. I believe this restriction is not a problem in practice, and will keep things somewhat sane.
And no, it's probably still not a good idea to try mix logical pathnames and mixed-case physical pathnames, as the result is highly non-portable.
Also removed *system-cache* and getuid, which were bad ideas that never worked (and if anyone is using either, he'll thank me for making him stop).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I believe in God, only I spell it Nature. — Frank Lloyd Wright
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Dear binghe, On 12 June 2011 22:47, Chun Tian (binghe) <binghe.lisp@gmail.com> wrote:
I don't think the new feature for RMCL really working: [...] As above test shows, I started a clean RMCL without ASDF and then manually compile&load ASDF 2.016.2, pushing only one system directory (as POSIX namestring) to asdf:*central-registry* and it fails to interpret ...
I think the feature is working, but I forgot to make it clear that this interpretation of strings as posix namestrings only applies in the DSL used by the source-registry and output-translation layers. The DSL is NOT used by the *central-registry*. If you want to use POSIX-namestrings in the *central-registry*, you need to explicitly call asdf::probe-posix, as in (push (asdf::probe-posix "/Users/binghe/Lisp/usocket/branches/0.5.x/") asdf:*central-registry*) Regards, —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If the human mind were simple enough to understand, we'd be too simple to understand it. — Pat Bahn
On Sun, 12 Jun 2011, Faré wrote:
I think the feature is working, but I forgot to make it clear that this interpretation of strings as posix namestrings only applies in the DSL used by the source-registry and output-translation layers. The DSL is NOT used by the *central-registry*. If you want to use POSIX-namestrings in the *central-registry*, you need to explicitly call asdf::probe-posix, as in
(push (asdf::probe-posix "/Users/binghe/Lisp/usocket/branches/0.5.x/") asdf:*central-registry*)
Couldn't he also use (push #P"/Users/binghe/Lisp/usocket/branches/0.5.x/" asdf:*central-registry*) ? - Daniel
Definitely I can't, the #\/ in #p"..." won't be recognized as directory separator: ? (asdf::probe-posix "/Users/binghe/Lisp/usocket/branches/0.5.x/") #P"Macintosh HD:users:binghe:Lisp:usocket:branches:0.5.x:" ? #p"/Users/binghe/Lisp/usocket/branches/0.5.x/" #P"/Users/binghe/Lisp/usocket/branches/0∂.5.x/" ? (truename *)
Error: File #P"/Users/binghe/Lisp/usocket/branches/0∂.5.x/" does not exist. While executing: TRUENAME Type Command-. to abort. See the Restarts… menu item for further choices. 1 > Aborted
在 2011-6-13，12:37， Daniel Herring 写道：
On Sun, 12 Jun 2011, Faré wrote:
I think the feature is working, but I forgot to make it clear that this interpretation of strings as posix namestrings only applies in the DSL used by the source-registry and output-translation layers. The DSL is NOT used by the *central-registry*. If you want to use POSIX-namestrings in the *central-registry*, you need to explicitly call asdf::probe-posix, as in
(push (asdf::probe-posix "/Users/binghe/Lisp/usocket/branches/0.5.x/") asdf:*central-registry*)
Couldn't he also use (push #P"/Users/binghe/Lisp/usocket/branches/0.5.x/" asdf:*central-registry*) ?
- Daniel
participants (4)
-
Chun Tian (binghe) -
Daniel Herring -
Faré -
Pascal Costanza