[cffi-devel] setf in with-foreign-slots cannot work with LispWorks 5.0 (64bit Linux)
Hi, CFFI Developers I'm using CFFI in my LispWorks 5.0.2 Enterprise Edition (64bit Linux). I found follow code can not compile: (in-package :cffi) (defcstruct c-type (c-long :long)) (defvar a (foreign-alloc 'c-type)) (with-foreign-slots ((c-long) a c-type) (setf c-long 0)) ;;; Compiling file /home/binghe/src/lisp/cffi-test.lisp ... ;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0 ;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3 ;;; Source level debugging is on ;;; Source file recording is on ;;; Cross referencing is on ; (TOP-LEVEL-FORM 1) ; (TOP-LEVEL-FORM 2) ; (TOP-LEVEL-FORM 3) ; (TOP-LEVEL-FORM 4) ; (DEFVAR CFFI::A) **++++ Error in (TOP-LEVEL-FORM 5): Type (SIGNED-BYTE 64) not supported by SYSTEM:TYPED-AREF. ; (TOP-LEVEL-FORM 6) ; *** 1 error detected, no fasl file produced. ;;; Compilation finished with 0 warnings, 1 error. Is it a bug? -- '()
On Tue, 2007-05-22 at 18:48 +0800, Chun Tian (binghe) wrote:
**++++ Error in (TOP-LEVEL-FORM 5): Type (SIGNED-BYTE 64) not supported by SYSTEM:TYPED-AREF. ; (TOP-LEVEL-FORM 6) ; *** 1 error detected, no fasl file produced. ;;; Compilation finished with 0 warnings, 1 error.
Is it a bug?
Yes, but it's debatable where the bug is. cffi-sys on LispWorks expects to be able to use fli:foreign-typed-aref for all primitive foreign types (integers, pointers, and floats), and a :long on that platform is 64 bits. That's a reasonable assumption as it seems to work on all other LW setups tested thus far. Some possible solutions: 1. The Right Thing would be to get LispWorks to support 64-bit integers in foreign-typed-aref, at least on your platform. Maybe this is already done; I don't know what the latest LW release is. 2. The quick and horrible hack is to change all lines like this line in src/cffi-lispworks.lisp #+#.(cl:if (cl:find-symbol "FOREIGN-TYPED-AREF" "FLI") '(and) '(or)) to this: #+(or) ;;foreign-typed-aref doesn't really work for me and remove lines that looks like this: #-#.(cl:if (cl:find-symbol "FOREIGN-TYPED-AREF" "FLI") '(and) '(or)) Obviously this will only apply on your install. 3. The slightly less horrible hack would be to change the interface of cffi-sys::convert-foreign-typed-aref-type (definition and both uses) to signal an error when the cffi-type argument cannot be so "converted", so the caller can fallback on a less efficient expanded form. -- ;;; Stephen Compall ** http://scompall.nocandysw.com/blog ** Failure to imagine vast possibilities usually stems from a lack of imagination, not a lack of possibility.
2007年5月23日 星期三、Stephen Compall さんは書きました:
On Tue, 2007-05-22 at 18:48 +0800, Chun Tian (binghe) wrote:
**++++ Error in (TOP-LEVEL-FORM 5): Type (SIGNED-BYTE 64) not supported by SYSTEM:TYPED-AREF. ; (TOP-LEVEL-FORM 6) ; *** 1 error detected, no fasl file produced. ;;; Compilation finished with 0 warnings, 1 error.
Is it a bug?
Yes, but it's debatable where the bug is. cffi-sys on LispWorks expects to be able to use fli:foreign-typed-aref for all primitive foreign types (integers, pointers, and floats), and a :long on that platform is 64 bits. That's a reasonable assumption as it seems to work on all other LW setups tested thus far.
Some possible solutions:
1. The Right Thing would be to get LispWorks to support 64-bit integers in foreign-typed-aref, at least on your platform. Maybe this is already done; I don't know what the latest LW release is.
I'm using the latest LW release (5.0.2). I've checked LW's Foreign Language Interface User Guide and Reference Manual, the foreign-typed-aref doesn't support 64bit types now: http://www.lispworks.com/documentation/lw50/FLI/html/fli-98.htm#pgfId-114965... Description The function foreign-typed-aref accesses a foreign array and is compiled to efficient code when compiled at safety 0. It corresponds to sys:typed-aref which accesses Lisp vectors. type must evaluate to double-float , single-float , (unsigned-byte 32) , (signed-byte 32) , (unsigned-byte 16) , (signed-byte 16) , (unsigned-byte 8) or (signed-byte 8) . I'll ask LW support if it's possible to support (signed-byte 64) and (unsigned-byte 64). Thanks. Chun Tian (binghe)
2. The quick and horrible hack is to change all lines like this line in src/cffi-lispworks.lisp
#+#.(cl:if (cl:find-symbol "FOREIGN-TYPED-AREF" "FLI") '(and) '(or))
to this:
#+(or) ;;foreign-typed-aref doesn't really work for me
and remove lines that looks like this:
#-#.(cl:if (cl:find-symbol "FOREIGN-TYPED-AREF" "FLI") '(and) '(or))
Obviously this will only apply on your install.
3. The slightly less horrible hack would be to change the interface of cffi-sys::convert-foreign-typed-aref-type (definition and both uses) to signal an error when the cffi-type argument cannot be so "converted", so the caller can fallback on a less efficient expanded form.
-- '()
On Wed, 2007-05-23 at 12:33 +0800, Chun Tian (binghe) wrote:
I'll ask LW support if it's possible to support (signed-byte 64) and (unsigned-byte 64).
Did you ever hear back about this? -- ;;; Stephen Compall ** http://scompall.nocandysw.com/blog ** Failure to imagine vast possibilities usually stems from a lack of imagination, not a lack of possibility.
2007年6月6日 星期三、Stephen Compall さんは書きました:
On Wed, 2007-05-23 at 12:33 +0800, Chun Tian (binghe) wrote:
I'll ask LW support if it's possible to support (signed-byte 64) and (unsigned-byte 64).
Did you ever hear back about this?
Yes, I asked LispWorks Support and got this answer:
On Wed, 23 May 2007 13:43:54 +0800, Chun Tian (binghe) said:
Hi,
Recently I found the CFFI package cannot use in LW 5.0 on 64bit Linux. Follow code cannot compile:
(in-package :cffi)
(defcstruct c-type (c-long :long))
(defvar a (foreign-alloc 'c-type))
(with-foreign-slots ((c-long) a c-type) (setf c-long 0))
A CFFI developers said, because LW's foreign-typed-aref doesn't support (signed-byte 64) and (unsigned-byte 64) now, I've checked LW's Foreign Language Interface User Guide and Reference Manual, and found that's true:
http://www.lispworks.com/documentation/lw50/FLI/html/fli-98.htm#pgfId-114 9659
So this is a CFFI bug, but I wonder if it's possible that LW will support this?
Yes, we will add support for this in a future release.
Regards,
Martin Simmons LispWorks Technical Support http://www.lispworks.com/support/
So, LispWorks will support this in "a future release", no useful patch for current release available... -- '()
participants (2)
-
Chun Tian (binghe) -
Stephen Compall