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

[cffi-devel] Something is definitely wrong...
by Dmitri Hrapof 21 Dec '06

21 Dec '06

Hello! I continued to experiment with my Freetype bindings http://www.common-lisp.ru/cleft.asd http://www.common-lisp.ru/cleft.lisp and more strange behaviour was found. Firstly, as I said earlier, FT_Load_Char(face, char, FT_LOAD_RENDER) doesn't work when called from Lisp. However, FT_Load_Char(face, char, FT_LOAD_DEFAULT) + FT_Render_Glyph(glyph, FT_RENDER_MODE_NORMAL) work. Secondly, the following code (with-freetype lib (with-face lib (face "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf") (set-char-size face 64 0 600 0) (with-foreign-object (matrix 'ft-matrix) (setf (foreign-slot-value matrix 'ft-matrix 'xx) (cos (deg->rad 22.5)) (foreign-slot-value matrix 'ft-matrix 'xy) (- (sin (deg->rad 22.5))) (foreign-slot-value matrix 'ft-matrix 'yx) (sin (deg->rad 22.5)) (foreign-slot-value matrix 'ft-matrix 'yy) (cos (deg->rad 22.5))) (ft-set-transform face matrix (null-pointer)) (glyph-pixarray face (char-code #\a))))) rotates glyph and returns rendered bitmap, but this bitmap is always of the same size (for the given character), no matter what the resolution and height are (set by set-char-size) Tested on Ubuntu 6.10 PPC + SBCL 1.0 or Clisp 2.41 and Fedora Core 3 i386 + SBCL 0.9.15 Looks like some C functions work and some other do not... Why? Thank you for answers and Happy Christmas! Dmitri

1 1

[cffi-devel] New patches: 20-Dec-2006
by loliveira＠common-lisp.net 21 Dec '06

21 Dec '06

Wed Dec 20 17:11:41 EST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * clisp: copy-in/out implementation of with-pointer-to-vector-data Patch courtesy of Stelian Ionescu. M ./src/cffi-clisp.lisp +32 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-061220.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] [PATCH] adding copy-in/out WITH-POINTER-TO-VECTOR-DATA to the clisp backend
by Stelian Ionescu 20 Dec '06

20 Dec '06

until a better solution can be found, the attached patch adds a copy-in/out WITH-POINTER-TO-VECTOR-DATA to the clisp backend -- (sign :name "Stelian Ionescu" :aka "fe[nl]ix" :quote "Quidquid latine dictum sit, altum sonatur.")

2 1

[cffi-devel] hard to find bugs pop up when working with enums :(
by Lars Rune Nøstdal 20 Dec '06

20 Dec '06

..say I have this: SWGtk> (defcenum UpdateType :continuous :discontinous :delayed) ..then do: SWGtk> (foreign-enum-value 'UpdateType :not-valid) ..I get a meaningful message from CFFI: :not-valid is not defined as a keyword for enum type #<cffi::foreign-enum UpdateType>. ..very nice; as expected. But if I do: SWGtk> (foreign-funcall "someCFunction" UpdateType :not-valid) ..I get: The value nil is not of type (signed-byte 32). It is almost impossible to debug this because I cannot see any NIL anywhere. :not-valid is a constant here of course - but if it is in a variable: SWGtk> (foreign-funcall "someCFunction" UpdateType some-variable) ..`some-variable' _still_ doesn't contain NIL so I've been lost for quite some time here. -- Lars Rune Nøstdal http://nostdal.org/

2 1

[cffi-devel] calling a function of the same name from two DLLs
by Jack Unrue 20 Dec '06

20 Dec '06

Hello, CFFI folks. What are the implications of declaring two foreign functions, each foreign name being the same but which are implemented in two separate DLLs? The specific case I have in mind is the Win32 function DllGetVersion, which can return different meta-data for comctl32.dll vs. shell32.dll. I am effectively doing the following right now: (load-foreign-library "comctl32.dll") (defcfun ("DllGetVersion" comctl-dll-get-version) HRESULT (info :pointer)) (load-foreign-library "shell32.dll") (defcfun ("DllGetVersion" shell-dll-get-version) HRESULT (info :pointer)) Is there any caching of CFFI foreign function meta-data behind the scenes, perhaps keyed by the foreign function name? Such as might be causing identical results no matter which is called first, or which load-foreign-library occurs first? Note: my WinXP install has several different versions of comctl32.dll, one of which matches the shell32.dll version, but I have at least one configuration where I know the result really is wrong (as if the result from the other DllGetVersion call was being cached). -- Jack Unrue

8 15

[cffi-devel] New patches: 19-Dec-2006
by loliveira＠common-lisp.net 20 Dec '06

20 Dec '06

Tue Dec 19 14:45:53 EST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Correctly handle duplicate loading of libraries in CMUCL. Patch courtesy of Stelian Ionescu. M ./src/cffi-cmucl.lisp -2 +19 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-061219.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] [PATCH] fix %load-foreign-library on cmucl
by Stelian Ionescu 19 Dec '06

19 Dec '06

on CMUCL it get an error when I load twice a library with LOAD-FOREIGN-LIBRARY because SYS::LOAD-OBJECT-FILE returns NIL when re-loading a shared object. the attached patch fixes this -- (sign :name "Stelian Ionescu" :aka "fe[nl]ix" :quote "Quidquid latine dictum sit, altum sonatur.")

3 5

[cffi-devel] WITH-POINTER-TO-VECTOR-DATA ?
by Luke Crook 19 Dec '06

19 Dec '06

I'm trying to optimize memory access to an SDL_Surface in the lispbuilder-sdl project. An SDL_Surface is basically a foreign array. Reading and writing individual pixels involves calling MEM-AREF to access an integer value at a specific offset in the SDL_Surface array. This is fine for individual pixel reads and writes but sub-optimal for a rotation function where there is a read and corresponding write for each pixel in the surface (For example a 320x240 resolution surface requires a total of 153,600 calls to MEM-AREF in order to perform a rotation.) Can I use WITH-POINTER-TO-VECTOR-DATA to somehow speed this up? Thanks, - Luke

2 1

[cffi-devel] something is wrong...
by Dmitri Hrapof 10 Dec '06

10 Dec '06

Hello! I'm trying to use libfreetype.so via CFFI. What I hacked up so far is located here: http://www.common-lisp.ru/cleft.asd http://www.common-lisp.ru/cleft.lisp The code like that works: (with-freetype lib (with-face lib (face "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf") (docharmap (code face) (format t "~a " (code-char code))))) and prints out all glyphs in a font. However, the following doesn't do what I want: (with-freetype lib (with-face lib (face "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf") (set-char-size face (* 16 64) (* 16 64) 300 300) (glyph-pixarray face (char-code #\a)))) It returns #2A() Looks like the whole bitmap structure is set to zeros. I think I'm following FreeType and CFFI tutorials closely and I can't explain what's wrong... Thank you for your help, Dmitri

1 1

[cffi-devel] New patches: 8-Dec-2006
by loliveira＠common-lisp.net 09 Dec '06

09 Dec '06

Fri Dec 8 03:52:24 EST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Fix WITH-POINTER-TO-VECTOR-DATA on recent SBCLs Patch courtesy of Stelian Ionescu. M ./src/cffi-sbcl.lisp -1 +1 Sat Dec 2 22:26:20 EST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Bugfixes for ECL/DFFI Patch courtesy of Juan Jose Garcia-Ripoll. M ./src/cffi-ecl.lisp -3 +5 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-061208.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0