- cffi-devel - mailman3.common-lisp.net

[Cffi-devel] Casting variables and functions
by Joeish W 31 Mar '14

31 Mar '14

This is the way I thought you did it but I'm running this and it's not working: (with-foreign-object (float :float) (setf float 6) (type-of float)) >(INTEGER 0 4611686018427387903) The output says it is an integer I tried this: (with-foreign-object (float :float) (setf (mem-ref float :float) 4) (type-of (mem-ref float :float))) And get this error: Value of #1=#:VALUE4 in (SB-KERNEL:%SET-SAP-REF-SINGLE FLOAT 0 #1#) is 4, not a SINGLE-FLOAT. [Condition of type SIMPLE-TYPE-ERROR] If someone could help me cast in CFFI I would appreciate it. the word "cast" isn't even in the CFFI documentation. I just would like to be able to cast anything, from functions to variable into other types. Any maybe if someone skilled in CFFI can tell me if it so good that it can do any thing you can in C. I would appreciate that too.

3 4

[Cffi-devel] writing documentation for CFFI functions
by Joeish W 30 Mar '14

30 Mar '14

Which is the better way do write documentation for functions for a CFFI library like this? C++: int RNG::uniform(int a, int b) Common Lisp: (UNIFORM-D (RNG (:POINTER RNG)) (A :DOUBLE) (B :DOUBLE)) => :DOUBLE or like this without the parenthesis C++: float RNG::uniform(float a, float b) Common Lisp: (UNIFORM-F (RNG :POINTER RNG) A :FLOAT B :FLOAT) => :FLOAT

2 4

[cffi-devel] New and delete pertaining C wrapper for C++ code
by Joeish W 23 Mar '14

23 Mar '14

I have a whole list of C wrappers for OpenCV C++ functions like the one below. And all of them return a "new". I can't change them because they are becoming part of OpenCV and it would make my library perfect to have a consistently updated skeleton to wrap around. My question is in this case how would one of you free these "new" memory allocators...When I run them in any kind of loop. It just eats up my ram, I end up having to restart my pc. Should I make a "delete" wrapper and use that. I've tried using foreign-free but I still have the same issue of having to restart. Any help is appreciated. Mat* cv_create_Mat() { return new Mat(); }

2 4

[cffi-devel] Creating a pointer to a C string
by Joeish W 19 Mar '14

19 Mar '14

I'm trying to recreate a const char* filename parameter for code I have that needs it...The function I'm wrapping is the OpenCV C++ function "imread" it is below in the documentation. It is used to read an image(jpg etc) from a file and return a pointer to it http://docs.opencv.org/modules/highgui/doc/reading_and_writing_images_and_v… first I need to wrap in C as below calling the const char* filename parameter as a String* the below cv_imread does compile on ubuntu trusty using g++. And the function works as intended using g++. Mat* cv_imread(String* filename, int flags) { return new Mat(cv::imread(*filename, flags)); } I wrap in Lisp like this: (defcfun ("cv_imread" %imread) (:pointer mat) (filename (:pointer string*)) (flags :int)) When I usually create a (:pointer string*) parameter I do it like this (window-name (foreign-alloc :string :initial-element "IMREAD Example")) and it works to supply strings that aren't filenames but when I try to use a filename both absolute and relative paths it fails...it also fails using double forward slashes in the pathname. Any advice is appreciated and btw Emacs /SBCL is my Lisp IDE

2 1

[cffi-devel] How would I wite the return value for a defcfun in my documentation
by Joeish W 11 Mar '14

11 Mar '14

Here is my defcfun as I normally write it, ;; Size Mat::size() const ;; Size* cv_Mat_size(Mat* self) (defcfun ("cv_Mat_size" mat-size) (:pointer size) (self (:pointer mat))) the ;; Size Mat::size() const is the C++ function declaration with a Size return value The ;; Size* cv_Mat_size(Mat* self) is the C wrapper function declaration with a Size* return value This is my defcfun with a (:pointer size) return value (defcfun ("cv_Mat_size" mat-size) (:pointer size) (self (:pointer mat))) In my Documentation for this function I list the Common Lisp function declaration as (MAT-SIZE (SELF (:POINTER MAT))) I couldn't figure out if I should add a return value but in C++ the return value always goes up front i/e ;; Size Mat::size() const Is it common to put return values on Lisp/CFFI function declarations and if so where in this declaration (MAT-SIZE (SELF (:POINTER MAT))) should I put mine btw on the CLHS I didn't see or missed return values on any function declaration Thanks in advance for any takers=) Good Day.

3 4

[cffi-devel] CFFI 0.12.0 released
by Luís Oliveira 05 Mar '14

05 Mar '14

Hello everyone, I've just released CFFI 0.12.0. See <https://github.com/cffi/cffi/wiki/NEWS> for a summary of what's new since the previous release. Cheers, -- Luís Oliveira http://kerno.org/~luis/

1 0

[cffi-devel] Maintenance status
by Zach Beane 31 Jan '14

31 Jan '14

Is there anyone processing patches and planning new releases? I ask because https://github.com/cffi/cffi/pull/26 looks like a useful, complete patch, but there's been no feedback - is there a problem with it, or how it was submitted? Should it be reworked and resubmitted? Or rejected? Was it discussed, and I just missed it? Zach

3 2

Returning errno as a second value
by Felix Filozov 28 Jan '14

28 Jan '14

Hi all, In Allegro CL, the only safe way to get errno after a foreign function call is to configure the foreign function definition to return it as a second value. CFFI doesn't deal with errno. There has been some previous discussion ( http://lists.common-lisp.net/pipermail/cffi-devel/2009-January/003017.html) to return errno safely, but doesn't seem like it went anywhere. So any library that tries to get errno is potentially broken in Allegro CL. I'm seeing this in practice with lisp-zmq, for example. I'd like to introduce a new option to defcfun and foreign-funcall called :errno. It would look like this: (foreign-funcall ("strlen" :errno t) :string "foo" :int), or (defcfun (strlen "strlen" :errno t) :int (s :string)). Calling (strlen) would return two values, the return value of the foreign call, and errno. In some Lisps, the only way to get errno is to make an additional foreign call. Then perhaps that call could be made by CFFI and returns as the second value. I've created a pull request (https://github.com/cffi/cffi/pull/28) with a very rudimentary implementation for Allegro CL. Since CFFI delegates the handling of errno to the implementation, perhaps we could preserve the status quo and not get bugged down in grandiose plans of portability. Thoughts and suggestions are welcome. Thanks, Felix

7 23

[cffi-devel] cffi changes are generating deprecation warning in cl-gd now
by Jeff Cunningham 28 Jan '14

28 Jan '14

Hi; A short while ago I started noticing this error message showing up ;; STYLE-WARNING: ;; bare references to struct types are deprecated. Please use (:POINTER (:STRUCT CL-GD::GD-IMAGE)) ;; or (:STRUCT CL-GD::GD-IMAGE) instead. It took me awhile to extract a simple demo case, but I've narrowed it down to the WITH-THICKNESS macro call I believe. I'm not sure which list would be best for this question, so I cross-posted it. Here's a test case. (ql:quickload "cl-gd") (use-package :cl-gd) (let* ((x1 -86) (x2 529) (y1 -0.13) (y2 1.16) (xv '(0.0 1.0 2.0 3.0 4.0)) (yv '(0.99 0.12 0.66 0.24 0.075))) (with-image* (500 250) (allocate-color 255 255 255) (let ((c (allocate-color 0 0 255))) (with-transformation (:x1 x1 :x2 x2 :y1 y1 :y2 y2) (with-thickness (1) (mapl #'(lambda (x y) (when (and (cdr x) (cdr y)) (draw-line (car x) (car y) (cadr x) (cadr y) :color c))) xv yv)) (write-image-to-file "test.png" :if-exists :supersede))))) If you take out the with-thickness macro call the message disappears. I played around with that macro but don't really understand enough about the intricacies of cffi to fix it. Does anyone have any ideas? Here's the macro in question: (defmacro with-thickness ((thickness &key (image '*default-image*)) &body body) "Executes BODY with the current line width of IMAGE set to THICKNESS. The image's previous line width is guaranteed to be restored before the macro exits. Note that the line width is measured in pixels and is not affected by WITH-TRANSFORMATION." (cl-gd::with-unique-names (old-thickness) ;; we rebind everything so we have left-to-right evaluation (cl-gd::with-rebinding (thickness image) `(let ((,old-thickness (thickness ,image))) (unwind-protect (progn (setf (thickness ,image) ,thickness)) ,@body) (setf (thickness ,image) ,old-thickness))))) Much obliged. --Jeff Cunningham

2 1

[cffi-devel] Recommended way to specify libraries
by Elliott Slaughter 04 Jan '14

04 Jan '14

>From [1] I see the following code example (*define-foreign-library* libcurl (:unix (:or "libcurl.so.3" "libcurl.so")) (t (:default "libcurl"))) with the comment "the define-foreign-library clause (t (:default "libcurl"))[...] will adapt to various operating systems". I'm wondering exactly how smart is this automatic handling? On Windows, for example, the conventions are not always followed so closely, and as a result I keep adding more special cases to my define-foreign-library clauses when users complain they can't load the libraries. For example, libpng might be png.dll or libpng.dll or libpng12.dll or libpng12-0.dll or libpng15-15.dll. Will I be required to maintain a list of all possible names for the rest of eternity or is there some better way to manage this situation? Thanks. [1]: http://common-lisp.net/project/cffi/manual/cffi-manual.html#Tutorial_002dLo… -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

3 5