cffi-devel June 2013

cffi-devel@common-lisp.net

9 participants
7 discussions

Problems with nested structs and the newer cffi
by Willem Rein Oudshoorn 18 Aug '13

18 Aug '13

I am encountering some problems with trying to upgrade my old cffi code to the new version from quicklisp. If I use the old code, I get lots of warnings about my structs, that I should use either (:struct ...) or (:pointer (:struct ...)) However whateer I try, I do not seem to get it to work, and I am starting to think there is some issue between me and the new cffi. The main issue is a nested struct definition like this: ``` (defcstruct timeval (time %time) (offset :int)) (defcstruct (git-signature) (name :string) (email :string) (time (:struct timeval))) ``` With type definitions ``` (define-foreign-type time-type () nil (:actual-type :int64) (:simple-parser %time)) (define-foreign-type git-signature-type () nil (:actual-type :pointer) (:simple-parser %git-signature)) ``` I encounter problems when I am trying to update the `translate-to-foreign` for the `git-signature-type`. The implementation boils down to: ``` (defmethod translate-to-foreign ((value list) (type git-signature-type)) (let ((signature (foreign-alloc '(:struct git-signature)))) (with-foreign-slots ((name email time) signature (:struct git-signature)) (setf name (getf value :name (getenv "USER"))) (setf email (getf value :email (default-email))) (with-foreign-slots ((time offset) time (:struct timeval)) (let ((time-to-set (getf value :time (local-time:now)))) (setf time time-to-set) (setf offset (/ (local-time:timestamp-subtimezone time-to-set local-time:*default-timezone*) 60))))) signature) ``` The problem is in the inner `with-foreign-slots ((time offset)...`. The error I get is: ; Evaluation aborted on #<TYPE-ERROR expected-type: SYSTEM-AREA-POINTER datum: (CL-GIT::OFFSET 0 TIME @1970-01-01T01:00:03.000000+01:00)>. The reason is, as far as I can tell, that in the code: (with-foreign-slots ((time offset) time (:struct timeval)) ... the value of `time` is already a plist (due to the outer with-foreign-slots), and the inner with-foreign-slots expects a pointer. So what is the best way of fixing this? I can fix this by replacing the inner `with-foreign-slots` by ``` (with-foreign-slots ((time offset) (foreign-slot-pointer signature '(:struct git-signature) 'time) (:struct timeval)) ``` which seems a bit long. An additional question is, when to use (:struct ...) and when to use (:pointer (:struct ..))) I did expect that I needed to use (:pointer (:struct ..)) in the toplevel `with-foreign-slots`, because the argument is actually a pointer to the struct. But that did not work. As you can tell, I am a bit confused. Hope that someone can give some hints to clear my head. Kind regards, Wim Oudshoorn.

4 10

wrong link on website
by Nicolas Martyanoff 02 Jul '13

02 Jul '13

Hi, For your information, the link to the mailing list info page of CFFI is not valid anymore on http://common-lisp.net/project/cffi/ (404). Regards, -- Nicolas Martyanoff http://wandrian.net khaelin(a)gmail.com

2 1

Example with sprintf & %f from cffi manual crashes clisp on cygwin
by Mirko Vukovic 01 Jul '13

01 Jul '13

Hello, The following example from section 10 of the cffi documentation is causing a segmentation fault on clisp on cygwin: (defcfun "sprintf" :int (str :pointer) (control :string) &rest) CFFI> (with-foreign-pointer-as-string (s 100) (sprintf s "%c %d %.2f %s" :char 90 :short 42 :float 3.1415 :string "super-locrian")) => "A 42 3.14 super-locrian" I replaced :float pi with :float 3.1415, as ``pi'' is long-float - I wanted to remove this as a possible cause. At first I thought it was the %s for the string, but it may actually be the %.2f. - By itself %f, it does not correctly process floats, emitting ``f''. - If followed by other codes, it swallows them - If followed by a string, causes a segmentation fault CL-USER> (cffi:with-foreign-pointer-as-string (s 100) (sprintf s "%s" :string "super-locrian")) "super-locrian" CL-USER> (cffi:with-foreign-pointer-as-string (s 200) (sprintf s "%.2f" :float 3.1415)) "f" CL-USER> (cffi:with-foreign-pointer-as-string (s 200) (sprintf s "%.2f %c" :float 3.1415 :char 65)) "f " CL-USER> (cffi:with-foreign-pointer-as-string (s 200) (sprintf s "%.2f %s %c" :float 3.1415 :string "five" :char 65)) Segmentation fault I'll try this on Linux/SBCL when I get back to work on Monday. Mirko

2 5

Using foreign values in CL expressions
by Mirko Vukovic 27 Jun '13

27 Jun '13

I am figurirng out my way through cffi, and I cannot figure out the following (this is in clisp): Suppose I have a C functions that returns a result via a pointer. Its definition is: foo a, b, &c and then I want to do 3 * c. What do I have to give for c? I do have its address. Should I use mem-ref, or convert-from-foreign, or something else? Here is a scetch (where I already did defcfun ("foo" foo) ...)): (let ((*c (foreign-alloc :float)) (foo a b *c) (* 3 (??? *c)) Thank you, Mirko

2 1

defcfun cannot find foreign function in library
by Mirko Vukovic 26 Jun '13

26 Jun '13

Hello, Disclaimer: I am a newbie at all things C, including CFFI. Thus what I am trying to do may not be possible. The following is on Windows 7. I use clisp on cygwin. I am trying to link to a VISA library (VISA is used to control data acquisition instruments), visa32.lib compiled for Windows. The library is shipped with Tektronix software. The manual gives examples of using the library using C++, and I am trying to follow the first example. To me it looked pretty much like C - no objects, templates at least. Problem: defcfun cannot find the function. Here is the example code: #include <visa.h> #include <stdio.h> #include <memory.h> // This example opens a specific GPIB device, does an *idn query // and prints the result. int main(int argc, char* argv[]) { ViSession rm = VI_NULL, vi = VI_NULL; ViStatus status; ViChar buffer[256]; ViUInt32 retCnt; // Open a default session status = viOpenDefaultRM(&rm); <--------------- I want to access this function if (status < VI_SUCCESS) goto error; // Open the GPIB device at primary address 1, GPIB board 8 status = viOpen(rm, “GPIB8::1::INSTR”, VI_NULL, VI_NULL, &vi); if (status < VI_SUCCESS) goto error; ... etc My cffi code is: (cffi:defctype ViSession :int) (cffi:defctype ViStatus :int) (cffi:defcfun ("viOpenDefaultRM" vi-open-default-rm :library tek-visa) ViStatus (rm ViSession)) And the library is defined thus: (cffi:define-foreign-library tek-visa (:windows *VISA-lib*)) ;; *VISA-lib* contains path to the library (cffi:use-foreign-library tek-visa) defcfun gives warning that the foreign function does not exist. Using `nm' I did find: 00000000 I __imp__viOpenDefaultRM@4 00000000 T _viOpenDefaultRM@4 I tried using these (and some variants), but got the same message. Now, this is a Windows library, and clisp is on Cygwin. Could that be the problem? Any other thoughts? Thank you, Mirko

4 6

Debugging a Callback
by James Ashley 21 Jun '13

21 Jun '13

This may not be the proper list (I'm tempted to cross-post to the clozure one), but I have to start somewhere. I'm putting together a wrapper around the recently released version of the C library GLFW. In the middle of a callback (written in CL and mostly using cl-glfw), I'm winding up in the debugger, and I'm not having any luck figuring out why. I don't have a minimal test-case to share, yet. That's my next step. I'm being lazy and asking before I start trying to trim pieces down. The best nutshell of the problem I have at the moment is that the callback in question looks like: (cffi:defcallback window-sizer :void ((window glfw3::glfw-window) (width :int) (height :int)) ;; Have to have the OpenGL context before we can do this. ;; Q: Should I be making that window's context current? ;; A: Seems really stupid to think otherwise. (declare (ignore window)) (format t "Resizing to ~A x ~A~%" width height) (gl:viewport 0 0 width height) (format t "Setting projecting matrix~%") (gl:matrix-mode :projection) (gl:load-identity) (let ((ratio (/ width height))) (format t "Setting ortho: ~A~%" ratio) ;; This next line is failing here, pretty spectacularly. ;; with an error message that doesn't seem to make any sense. ;; It appears to run fine (even if it does nothing) when ;; I run it throuh the REPL. (gl:ortho (- ratio) ratio -1 1 1 -1)) (format t "Returning~%")) The stack trace (FWIW) looks like: The value 17465867632912 is not of the expected type DOUBLE-FLOAT. [Condition of type TYPE-ERROR] 0: (CFFI-CALLBACKS::|GLFW3-EXAMPLE::WINDOW-SIZER| 17465867632956) Locals: #:G7819 = 17465867632956 #:G7822 = #<A Foreign Pointer [stack-allocated] #x7F14B6B009E0> GLFW3-EXAMPLE::WINDOW = #<A Foreign Pointer #x7F149C034C70> GLFW3-EXAMPLE::WIDTH = 649 GLFW3-EXAMPLE::HEIGHT = 502 COMMON-LISP:RATIO = 649/502 CL-OPENGL-BINDINGS::LEFT = -649/502 #:G7833 = -1.292828685258964D0 #:G7834 = 1.292828685258964D0 #:G7835 = -1.0D0 #:G7836 = 1.0D0 #:G7837 = 1.0D0 #:G7838 = -1.0D0 1: (CCL::%PASCAL-FUNCTIONS% 5 17465867632956) Locals: INDEX = 5 ARGS-PTR-FIXNUM = 17465867632956 LISP-FUNCTION = #<Compiled-function CFFI-CALLBACKS::|GLFW3-EXAMPLE::WINDOW-SIZER| (Non-Global) #x302001CF9B0F> WITHOUT-INTERRUPTS = NIL *CALLBACK-TRACE-P* = NIL 2: (NIL #<Unknown Arguments>) 3: (POLL-EVENTS) 4: (CCL::CALL-CHECK-REGS POLL-EVENTS) 5: (CCL::CHEAP-EVAL (POLL-EVENTS)) Does anyone have a suggestion about where I should look to try to figure out where that value it's complaining about comes from? Or what's expecting the DOUBLE-FLOAT? Is there something else in the stack trace (or anywhere else) that I'm just totally missing due to my noobishness? The C signature of the callback function is typedef void (* GLFWwindowsizefun)(GLFWwindow*,int,int); Is there something else I can supply that I didn't realize is important? Just for the record, I'm much more interested in learning how I can diagnose and fix these sorts of problems for myself than anything else. I just seemed to run into a total dead end on google. Thanks in advance, James

4 4

what does 'deprecated' mean with respect to "bare structure types"?
by james anderson 13 Jun '13

13 Jun '13

good afternoon; upon pulling and building with the current cffi version, one observes, that the elementary form of references to structure types has fallen into disfavor and leads to a style warning, to the effect, that such forms are "deprecated". that term might lead one to understand such a form to be ambiguous, inconsistent or incompatible some introduced mechanism, or to be expected to impair future changes for similar reason. when, however, one regards the related commentary in the usage documentation and examines the code locations which concern the deprecation, it appears, that the semantics of the elementary form is unambiguously known and supported in all contexts, that there is no indication of impending changes which would change this situation, and that, given these circumstances, the deprecation warning is gratuitous and can actually be ignored. is this a true comprehension of the situation? if i have overlooked or disregarded some key aspect of this change, please advise. best regards, from berlin,

2 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel June 2013