Sorry for a late reply.

UIOP has these utilities that can help you:
(uiop:find-symbol* :unimplemented-stub :foo nil)
(uiop:match-condition-p #(unimplemented-stub foo) (make-condition
(setf uiop:*uninteresting-conditions* '(#(unimplemented-stub foo)))

Also, ASDF has the around-compile hook that is the recommended place
to locally set those things:
(defun ignoring-unimplemented-sub (f) (let
((uiop:*uninteresting-conditions* '(#(unimplemented-stub foo))))
(funcall f)))
(defsystem ... :around-compile ignoring-unimplemented-sub ...)

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
Do NOT question authority — they don't know either.

On Sun, Jun 24, 2018 at 8:41 AM Robert Goldman <> wrote:
> On 22 Jun 2018, at 23:55, Stas Boukarev wrote:
> On Fri, Jun 22, 2018 at 5:13 PM Robert Goldman <> wrote:
>> I have a library that provides DEF-UNIMPLEMENTED as a macro for defining 
>> stub functions. When you compile a file with unimplemented functions, you 
>> get a warning of the type FOO:UNIMPLEMENTED-STUB in my library FOO.
>> I'd like to put in an asdf system definition a file spec something like this:
>> (:file "file-with-stubs"
>>   :method (:around (o c)
            (handler-bind ((foo:unimplemented-stub
>>                               #'(lambda (c)
>>                                   (print c)
>>                                   (muffle-warning c))
>>                 (call-next-method)))
>> but, of course, the package foo doesn't exist when this is read (although I 
>> could put (asdf:load-system "foo") upstream of the enclosing defsystem).
>> This isn't a case that's nicely consistent with Faré's hack for translating 
>> strings or keyword symbols, nor does it seem easy to use find-symbol for 
>> this purpose.
> You could still use FIND-SYMBOL:
> (handler-bind ((error (lambda (c) (when (typep c (find-symbol x :foo)))))) 
> (a))
> That's a good point, and effectively what I ended up doing. But it's 
> certainly not pleasing, because we end up doing our own type dispatch, on top 
> of that which is built into CL with handler-bind. Still, this might be the 
> best I can do.
> thanks,
> r

Reply via email to