Re: Relativising FASL Cache Paths

[Faré]

On Sun, Dec 17, 2017, 06:08 Nicolas Hafner  wrote:

> On 17/12/17 12:02, 73budden . wrote:
>
> Nicolas, can you resolve source locations at SWANK level? E.g.
> functions like SWANK/SBCL::SOURCE-FILE-SOURCE-LOCATION might be
> appropriate for patching: you take the location that SBCL gives you,
> but then redirect SWANK to other place. I guess this is not the only
> place you have to patch, it would require patching private functions
> and it might not work at all. But if that works for you please let me
> know. I'm also maintaining a thing a bit similar to portacle and it
> looks like I would suffer from the same issue.
>
> That sounds like a really nasty workaround. I'd much rather try to get
> ASDF to use logical pathnames.
>
Logical pathnames are never the solution, especially not if portability
means anything, and if SBCL is targeted in particular.

Too many systems have file names that just can't be valid logical pathnames
(that are limited strictly to single-case letters, digits, and dashes, plus
a dot only to separate the similarly-limited type). Underscores, mixed
case, wrong case, plus sign, dot, and whatever else are not allowed, yet
may be implied by the .asd file.

Good luck convincing all authors in Quicklisp of renaming their files and
directories (though this renaming could conceivably be done automatically
after the fact, combined with large logical pathname mapping tables, for
atrocious performance and horrible bugs when that fails; good luck with
that kluge).

I recommend aiming for a true solution, which implies adding the capability
of overriding the pathname to SBCL's compile-file then UIOP's compile-file*
and ASDF's compile-op, and/or non-compliant lax pass-through logical
pathnames a la CCL.

-#f

Re: Relativising FASL Cache Paths

[Nicolas Hafner]

On 17/12/17 12:02, 73budden . wrote:
> Nicolas, can you resolve source locations at SWANK level? E.g.
> functions like SWANK/SBCL::SOURCE-FILE-SOURCE-LOCATION might be
> appropriate for patching: you take the location that SBCL gives you,
> but then redirect SWANK to other place. I guess this is not the only
> place you have to patch, it would require patching private functions
> and it might not work at all. But if that works for you please let me
> know. I'm also maintaining a thing a bit similar to portacle and it
> looks like I would suffer from the same issue. 
That sounds like a really nasty workaround. I'd much rather try to get
ASDF to use logical pathnames.
> Also let me remind you that you can set up the path to SBCL sources by
>
> sb-ext:set-sbcl-source-location
>
> AFAIR locating sources of SBCL functions didn't work in portacle when
> I saw it, and it was not very long ago.
Portacle already does that
.


signature.asc
Description: OpenPGP digital signature

Re: Relativising FASL Cache Paths

[73budden .]

Hi!

Nicolas, can you resolve source locations at SWANK level? E.g.
functions like SWANK/SBCL::SOURCE-FILE-SOURCE-LOCATION might be
appropriate for patching: you take the location that SBCL gives you,
but then redirect SWANK to other place. I guess this is not the only
place you have to patch, it would require patching private functions
and it might not work at all. But if that works for you please let me
know. I'm also maintaining a thing a bit similar to portacle and it
looks like I would suffer from the same issue. Also let me remind you
that you can set up the path to SBCL sources by

sb-ext:set-sbcl-source-location

AFAIR locating sources of SBCL functions didn't work in portacle when
I saw it, and it was not very long ago.