[armedbear-devel] r12666 breaks ASDF compilation on Linux

[Alessio Stalla]

On Wed, Jun 2, 2010 at 7:14 PM, Mark Evenson <evenson at panix.com> wrote:
> On 6/2/10 6:56 PM, Alessio Stalla wrote:
>> On Wed, Jun 2, 2010 at 6:33 PM, Mark Evenson<evenson at panix.com>  wrote:
> […]
>>> I think the second part of the patch is good, as Pathname.init()
>>> shouldn't be setting the namestring at all.  The getNamestring()
>>> accessor should construct the value on its first invocation.
>>
>> But won't that construct it with \ on Windows?
>
> Yeah, but that should be the right behavior: translate to the native
> directory separator, right?

Yes, but not when the user passed / as a directory separator.

>>
>>> So I would be led to think that the first part of the patch is wrong.
>>> At best, it has no effect on the action on the algorithim.
>>
>> It has the effect of preventing getNamestring() to recalculate the
>> namestring until the pathname is modified.
>
> Hmmm: I don't see why that would be desirable.  I evidently don't
> understand enough context here then without running tests (which is
> tough to do with this wrist).  Naively, I expect we need some sort of
> heuristic in Pathname.init(String) that detects if the Pathname was
> serialized on the other platform, then takes corrective action.  Cases
> like 'c:/this/path' or '\\\\server\mount\point' serialized under Windows
> will have no exact meaning under non-Windows for which I don't know what
> would be reasonable behavior.  Just ignore those parts?

The problem is that a pathname is serialized as its namestring. If the
asdf code contains #P"/foo/bar" and it's compiled in Windows, that
becomes #P"\\foo\\bar" and is serialized as such. What I did is to
preserve the namestring passed by the user ("/foo/bar") unless of
course the user later modifies the pathname, in which case the
namestring is recomputed. Another possibility could be to store the
user-provided string in another field (not the namestring) and use
that field for serialization only. The field would be nulled when the
pathname is modified and, if null, the namestring would be used for
serialization.
Probably the correct solution is to serialize a pathname as its
distinct components and rebuild it from them, but it's significantly
harder to do.

Alessio