cffi-devel April 2014

cffi-devel@common-lisp.net

10 participants
20 discussions

[Cffi-devel] CFFI ABCL bug?
by Cyrus Harmon 15 Apr '14

15 Apr '14

When compiling new-ish CFFI with ABCL, I get a warning that *function-call-encoding* is not defined: (defun make-function-pointer (pointer convention) (apply #'jnew (if *jna-4.0.0-or-later-p* (private-jconstructor "com.sun.jna.Function" "com.sun.jna.Pointer" "int" "java.lang.String") (private-jconstructor "com.sun.jna.Function" "com.sun.jna.Pointer" "int")) pointer (jfield "com.sun.jna.Function" (convert-calling-convention convention)) (when *jna-4.0.0-or-later-p* (list *function-call-encoding*)))) Similarly, there’s a defparameter nearby: (defparameter *jna-string-encoding* "UTF-8" "Encoding for conversion between Java and native strings that occurs within JNA. Used with jna-4.0.0 or later.”) that doesn’t seem to be used anywhere. Should these two be referring to the same thing? thanks, Cyrus

1 0

[Cffi-devel] possible cffi bug
by Joeish W 14 Apr '14

14 Apr '14

I have these 2 wrappers for the C++ vector class and I wrap both in CFFI the same way, and call them the same way but I'm getting unhandled memory fault errors when using my wrapper for the carraytovectorm, The only difference being, using the carraytovectorp as an example of all my other carraytovector type c wrappers that are written the same way, is that when I initialize the Point class to pass to the carraytovectorp I can do it like this: Point* m, n, o; vector_Point* v = std_carrayTovectorp(m, 3); and it works but when I attempt to do the same thing with carrayvectorm like so: Mat* m, n, o; vector_Mat* v = std_carrayTovectorm(m, 3); I get a segmentation fault error in C This works in both though. Point m, n, o; vector_Point* v = std_carrayTovectorp(&m, 3); If you think this might be a bug too..I can forward any other info needed to debug..I just tried to keep this post light so it wouldn't seem daunting:) vector_Mat* std_carrayTovectorm(Mat* a, size_t len) { vector<Mat>* v = new vector<Mat>; for(size_t i = 0; i < len; i++) v->push_back(a[i]); return v; } vector_Point* std_carrayTovectorp(Point* a, size_t len) { vector<Point>* v = new vector<Point>; for(size_t i = 0; i < len; i++) v->push_back(a[i]); return v; }

2 1

[Cffi-devel] What is the proper way to do GC in CFFI
by Joeish W 13 Apr '14

13 Apr '14

I have Lisp functions that wrap C wrappers for C++ functions that contain a new operator. The C wrappers have to stay the same I can't change those but I was advised to update my method of GC. Here are the C wrappers: Mat* cv_create_Mat() { return new Mat(); } void cv_delete_Mat(void* ptr) { delete (~Mat*)ptr; } Here are the Lisp wrappers for them: (defcfun ("cv_create_Mat" mat) (:pointer mat) "MAT constructor") (defcfun ("cv_delete_Mat" del-mat) :void (ptr :pointer)) In a loop, as below, I would normally after calling a MAT function, delete it when I'm done with it manually with DEL-MAT, but I heard there was a better way by actually entering in the DEL-MAT function into Lisps natural GC methods so it would know when it comes across a function with a new it should call delete to get rid of it when it know i'm done with it.. The thing is I could use help to get started. Hopefully a concrete example of how to do this so I don't have to call DEL-MAT manually (dotimes (n 1000) (setf m (mat)) (del-mat m))

4 11

Re: [Cffi-devel] Pre-populate cffi:*foreign-library-directories* by OS
by Frank Goenninger 08 Apr '14

08 Apr '14

Am 07.04.14 12:31 schrieb "Martin Simmons" unter <martin(a)lispworks.com>: >The problem is that there is no general agreement about where to put >libraries >on Linux and most 64-bit Linux distros support running 32-bit programs >using >libraries in a different directory from the 64-bit ones. > >On 32-bit Debian, /usr/lib is likely to contain 32-bit libraries. >On 64-bit Debian, /usr/lib is likely to contain 64-bit libraries. >On 32-bit and 64-bit Fedora, /usr/lib is likely to contain 32-bit >libraries. > >Many libraries on later Ubuntu distros are in platform-specific >directories >such as /usr/lib/i386-linux-gnu and /usr/lib/x64_x86-linux-gnu > >Therefore, the path you need depends on whether you are running a 64-bit >Lisp, >a 64-bit OS and also on which distro you are running. In particular, >/usr/lib >might give you the wrong libraries. > >__Martin Very well said and very true. Therefore, what we do when building and delivering applications, is to set cffi's foreign directory specifying variables to nil (!) at application start. The OS does know how to load libs by itself - that's what %PATH%, $DYLD_LIBRARY_PATH etc are for! Only when we deliver our own libs we set this explicitly, like: (cffi:define-foreign-library LIBSERIAL (t (:default "libserial"))) (cffi:define-foreign-library LIBPIB (t (:default "libpib"))) (eval-when (:compile-toplevel :load-toplevel :execute) (defparameter +CCAGCOMM-DEFAULT-LIB-DIR+ "/opt/consequor/lib/")) (defparameter *ccagcomm-lib-dir* #.+CCAGCOMM-DEFAULT-LIB-DIR+) (defun ccagcomm-lib-dir () (or *ccagcomm-lib-dir* +CCAGCOMM-DEFAULT-LIB-DIR+)) (defun set-ccagcomm-lib-dir (&optional (path *ccagcomm-lib-dir*)) (pushnew path cffi:*foreign-library-directories* :test #'eql)) (let ((ccagcomm-opened nil)) (defun ccagcomm-open () (if (not ccagcomm-opened) (progn (set-ccagcomm-lib-dir) (cffi:load-foreign-library 'LIBSERIAL) (cffi:load-foreign-library 'LIBPIB) (setq ccagcomm-opened t)))) (defun ccagcomm-close () (if ccagcomm-opened (progn (cffi:close-foreign-library 'LIBPIB) (cffi:close-foreign-library 'LIBSERIAL) (setq ccagcomm-opened nil)))) (defun ensure-ccagcomm-opened () (ccagcomm-close) (ccagcomm-open) ccagcomm-opened)) That's all for any app. Simple. Works on every platform we need (Linux, Windows, Mac OS X). We also never install our own libs under /usr or in a Windows directory - too many problems arising from that. Cheers Frank

1 0

[Cffi-devel] Pre-populate cffi:*foreign-library-directories* by OS
by Liam Healy 07 Apr '14

07 Apr '14

>From time to time I have seen requests from users to include an absolute path (starting from "/") in systems that use load-foreign-library under a clause for their favorite OS. This makes me nervous, especially when it is a little-used OS, because I have the feeling the requester's configuration is not typical for that OS and I will later get a request to add a different path when the original requester has moved on. Ideally, there would never have to be any absolute paths; dlopen would always know where to find libraries, because the OS is always configured in a standard way. However, a quick survey of this topic shows that reality falls far short of this ideal, and remedies are not clear. It is well beyond our capabilities to fix the entire world on this matter. Between fixing the world and fixing every CFFI-using application one by one, there is the compromise of setting default search paths for each OS in CFFI itself, thereby opening all applications to proper functionality out of the box for most OSes. The variable cffi:*foreign-library-directories* seems like the right thing to set. I've looked through all Quicklisp libraries for absolute paths in uses of load-foreign-library, and found these: Solaris: /lib/64, /usr/lib/amd64, /usr/lib Darwin: /usr/lib, /opt/local/lib, /usr/local/lib Unix: /usr/local/lib, /usr/lib Therefore I propose to change the definition to: (defvar *foreign-library-directories* '(#+(or unix darwin solaris) "/usr/lib" #+(or unix darwin) "/usr/local/lib" #+darwin "/opt/local/lib" #+solaris "/lib/64" #+solaris "/usr/lib/amd64") "List onto which user-defined library paths can be pushed.") As requests come in to add an absolute path for an application, they can be referred to this mailing list to request the change here, if it is not an application-specific path. Then it is more likely to be properly vetted for general applicability for all users of that OS, and will be available for all libraries. Does this sound like a reasonable way to handle this problem? Liam

5 9

[Cffi-devel] "The value is not of type SB-SYS:SYSTEM-AREA-POINTER." when creating 2d array
by Joeish W 06 Apr '14

06 Apr '14

I'm getting this this Error: The value (FOREIGN-ALLOC :POINTER :INITIAL-ELEMENT (POINT (UNIFORM RNG X-1 X-2) (UNIFORM RNG Y-1 Y-2))) is not of type SB-SYS:SYSTEM-AREA-POINTER. [Condition of type TYPE-ERROR] My array is below, I simplified the array elements to (cffi:null-pointer) I've been trying everything I can to create a 2d array of pointers. But its all been coming down to this error: If anyone can help with this I'd be very appreciative.:) (defvar *2d-array* #2A(( (foreign-alloc :pointer :initial-element (null-pointer)) (foreign-alloc :pointer :initial-element (null-pointer))) ((foreign-alloc :pointer :initial-element (null-pointer)) (foreign-alloc :pointer :initial-element (null-pointer))))) (foreign-alloc :pointer :initial-contents (make-array (reduce #'* (array-dimensions *2d-array*)) :displaced-to *2d-array*))

1 0

[Cffi-devel] What's the best way to convert c+ classes into Lisp
by Joeish W 04 Apr '14

04 Apr '14

I have a bunch or C wrappers for C++ OpenCV code I'm writing and I was hoping someone could show me how the best way would be in CFFI to write theses functions. They're from a C++ class the OpenCV Point_ class defined here http://docs.opencv.org/modules/core/doc/basic_structures.html?highlight=ass… Here are the functions below. So far I'm making the top 2 functions point0 and point2 use the same name "point" with this function: (defun point (&optional (x nil) (y nil)) (cond ((eq (or x y) nil) (point0)) ((and x y) (point2 x y)) (t nil))) but I also have functions to retrieve the x and y coordinates of a point that belong to the same class. I call those point-x and point-y..I was hoping someone could write me up the best way on how to use these Point_ class wrappers . Is it with defclass or define-foreign-type or am I already doing a good job? I could use this info in making all my other class wrappers correctly. ;; Point* cv_create_Point(int x, int y) (defcfun ("cv_create_Point" point0) (:pointer point) "Point constructor") ;; Point* cv_create_Point(int x, int y) (defcfun ("cv_create_Point2" point2) (:pointer point) "Point constructor" (x :int) (y :int)) ;; _Tp x, y ;; int cv_Point_getX(Point* self) (defcfun ("cv_Point_getX" point-x) :int "Retrieves X coordinate of a point" (self (:pointer point))) ;; _Tp x, y ;; int cv_Point_getY(Point* self) (defcfun ("cv_Point_getY" point-y) :int "Retrieves y coordinate of a point" (self (:pointer point)))

1 0

[cffi-devel] HDF5 bindings
by Jeff Cunningham 03 Apr '14

03 Apr '14

I noticed that Daniel Herring posted a set of bindings to the C HDF5 library back in 2011. I'd like to write some higher level functions to make working with (at least simple) files of this type easier. Has anyone worked with these bindings? I'm not a CFFI expert and would benefit greatly from a sample or two. Kind regards, --Jeff Cunningham

2 1

[Cffi-devel] Wrapping a C wrapper for OpenCV's vector<Mat>
by Joeish W 01 Apr '14

01 Apr '14

Here is the C wrapper for vector<Mat> which is just a typename for a C++ vector: vector_Mat* std_carrayTovectorm(Mat* a, size_t len) { vector<Mat>* v = new vector<Mat>; for(size_t i = 0; i < len; i++) v->push_back(a[i]); return v; } Here is my wrapper in CFFI: ;; vector_Mat* (defctype vector-mat :pointer) (defcfun ("std_carrayTovectorm" %c-arr-to-vector-mat) (:pointer vector-mat) (a (:pointer mat)) (len :unsigned-int)) When I use it as below I get "unhandled memory fault error", If anyone can check my work I would be much appreciative. I can post my mat-value wrapper if necessary. It works fine though. (%c-arr-to-vector-mat (foreign-alloc :pointer :initial-contents(list (mat-value 4 4 +32s+ (scalar 1 2 3)) (mat-value 4 4 +32s+ (scalar 1 2 3)))) 1)

1 0

[Cffi-devel] How do I covert this 2D array to CFFI
by Joeish W 01 Apr '14

01 Apr '14

I'm trying to convert this declaration of an array of points to CFFI but I'm getting unhandled memory fault errors Directly below this C declaration is a tree of foreign-alloc functions I used to create this I'm hoping someone can check my work and tell me if it is my declaration that's the problem Point pt[2][3]; pt[0][0].x = rng.uniform(x_1, x_2); pt[0][0].y = rng.uniform(y_1, y_2); pt[0][1].x = rng.uniform(x_1, x_2); pt[0][1].y = rng.uniform(y_1, y_2); pt[0][2].x = rng.uniform(x_1, x_2); pt[0][2].y = rng.uniform(y_1, y_2); pt[1][0].x = rng.uniform(x_1, x_2); pt[1][0].y = rng.uniform(y_1, y_2); pt[1][1].x = rng.uniform(x_1, x_2); pt[1][1].y = rng.uniform(y_1, y_2); pt[1][2].x = rng.uniform(x_1, x_2); pt[1][2].y = rng.uniform(y_1, y_2); const Point* ppt[2] = {pt[0], pt[1]}; (foreign-array-alloc #2A((501 10) (255 10) (501 255) (10 501)) '(:array :int 4 2))) (d a (foreign-alloc :pointer :count 2 :initial-contents (list (foreign-alloc :pointer :count 3 :initial-contents (list (foreign-alloc :pointer :initial-element (point (uniform rng x-1 x-2) (uniform rng y-1 y-2))) (foreign-alloc :pointer :initial-element (point (uniform rng x-1 x-2) (uniform rng y-1 y-2))) (foreign-alloc :pointer :initial-element (point (uniform rng x-1 x-2) (uniform rng y-1 y-2))))) (foreign-alloc :pointer :count 3 :initial-contents (list (foreign-alloc :pointer :initial-element (point (uniform rng x-1 x-2) (uniform rng y-1 y-2))) (foreign-alloc :pointer :initial-element (point (uniform rng x-1 x-2) (uniform rng y-1 y-2))) (foreign-alloc :pointer :initial-element (point (uniform rng x-1 x-2) (uniform rng y-1 y-2)))))))) Here is how I have point defined it works as intended. The uniform function works well in the point so I didn't post but will if necessary ;; Point* cv_create_Point(int x, int y) (defcfun ("cv_create_Point2" point2) (:pointer point) "Point constructor" (x :int) (y :int))

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel April 2014