[armedbear-devel] translate-logical-pathname and :wild-inferiorsregression

[Alan Ruttenberg]

On Wed, Feb 3, 2010 at 8:51 AM, Mark Evenson <evenson at panix.com> wrote:
> On 1/29/10 4:12 PM, Alan Ruttenberg wrote:
>>
>> On Fri, Jan 29, 2010 at 4:03 AM, Mark Evenson<evenson at 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."
>