[asdf-devel] One failure on ASDF 3.1.0.70 on Allegro/Windows

[Faré]

On Tue, Feb 25, 2014 at 1:19 PM, Robert P. Goldman <rpgoldman at sift.info> wrote:
> Faré wrote:
>> I recommend we just let the user choose between PATHNAME-EQUAL and
>> PATHNAME-EQUALP, or some such.
>
> The only question about this would be whether this is visible to the
> user or not?
>
I'd rather the user be in control.

> Looking into ASDF we find the following calls to PATHNAME-EQUAL:
>
> * BINARY-OP calls PATHNAME-EQUAL to see if it will inadvertently
> overwrite the system .asd file
> * Under ECL and MKCL, when building a bundle, we use pushnew with
> PATHNAME-EQUAL; if this is wrong, and PATHNAME-EQUALP is right, then we
> could get duplicates in the bundle
> * FIND-SYSTEM calls PATHNAME-EQUAL to see if the system definition
> source file has been changed.  A false positive here will cause
> unnecessary reloads.
> * SAME-PACKAGE-SYSTEM-P uses PATHNAME-EQUAL to check and see if two
> package-systems are the same.
>
> I don't see how these problems can be resolved by punting to the user:
> the user doesn't have access to this level of control.
>
For FIND-SYSTEM and SAME-PACKAGE-SYSTEM-P, remember that
these happen within the context of a same configuration.
foo.asd will be searched for system "foo", and "Foo.asd" for system "Foo".
To ASDF, these are different systems (NB: symbols are downcased),
so it's OK for PATHNAME-EQUAL to distinguish them.
Then, if the directories are case-sensitive unequal, but case-sensitive equal,
that means that you found one file in the first one in configuration order,
and the other file in the second one in configuration order,
which is proof enough that they are different files.
And if configuration changed and case with it, that's also a good
reason to reload.

Remains the bundle issues. The first one is avoiding to overwrite a .asd file;
the second is trying to avoid having the uiop library twice in the
archive. Both would require
quite some custom asdf methods to have the asd file (respectively uiop
library) as output-files
of some user system yet with a case-tweaked pathname. Yes, it's
possible to do it wrong,
but the user has to try hard for it, at which point I think it's OK to
concede defeat.

> While I agree that a heuristic for deciding whether pathnames are
> case-sensitive is not ideal, I don't see an alternative to supplying one.
>
I suspect that committing myself to a mental institution might be a
sane alternative to trying to supply a heuristic for case-sensitivity
of a filesystem without using CFFI.

> But perhaps there's a different way out?  At any rate, we'd have to
> figure out how to handle the above cases.
>
You're right of course that handling those cases right is important,
but I believe they are already handled as right as can be. Trying to
double-guess the user based on a flaky case-sensitive heuristic is
only the recipe for debugging madness either for you or for the poor
user who'll be double-guessed wrong.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If you could ask a unique question to a computer during a Turing test,
what would you ask?
        — Douglas Hofstadter, Metamagical Themas