cffi-devel September 2007

cffi-devel@common-lisp.net

17 participants
18 discussions

[cffi-devel] cffi bindings generator
by Anurag 17 Sep '07

17 Sep '07

Hello! I have been trying out c2ffi and swig for generating bindings of a library without any luck. With c2ffi, i generated the xml output from gccxml and parsed them using c2ffi. But all i get in the output is: (in-package :cl-foo) I am using gccxml from cvs. Has someone successfully generated bindings using another tool? Any tips that i should follow? -- thanks Anurag

2 1

[cffi-devel] Can you afford to lose 300, 000 potential customers per year ?
by Instant＠common-lisp.net 06 Sep '07

06 Sep '07

1 0

[cffi-devel] Post your ads where people read them!!!
by Feed＠common-lisp.net 04 Sep '07

04 Sep '07

1 0

[cffi-devel] Strange Performance Issue
by Mikael Lax 03 Sep '07

03 Sep '07

Hello, I was working on a cl-opengl app recently and I noticed that my textures were taking much longer to load than I could remember. After some investigation I could distill the following test functions: (defun test-1 () (let* ((array (make-sequence 'vector (* 512 512 3) :initial-element 0)) (count (length array))) (cffi:with-foreign-object (data 'cl-opengl-bindings:ubyte count) (loop for i below count do (setf (cffi:mem-aref data 'cl-opengl-bindings:ubyte i) (aref array i)))))) (defun test-2 () (let* ((array (make-sequence 'vector (* 512 512 3) :initial-element 0)) (count (length array)) (type (cl-opengl::symbolic-type->real-type :unsigned-byte))) (cffi:with-foreign-object (data type count) (loop for i below count do (setf (cffi:mem-aref data type i) (aref array i)))))) Now observe the timings (in SBCL) for them: * (time (test-1)) Evaluation took: 0.027 seconds of real time 0.019999 seconds of user run time 0.006666 seconds of system run time 0 calls to %EVAL 0 page faults and 3,145,736 bytes consed. NIL * (time (test-2)) Evaluation took: 9.565 seconds of real time 8.629437 seconds of user run time 0.236652 seconds of system run time [Run times include 0.74 seconds GC run time.] 0 calls to %EVAL 0 page faults and 688,918,576 bytes consed. A substantial difference is apparent. For completeness I also tried CLISP: [14]> (time (test-1)) Real time: 10.952836 sec. Run time: 10.169337 sec. Space: 173015440 Bytes GC: 100, GC time: 0.816611 sec. NIL [15]> (time (test-2)) Real time: 18.55567 sec. Run time: 17.215544 sec. Space: 342884976 Bytes GC: 199, GC time: 1.526577 sec. NIL While not as prominent, a difference is still clearly visible. Now I'm curious as to why there's such a performance difference here, am I missing something obvious? Does it happen to anyone else? Sincerely, Mikael Lax PS: I don't know if this or cl-opengl is the appropriate mailing-list for this, but since there seems to be some cross-pollination of cl-opengl/cffi developers I'm sending it here on a gamble.

3 3

[cffi-devel] finding out byte order
by Tamas K Papp 02 Sep '07

02 Sep '07

What is the recommended way find to the byte order of the platform using CFFI? Currently I am using the following: (defun native-byte-order-lsb-p () (with-foreign-object (x :uint32) (setf (mem-ref x :uint32) 1) (= (mem-ref x :uint8) 1))) but it looks like a nasty hack. Tamas

2 1

[cffi-devel] Semantics of defctype*
by Rayiner Hashem 02 Sep '07

02 Sep '07

Hi. I was trying to get Verrazano up and running on my machine, and I noticed that generated bindings would not happily C-c C-k for me in Emacs. I reduced it to the following test case: --- some-file.lisp --- (in-package :cl-user) (defpackage :test-package (:use :cffi :common-lisp)) (in-package :test-package) (cffi::defctype sqlite-int64 :long-long) (cffi::defctype* sqlite-int99 :long-long) (cffi:defcfun ("foo" foo) :int (arg1 sqlite-int64)) (cffi:defcfun ("bar" bar) :int (arg1 sqlite-int99)) --- end some-file.lisp --- If you're in a SLIME session with CFFI already loaded, compiling this file once will result in an error. Compiling it again will make it work. If you compile just the cffi:defctype* declaration with C-c C-c, then try compiling the file, it works. Presumably, defcfun wants the types in its arg lists to be available at compile time, and defctype* doesn't make them available? That said, we shouldn't really be using defctype* at all, right? Slightly more clever processing of definitions should obviate any need for it. Sincerely, Rayiner Hashem

2 3

[cffi-devel] "How would you like to have your ad on 2 Million Websites ?"
by BlogBlaster＠common-lisp.net 02 Sep '07

02 Sep '07

1 0

[cffi-devel] New patches: 1-Sep-2007
by loliveira＠common-lisp.net 02 Sep '07

02 Sep '07

Sat Sep 1 15:10:50 EDT 2007 Luis Oliveira <loliveira(a)common-lisp.net> * Fix indentation in defctype* M ./src/early-types.lisp -7 +7 Mon Jun 25 10:45:50 EDT 2007 tomi.borbely(a)gmail.com * fix: missing eval-when M ./src/early-types.lisp -7 +8 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-070901.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel September 2007