cffi-devel November 2013

cffi-devel@common-lisp.net

6 participants
19 discussions

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] How to define a pointer to a 2d array
by Joeish W 08 Dec '13

08 Dec '13

I have a function that accepts a void* as a parameter Im trying to convert this to use as the void* float trainingData[4][2] = { {501, 10}, {255, 10}, {501, 255}, {10, 501} }; this is how i do a void* 1d array float labels[4] = {1.0, -1.0, -1.0, -1.0}; (labels (foreign-alloc :float :initial-contents '(1.0 -1.0 -1.0 -1.0))) so how do i do the 2d array

2 3

[cffi-devel] C to Lisp
by Greg Bennett 27 Nov '13

27 Nov '13

Good morning, I (think I) might be close to getting a result in having a C function return its output to Lisp. I shall be very grateful for comments and corrections to what I have done, and thank readers for their patience. Here is the C-function from which I wish to get the result Hello Lisp from C on the lisp side: /* Hello.c program */ #include<stdio.h> void Hello(void) { printf("Hello Lisp from C\n"); return 0 ; } At the end of the process, I hope to be able to do this on the Lisp side: (defcfun ("Hello" HiFromC) (:void)) and then (HiFromC) -> Hello Lisp from C Both C and Lisp sessions are below in case details are relevant. Somewhere I have missed a critical element. Thanks to a message from Luis Oliveira pointing me to the necessity of using a shared library as the intermediary between C and Lisp. There seem to be as many recipes for creating such libraries as there are posters of the topic, and as many variations on the code too. I have put together the C side following very much this page: www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html In file /home/gwbennett/Hello.h #ifndef Hello_h__ #define Hello_h__ extern void Hello(void); #endif // Hello_h__ In file /home/gwbennett/Hello.c /* Hello program */ #include<stdio.h> void Hello(void) { printf("Hello Lisp from C\n"); return 0 ; } In file main.c /* This is main.c to go with Hello.c,h */ #include <stdio.h> #include "Hello.h" int main (void) { Hello(); return 0; } Then gcc -c -Wall -Werror -fpic Hello.c -> OK gcc -shared -o libfHello.so Hello.o -> OK gcc -L/home/gwbennett -Wall -o test main.c -lHello -> OK Step 4 of the above page is about making the library visible. I have tried all 3 routes with the same results; at the moment I have taken the path of installing libHello.so in /usr/lib (and in /usr/loca/lib too)as described in the Section Using ldconfig to modify ld.so gcc -Wall -o test main.c -lfoo -> OK ldd test | grep foo -> /usr/locl/lib/libHello.so (0x00007f946c0c4000) ./test -> Hello Lisp from C so things seem to work down the C-side On the Lisp side I (hope I) am following the cffi manual page 10. I assume that cffi looks for shared libraries in the same sort of 'system' places as C, but just in case, see page 106 on *foreign-library-directories*. Start ccl version 1.9-r15972M (LinuxX8664) (require :cffi) -> OK (defpackage :cffi-user (:use :common-lisp :cffi)) -> OK (in-package :cffi-user) -> OK ;P106 (pushnew #P/"usr/lib" *foreign-library-directories* :test #'equal) -> OK (pushnew #P"/usr/local/lib" *foreign-library-directories* :test #'equal) -> OK (load-foreign-library '(:default "LibHello")) -> OK ;; I think I should be able to define the C -> Lisp name function (defcfun ("Hello" HiFromC) (:void)) -> HIFROMC ;; and execute it to get the message (HiFromC) -> NIL ;; .. so evidently I have not completely understood what is necessary to achieve the desired result. Again, thanks for any and all assistance. Cheers /Greg Bennett

3 2

[cffi-devel] cffi and c++
by Greg Bennett 24 Nov '13

24 Nov '13

As I start to learn about cffi, I see that the manual is copyright 2005 and mentions that C++ support is incomplete but being worked on. I should appreciate knowing what the current status of cffi is with respect to c++. Thx /Greg Bennett

2 1

Re: [cffi-devel] Access to code
by Luís Oliveira 24 Nov '13

24 Nov '13

On Sat, Nov 23, 2013 at 12:56 AM, Greg Bennett <gwbennett(a)sentex.ca> wrote: > At least I have a way forward: make up a simple c function - dear old > Hello World will do. Compile a shared library containing it. Load that > as you suggest. Use defcfun to give it a lisp name. Try calling that > name. > > As an aside: > I had hoped that the tutorial would hold that sort of simple example. I think it never occurred to us that the instructions on how to compile a shared library should be on the tutorial. I suppose it assumes you already have a shared library to start with. Where do you think that should be made more clear? > I cut+pasted segments of it into ccl version 1.9-r15972M (LinuxX8664) > only to have it break in two places: > section 4.7 when trying to call (set-curl-option-nosignal *easy-handle* > 1) WITHOUT having executed the 2 progn's in that section (mistakenly > assuming that the function was built automatically) only to be told > that there was no such function. Going back and executing the progn's > seemed to fix that. > > section 4.8 when executing (set-curl-option-url *easy-handle* > "http://www.cliki.net/CFFI") only to be told > The value "http://www.cliki.net/CFFI" is not of the expected type > CCL:MACPTR > > at which point I abandoned the tutorial. Notice the preceding paragraph. That code is merely illustrative. See the "Returning to the current set-curl-option-url interface, here is what we must do..." bits that follow. HTH, -- Luís Oliveira http://kerno.org/~luis/

1 0

[cffi-devel] What do i do with a c "bool" return type
by Joeish W 23 Nov '13

23 Nov '13

Here is the function im wrapping a c wrapper for a c++ opencv function and below it my wrapper bool cv_VideoCapture_isOpened0(VideoCapture* self) { return self->isOpened(); } (cffi:defcfun ("cv_VideoCapture_isOpened0" %vid-cap-cam-is-open) :pointer (self (:pointer video-capture))) not sure how to call the bool return type, the below defun didnt work using pointer for return type or int on defcfun and casting from boolean inside the defun below with (convert-from-foreign ,var :boolean). when i used a pointer return type, as swig wraps it i mem-refed or mem-arefed the defcun as :int in my defun below (defun video-cap-cam-is-open (self) (convert-from-foreign (%video-cap-cam-is-open self) :boolean)) in c++ the cout output of the functions im wrapping are 1 for the first one and 0 for the one after cap.release(); is called cout << "a =" << cap.isOpened(); = 1 cap.release(); cout << "b = " << cap.isOpened(); = 0 function documentation for function im wrapping is here http://docs.opencv.org/modules/highgui/doc/reading_and_writing_images_and_v…

2 1

[cffi-devel] Access to code
by Greg Bennett 22 Nov '13

22 Nov '13

Running under linux mint 14 64 bit; using ccl as the lisp. I have been looking at the examples provided with the cffi material, as well as at the manual, to see how the wrapping of c functions seems to work. These are very helpful but depend on system calls and "eveything" knows where they are. Suppose I have a set of c functions, and their .o files too, which I would like to wrap using defcfun and relatives. What precautions must I take in making known to ccl the locations(s) of these foreign files ? Is it a bit like asdf with a *central-registry* to hold such locations, or have I missed some obvious pointer to the answer ? Thanks for any and all assistance. Cheers /Greg Bennett

2 1

[cffi-devel] Possible foreign-free bug
by Joeish W 12 Nov '13

12 Nov '13

(defun get-cols-example () (let* ((matrix (create-mat 5 7 +8uc1+)) (submat (foreign-alloc `(:struct cv-mat) :initial-contents '()))) (get-cols matrix submat 0 3) (foreign-free submat))) when i run the above code with the (get-cols matrix submat 0 3) line commented or without foreign-free it runs fine but as it is above i get below error Error in `/usr/bin/sbcl': free(): invalid next size (fast): 0x00007fffd4000c60 *** in inferior lisp followed by many lines of code las below. All the fuinctions in the defun above are neccessary to reproduce issue: ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x80996)[0x7ffff7154996] [0x100681f7b8] ======= Memory map: ======== 00400000-00435000 r-xp 00000000 08:03 135423 /usr/bin/sbcl 00635000-00636000 r-xp 00035000 08:03 135423 /usr/bin/sbcl 00636000-00648000 rwxp 00036000 08:03 135423 /usr/bin/sbcl I dont have any foreign-free functions in my wrappers and the functions involved GET-COLS and CREATE-MAT are wrappers for OpenCV's cvGetCols and cvCreateMat...the wrappers are below for debugging purpose ;; CvMat* cvGetCols(const CvArr* arr, CvMat* submat, int start_col, int end_col) (defcfun ("cvGetCols" get-cols) (:pointer (:struct cv-mat)) "Returns array column span." (arr cv-arr) (submat (:pointer (:struct cv-mat))) (start-col :int) (end-col :int)) ;; CvMat* cvCreateMat(int rows, int cols, int type) (defcfun ("cvCreateMat" create-mat) (:pointer (:struct cv-mat)) (rows :int) (cols :int) (type :int)) any way i can help debug this i will and any guidance on this issue is much appreciated =)

3 3

[cffi-devel] possible foreign-free bug
by Joeish W 12 Nov '13

12 Nov '13

2 1

[cffi-devel] Possible foreign-free bug
by Joeish W 11 Nov '13

11 Nov '13

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel November 2013