cffi-devel

cffi-devel@common-lisp.net

1113 discussions

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 28 Jun '13

28 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

[PATCH] Fold (foreign-type-size <built-in-type>) to constants
by Max Mikhanosha 24 May '13

24 May '13

Hi, PZMQ uses (foreign-type-size) dynamically on built-in types in its getsockopt functions, which is called on every recv-string message call. Please apply the following short patch, it seems self-obviously correct. Regards, Max From c3f6ede805431eac6d96379691ab54a0a951d4f3 Mon Sep 17 00:00:00 2001 From: Max Mikhanosha <max(a)openchat.com> Date: Thu, 23 May 2013 21:50:58 -0400 Subject: [PATCH] Fold (foreign-type-size <built-in-type>) to constants --- src/types.lisp | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/types.lisp b/src/types.lisp index 582a94d..ea5a020 100644 --- a/src/types.lisp +++ b/src/types.lisp @@ -1009,3 +1009,12 @@ (defctype :ullong :unsigned-long-long) (:uintptr . :pointer)) (:unsigned-char :unsigned-short :unsigned-int :unsigned-long :unsigned-long-long)))) + +;; Fold foreign-type-size on built-in types to constants +(define-compiler-macro foreign-type-size (&whole form type) + (if (constantp type) + (let ((type (eval type))) + (if (member type *built-in-foreign-types*) + (%foreign-type-size type) + form)) + form)) -- 1.7.11.rc0.100.g5498c5f

1 0

Groveler and HUGE_VAL
by Zach 26 Apr '13

26 Apr '13

I am trying to grovel the value of HUGE_VAL from math.h. This: (constant (huge-val "HUGE_VAL") :type double-float) doesn't work, presumably because HUGE_VAL isn't a proper float on my system (but rather some special positive infinity double float). I get this error: The value NLOPT::INF is not of type REAL. I need to use HUGE_VAL in the arguments in my NLOpt bindings (hence the package name in NLOPT::INF, though I don't think I even typed INF into the system). I believe that I can't use, say, most-positive-double-float, as there is special behavior when the value HUGE_VAL is used, i.e. it isn't just a large number. Interestingly, I can grovel HUGE_VAL as an integer with value 18446744073709551615 which, presumably, if I used the ieee-floats system: (ieee-floats:decode-float64 18446744073709551615) == HUGE_VAL However, I'm not sure of that and that form naturally produces an overflow error. This is a value that cannot actually be represented as a float, after all. Anyway, I'm not sure that this helps me as I have to pass it to a function that expects a double (actually I pass it as an element in an array of doubles that gets passed to the function): nlopt_result nlopt_set_lower_bounds(nlopt_opt opt, const double* lb); So, I think I need to hold the sizeof(double) bytes in memory (whatever the value of HUGE_VAL is) so that I can write it out to an array later. This is doable, but I am having trouble figuring out the syntax to have the groveler automate the task of getting those sizeof(double) bytes in the first place. Is there a way to deal with this? Even better, is there a way that CFFI makes this much simpler so I can just pass define whatever holds HUGE_VAL as an opaque object that can be used as a double? Even better yet, the value of HUGE_VAL provided by CFFI already and I am just not seeing it? Thanks for reading, any help is appreciated, Zach

3 5

Mailing list Issues
by Barry Fishman 26 Apr '13

26 Apr '13

The references to the cffi-devel mailing list on the web page are broken. I had disabled receiving mail from the list. However, I have suddenly started receiving mail from the list. How do I stop it? -- Barry Fishman

2 1

Error on web page
by Liam Healy 14 Apr '13

14 Apr '13

Under "Getting Started", the home page now says. The latest version is , released on (release notes). Liam

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel