On Fri, Jul 12, 2002 at 12:35:17PM -0400, Raymond Toy wrote:
> >>>>> "Christophe" == Christophe Rhodes <csr21@...> writes:
> >> * (get-floating-point-modes)
> >> (:TRAPS (:OVERFLOW) :ROUNDING-MODE :NEAREST :CURRENT-EXCEPTIONS (:OVERFLOW)
> >> :ACCRUED-EXCEPTIONS (:INEXACT) :FAST-MODE NIL)
> >> Is something else happening?
> Christophe> Sorry -- CMUCL works fine (apart from that weird :ACCRUED-EXCEPTIONS) on
> What's wrong with accrued-exceptions? I always took that to mean that
> some inexact arithmetic has happened sometime before.
Well, OK, but firstly this might annoy some user of numerical code who
needs not to trap inexact arithmetic, but be able to test at the end of
the function whether the accrued-exceptions is set (in other words, I
think the default :accrued-exceptions in a freshly-started image should
> Christophe> Where I think CMUCL gets it wrong (or what I would consider wrong) is on
> Christophe> SPARC/Solaris, where I prefer SBCL's behaviour of not calling REINIT:
> Christophe> ;;; only interested in :OVERFLOW traps, the rest can go hang:
> Christophe> * (sb-vm::set-floating-point-modes :traps '(:overflow))
> Christophe> ;;; call my function
> Christophe> * (function-with-typo)
> Christophe> debugger invoked on condition of type UNDEFINED-FUNCTION:
> Christophe> The function FUNCTION-WITH-TYPO is undefined.
> Christophe> [...]
> Christophe> 0] abort
> Christophe> * (sb-vm::get-floating-point-modes)
> Christophe> (:TRAPS (:OVERFLOW)
> Christophe> ...)
> I'm confused. Are you saying this is wrong? I think it's right.
> FWIW, CMUCL/x86 produces this as well.
No, I think this is right -- and sorry for the misinformation (I must
have misread the CMUCL code, as it's not behaving the way my (wrong)
> Christophe> [ on sbcl/x86/linux, this last call gives (:TRAPS NIL ...) ]
> I think this is wrong.
Yes, absolutely. The odd thing is that there's no real difference in the
handling in sbcl between the platforms (apart from the kernel, I guess,
which might be the cause of the varying behaviour). Certainly, all the
problems seem to be on the SBCL end -- there seems to be some sort of
reinitialization of the world that we're not doing.
> Christophe> What does cmucl do in this situation? (and if it does the same as sbcl
> Christophe> here, how does it do it? Hmm, actually, on reflection I could be
> It says :traps are set to :overflow, just as you told it.
Cool -- again, sorry for my misread.
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)