Well, if you are comfortable cutting that macro line out of your copy of
ASDF, maybe you could tweak that line of code so that it prints the
values of those variables?
I'm wondering if this is a bug in SBCL instead of ASDF. I can replicate
your result: on SBCL, tracing `COMPILE-FILE` does not
Ah, right.
1. SBCL 1.4.8.53-eb16b4745 and ASDF 3.3.1
2. I'm not sure if these change when running asdf:load-system, but for
the moment they are all nil:
CL-USER> asdf::*uninteresting-conditions*
NIL
CL-USER> asdf::*uninteresting-compiler-conditions*
NIL
CL-USER> asdf::*warnings-file-type*
NIL
Two suggestions:
1. Let us know the implementation, implementation version, and ASDF
version
2. Look at the values of `*uninteresting-conditions*`,
`*uninteresting-compiler-conditions*`, and `*warnings-file-type*` in
your running lisp.
That will help us figure out why you are seeing this eff
I don't know enough about ASDF to know if I'm running with deferred
warnings -- I'm just trying to do (asdf:load-system ...) and removing
the with-muffled-compiler-conditions form (which itself is inside a
with-saved-deferred-warnings form) makes the trace output reappear. I
could well be overe
On 9 Jun 2018, at 12:38, Cyrus Harmon wrote:
Dear ASDF folks,
I was trying to trace calls to compile-file today and noticed that the
with-muffled-compiler-conditions form in uiop:compile-file* muffles
trace output. Is there anyway to make it not do that?
thanks,
Cyrus
I think you are ove
Dear ASDF folks,
I was trying to trace calls to compile-file today and noticed that the
with-muffled-compiler-conditions form in uiop:compile-file* muffles
trace output. Is there anyway to make it not do that?
thanks,
Cyrus
