On 8/25/16 Aug 25 -8:02 PM, Faré wrote: > Yeah, you may have to call (current-lisp-pathname) in a macro and/or > in an eval-when. > > What I generally recommend, though, is to save the pathname of the > system (via system-relative-pathname) and/or the file that you process > so that you can keep things relative to it.
Right. My preference is to save the file that is processed, so that I don't require the part to understand the whole. best, r > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > > > On Thu, Aug 25, 2016 at 7:55 PM, Jason Miller <ja...@milr.com> wrote: >> Correct me if I'm wrong, but the following macro should work: >> >> (defmacro lisp-file-truename () >> (or *compile-file-truename* *load-truename*)) >> >> Since minimal compilation requires that macros be expanded at >> compile-time, compiling a file with an invocation of the above macro >> should expand it. >> >> -Jason >> >> On 15:02 Thu 25 Aug , Robert Goldman wrote: >>> On 8/25/16 Aug 25 -1:08 PM, Robert Goldman wrote: >>>> On 8/24/16 Aug 24 -4:50 PM, Faré wrote: >>>>> On Wed, Aug 24, 2016 at 3:09 PM, Robert Goldman <rpgold...@sift.net> >>>>> wrote: >>>>>> I just realized that ASDF somewhat breaks *LOAD-TRUENAME*. >>>>>> >>>>>> I had some code in a DSL that has an :INCLUDE construct, and that DSL is >>>>>> being interpreted at load-time. >>>>>> >>>>>> The :INCLUDE directive tries to find other lisp files relative to the >>>>>> current file (the source file that contained the DSL :INCLUDE >>>>>> expression). >>>>>> >>>>>> Now, if we were not using ASDF, I would be able to find those files by >>>>>> merging a name with *load-truename* (and this is how things used to >>>>>> work). >>>>>> >>>>>> But ASDF's relocation of the fasls breaks this. >>>> >>>> [...snip...] >>>> >>>>> Can UIOP:CURRENT-LISP-FILE-PATHNAME help you? >>>> >>>> No, I'm afraid not. It returns the same thing that *LOAD-TRUENAME* >>>> does: the pathname for the fasl file, located in the cache, instead of >>>> the source file. >>>> >>>> CURRENT-LISP-FILE-PATHNAME evaluates to >>>> >>>> (or *compile-file-pathname* *load-pathname*) >>>> >>>> which means that I still get the pathname of the relocated fasl file, >>>> instead of the pathname of the lisp source file. >>>> >>>> I don't obviously see a way to invert the file translation function, >>>> either. >>>> >>>> I'm surprised I never noticed this in all these years. >>>> >>>> It's not obvious how to fix this, since the idea of having a dynamic >>>> variable bound (which was my first thought) isn't clearly feasible, >>>> since the COMPILE-FILE and LOAD aren't in a shared function call scope, >>>> because of the plan structure. >>>> >>>> I suppose one could add something to the PERFORM method for LOAD-OP, but >>>> when you're performing a LOAD-OP, you aren't even guaranteed that a >>>> corresponding COMPILE-OP exists (i.e., the process of COMPILE-THEN-LOAD >>>> could have been overridden). >>> >>> Ok, I *believe* that we could change this: >>> >>> (defun perform-lisp-load-fasl (o c) >>> (if-let (fasl (first (input-files o c))) >>> (load* fasl))) >>> >>> into something like >>> >>> (defun perform-lisp-load-fasl (o c) >>> (if-let (fasl (first (input-files o c))) >>> (let ((*lisp-source-truename* (component-pathnme c)) >>> (load* fasl))) >>> >>> and then export *lisp-source-truename*. >>> >>> Not ideal, but I'm having trouble thinking of a good alternative. >>> >>> The only other thing I can think of would be to supply a function that >>> would do: >>> >>> (uiop:inverted-file-redirection *load-truename*) >>> >>> >>> >>
