Re: Foreign Function Warnin

[reti@cambridge.apple.com (Kalman Reti)]

At  5:22 PM 12/9/93 -0600, Don Mitchell wrote:
>Subject:   RE>>Foreign Function Warning
>With respect to the included messages, wouldn't
>
>(handler-bind ((warning (condition)
>                           (muffle-warning condition)))
>   (your-code xxx))
>
>be a better way to get rid of the nuisance warning?  Actually, I would
>recommend using (setf *break-on-signals* 'warning) to cause it to break,
>check the type of warning generated (use the backtrace and look at the 
>warn stack frame), and replace warning in my code with the exact condition
>type so that it muffles the minimum set of warnings. (set 
>*break-on-signals* to nil after the one test to prevent further interruptions.)

Yes, it would be a MUCH better way.  When I answered the original code I was
to hasty at looking at what warn does and misread it as printing the error
before signalling the condition.  Teaches me to spend more time...
>
>--------------------------------------
>Date: 12/9/93 4:10 PM
>From: Kalman Reti
>Subject: Re: Foreign Function Warnings??
>
>>;warning: Duplicate defninition for "memcpy"
>>; while executing: ccl::ff-readobj
>
>Unfortunately, there is no special variable to suppress these warnings.  You can
>use the brute force approach, viz.:
>
>(let ((old-warn (fdefinition 'warn)))
>  (unwind-protect
>    (progn
>      (setf (fdefinition 'warn) #'(lambda (&rest ignore) ignore nil))
>      ;;;Your code which loads the foreign function files goes here.
>      ;;;you might also want to check in the dummy warn function that this is
>the      ;;;type of warning you expect, and funcall the old one if it isn't.
>      (warn "This is a test"))
>    (setf (fdefinition'warn) old-warn)))
>
>
>
>
>---------------------
>Donald H. Mitchell             Domain:  dhm@pro-solution.com
>Proactive Solutions Inc.         UUCP:  uunet!proact!dhm   
>5314 S. Yale Ave., Suite 402    Voice:  918.492.5192
>Tulsa, OK  74135                  FAX:  918.492.5193