cffi-devel January 2014

cffi-devel@common-lisp.net

8 participants
4 discussions

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel January 2014