[asdf-devel] SBCL 1.0.49 / ASDF 2.015.3 doesn't load my asdf systems anymore
fahree at gmail.com
Sat Jun 11 15:38:28 UTC 2011
>> ASDF doesn't introduce logical pathnames, and when you provide them,
>> it makes sure to pass them through to the implementation.
> Behaviour of logical pathnames with DIRECTORY is somewhat underspecified.
> (setf (logical-pathname-translations "foo")
> `(("**;*.fasl.*" "/home/foo/faslcache/**/*.fasl")
> ("**;*.*.*" "/home/foo/**/*.*")))
> and existence both
> (directory "foo:bar;x.fasl")
> return both, or just the one in faslcache?
> SBCL opts for both (modulo the aforementioned bug), other
> implementations may do things differently.
I think if it's trying that hard, it should show only the first:
only the fasl one is available through the LPN. And then,
with :resolve-symlinks nil (or some other implementation-specific hack),
it should give the logical pathname of that file instead of its truename.
But yes, I realize that the most recent way I cache the results
of the search for all .asd files now (per DIRECTORY returning
TRUENAMEs in the standard) breaks the previous ASDF promise of
not transforming logical-pathname's into physical pathnames.
ASDF BUG - or at least degradation in behavior to LPN users.
> Calling TRANSLATE-LOGICAL-PATHNAME first makes the answer unambiguous
> -- just the faslcache one, thanks -- which is why I believe ASDF
> should do that prior to calling DIRECTORY.
It's also the wrong thing wrt what ASDF would like to do to support
logical pathname users in the same way as before.
I see an ASDF 2.016.2 patch release coming.
PS: I'm impressed with how quick you came with a fix. Thank you!
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
For pretty much every writer, the big problem isn't piracy, it's obscurity.
— Tim O'Reilly, as cited by Cory Doctorow
More information about the asdf-devel