On Wed, Feb 3, 2010 at 8:51 AM, Mark Evenson evenson@panix.com wrote:
On 1/29/10 4:12 PM, Alan Ruttenberg wrote:
On Fri, Jan 29, 2010 at 4:03 AM, Mark Evensonevenson@panix.com wrote:
On 1/18/10 4:51 PM, Alan Ruttenberg wrote:
(TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*"
#P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
Acknowledge and logged as [ticket 82][1].
[…]
Somehow, the more I learn about Pathnames, the less I understand.
First off, I think that the SETF on LOGICAL-PATHNAME-TRANSLATION should never use the #P for its arguments as you had in your example:
First off, is the example I gave in this thread. (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
This succeeds in SBCL and throws an error (regressing) in ABCL. So that part is an issue no matter what.
(setf (logical-pathname-translations "ido") '((#P"IDO:IDO-CORE;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/ido-core/**/*.*")))
[…]
because it doesn't do what you might expect, namely the #p"IDO:IDO-CORE;**;*.*" is not interpreted as a logical pathname when read by the SHARP_P reader. You end up with an Pathname whose NAME is "IDO:IDO-CORE;**;*.*" and other components are nil. That this ever worked in ABCL is mysterious. Based on a canvas of open source Lisps available to me, SBCL, ECL, and CCL all signal errors on being input this form, for a variety of differing reasons. clisp accepts the form, but fails to record it as a logical pathname.
Second, refactoring your test case away from logical pathnames down to the use to TRANSLATE-PATHNAME, I derive the following use of TRANSLATE-PATHNAME to be equivalent to the behavior you want:
(translate-pathname "/immunology/" "/immunology/**/" "/usr/home/**")
which you want to output
#p"/usr/home/immunology/"
but none of the other Lisps I checked (SBCL, ECL, CCL, and clisp) work this way, they all return
#p"/usr/home/"
I think they do this to avoid the case for which Thomas Russ reported a bug where
(translate-pathname "/immunology/" "/immunology/**/" "/usr/home/immunology/**")
should return
#p"/usr/home/immunology/"
not
#p"/usr/home/immunology/immunology/"
as was the pre-r12283 ABCL behavior.
So there's some wierdness in sbcl: * (translate-pathname "/immunology/foo/" "/immunology/**/" "/usr/home/bar/**")
#P"/usr/home/bar/" * (translate-pathname "/immunology/foo/" "/immunology/**/" "/usr/home/bar/**/")
#P"/usr/home/bar/foo/"
(translate-pathname "/immunology/foo/" "/immunology/**" "/usr/home/bar/**")
debugger invoked on a SIMPLE-ERROR: Pathname components from SOURCE and FROM args to TRANSLATE-PATHNAME did not match: ("immunology" "foo") ("immunology")
I agree this is confusing. But my case was a simple regression and that's my immediate concern.
-Alan
So, I am a bit confused on how to proceed. The behavior of TRANSLATE-PATHNAME is implementation specific. From fuddling around with the old implementation and the new one, I seem to be able to get either behavior but not both and they seem logically incompatible but I haven't proved that definitely to myself. Since the other CL implementations exhibit the same behavior as current ABCL I need either a) evidence that another Lisp works the way that Alan expects (and does it then exhibit the same behavior that is a bug to Thomas Russ?) or b) a clear semantics that I can implement that satisfy both uses.
Input kindly solicited from one and all.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."