[mcclim-devel] Patch: Update support for the Scieneer CL.

[Douglas Crosher]

Andreas Fuchs wrote:
> Douglas Crosher wrote:
>> * Update support for the Scieneer CL.
> 
> Thanks! I committed this patch and the "Fix system pathnames" and "add 
> the stopwatch example" patches.

Thank you.

> One comment from David Lichteblau on #lisp (see 
> http://www.ircbrowse.com/channel/lisp/20061028?utime=3371045114#utime_requested 
> for context): Setting floating point traps in def-cairo-fun is probably 
> not right; it might be better to do it in with-cairo-floats. I left it 
> as it the way your patch does it and added a small explanation for 
> people trying to understand the code.

Thank you for pointing this out.  The attached patch implements 'with-cairo-floats
for the SCL and also CMUCL.

> I'm not certain about the symbol name case patches (on the basis of 
> hugeness and maintainability), so I will leave them out for this 
> release. I hope leaving them out doesn't discourage you from sending 
> more of your high-quality patches. I would like to find a solution that 
> makes all users (including the ones of "modern mode" lisps) happy, but 
> right now I   prefer to get that release done before we fall back to 
> 1-year time slots. (-:

'Modern mode' is a Franz term and may be trademark.  Some customers
prefer the ANSI CL symbol names in lower case, and I'll just call it a
non-standard lower case mode, and the SCL supports this as an option.  Since
the changes are all neutral in ANSI upper case mode it would seem harmless to
integrate them, and they have been developed and continue to be supported by
Scieneer.  Further I believe Franz offer ACL for free evaluation and this
could be used to maintain McCLIM support for these changes.  The modified source
code is available from the SCL freeware collection, and ACL modern mode patches
are also welcome, see:
http://www.scieneer.com/s/product.html?code=56150

Regards
Douglas Crosher
-------------- next part --------------
Index: Backends/gtkairo/cairo-ffi.lisp
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/Backends/gtkairo/cairo-ffi.lisp,v
retrieving revision 1.6
diff -u -r1.6 cairo-ffi.lisp
--- Backends/gtkairo/cairo-ffi.lisp	28 Oct 2006 17:49:24 -0000	1.6
+++ Backends/gtkairo/cairo-ffi.lisp	28 Oct 2006 23:47:24 -0000
@@ -41,14 +41,8 @@
 	 , at args)
        (defun ,wrapper ,argnames
 	 (multiple-value-prog1
-             ;; FIXME: This should probably go into with-cairo-floats.
-             ;; (see http://www.ircbrowse.com/channel/lisp/20061028?utime=3371045114#utime_requested)
-	     #-scl (,actual , at argnames)
-	     #+scl 
-	     (ext:with-float-traps-masked (:underflow :overflow :inexact
-						      :divide-by-zero :invalid)
-	       (,actual , at argnames))
-	     (let ((status (cairo_status ,(car argnames))))
+	     (,actual , at argnames)
+	   (let ((status (cairo_status ,(car argnames))))
 	     (unless (eq status :success)
 	       (error "~A returned with status ~A" ,name status))))))))
 
Index: Backends/gtkairo/gtk-ffi.lisp
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/Backends/gtkairo/gtk-ffi.lisp,v
retrieving revision 1.7
diff -u -r1.7 gtk-ffi.lisp
--- Backends/gtkairo/gtk-ffi.lisp	13 May 2006 19:37:29 -0000	1.7
+++ Backends/gtkairo/gtk-ffi.lisp	28 Oct 2006 23:47:25 -0000
@@ -85,12 +95,19 @@
 ;; reset all options afterwards, I get lisp errors like f-p-i-o for, say,
 ;; (ATAN -13 13/2) in McCLIM.  Isn't SBCL responsible for calling C code
 ;; with the with the modes C code expects?  Or does cairo change them?
+#-(or scl cmu)
 (defmacro with-cairo-floats ((&optional) &body body)
   `(unwind-protect
        (progn
 	 #+sbcl (sb-int:set-floating-point-modes :traps nil)
 	 , at body)
      #+sbcl (apply #'sb-int:set-floating-point-modes *normal-modes*)))
+;;;
+#+(or scl cmu)
+(defmacro with-cairo-floats ((&optional) &body body)
+  `(ext:with-float-traps-masked (:underflow :overflow :inexact
+					    :divide-by-zero :invalid)
+     , at body))
 
 ;; Note: There's no need for locking in single threaded mode for most
 ;; functions, except that the main loop functions try to release the