Groveller's bitfield support

Hi all,

This patch adds bitfield support to the groveller. Here is the usage:

In grovel file, write:

(bitfield flags-ctype
  ((:flag-a "FLAG_A")
    :documentation "DOCU_A")
  ((:flag-b "FLAG_B")
    :documentation "DOCU_B")
  ((:flag-c "FLAG_C")
    :documentation "DOCU_C"))

And if the C header file has:

#define FLAG_A 1
#define FLAG_B 2
#define FLAG_C 4

This will generate:

(cffi:defbitfield (flags-ctype)
  (:flag-a 1)
  (:flag-b 2)
  (:flag-c 4))

Documentation is also provided in the patch.

Thanks

Re: foreign-string-to-lisp should use keywords

On Thu, Jan 14, 2010 at 9:30 AM, Leslie P. Polzer
<sky <at> viridian-project.de> wrote:
> A minor nit I found while passing a custom encoding to
> this function. It's quite cumbersome to have to specify
> the other optional arguments to this function just to
> change one of them.

FOREIGN-STRING-TO-LISP does take keyword arguments. What am I missing?

--

-- 
Luís Oliveira
http://r42.eu/~luis/

Re: ECL specific changes for CFFI

On Thu, Apr 29, 2010 at 8:49 AM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll <at> googlemail.com> wrote:
>> I see. What's the rationale? Could ECL's FOREIGN-FREE/ALLOC use plain
>> malloc()/free()?
>
> But why? As we said there is nothing in the CFFI specification that mandates
> use of malloc(), just that the memory will not be freed

Right. The CFFI specification/documentation is a work in progress
though. I believe one of UFFI's major shortcomings is that it fails to
ensure consistent behaviour across implementations for error
situations. CFFI is much better in that regard, but it certainly could
use more work. The issue of whether FOREIGN-FREE/ALLOC should be
implemented in terms of malloc()/free() is one such example.

> Current system uses the same foreign memory manager as ECL, because it is
> safer for us, allows a good coexistence of both sets of memory and allows us
> to keep track of the amount of memory used. Furthermore, should it be
> needed, some pointers can be allocated as collectable and automatically
> reclaimed by our GC -- not that it is done by default, though

I'm convinced.  I'll update the manual to be explicit about this.
Using DEFCFUN to get at malloc()/free() should be straightforward
anyway, except we don't have a size_t type.

> Also, except for OpenMCL I see no explicit use of malloc/free anywhere. It
> must be some kind of accident that it works with other implementations.

SBCL calls malloc/free under the hood, as do most other
implementations. I think Allegro uses a different allocator.

detecting int size used by library

Hi,

Is there a way to detect the size of integers (ie 32 or 64 bit) used
by a library?

I am using LAPACK/BLAS (ATLAS) libraries via CFFI.  Recently, my
tests failed, and to my surprise, the solution was to use 32-bit ints.
Note that I am on a 64-bit platform, using the Ubuntu libraries, so
why this happens is a mystery.  But it would be great if I could
detect it somehow from within Lisp.

Thanks,

Tamas

Re: detecting int size used by library

_______________________________________________
cffi-devel mailing list
cffi-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel

Re: detecting int size used by library

On Wed, May 26, 2010 at 05:42, Tamas K Papp <tkpapp <at> gmail.com> wrote:
> I am using LAPACK/BLAS (ATLAS) libraries via CFFI.  Recently, my
> tests failed, and to my surprise, the solution was to use 32-bit ints.
> Note that I am on a 64-bit platform, using the Ubuntu libraries, so
> why this happens is a mystery.  But it would be great if I could
> detect it somehow from within Lisp.

In the particular case of LAPACK and the BLAS: the default LAPACK and
BLAS should always use 32-bit ints (Fortran's INTEGER type, a.k.a.
"INTEGER(4)").  There are versions of both libraries that use 64-bit
ints ("INTEGER(8)"), but the system should always identify them
specially: either as separate, differently named libraries, or as
differently named functions within the same library.  (I've seen both
possibilities.)

In general: Of course it would be nicer to be able to do everything in
Lisp, but have you taken a look at CMake's CheckTypeSize module?

http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:CheckTypeSize

mfh

Re: detecting int size used by library

On Wed, 2010-05-26 at 11:42 +0000, Tamas K Papp wrote:
> Hi,
> 
> Is there a way to detect the size of integers (ie 32 or 64 bit) used
> by a library?
> 
> I am using LAPACK/BLAS (ATLAS) libraries via CFFI.  Recently, my
> tests failed, and to my surprise, the solution was to use 32-bit ints.
> Note that I am on a 64-bit platform, using the Ubuntu libraries, so
> why this happens is a mystery. 

Linux uses the LP64 data model, in which ints are 32bit:
http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models

>  But it would be great if I could detect it somehow from within Lisp.

cffi:foreign-type-size will return the size of the builtin types

--

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib

_______________________________________________
cffi-devel mailing list
cffi-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel

:pointer size on 64-bit OS's

I am receiving reports of nasty intermittent crashes when lispbuilder-sdl is 
run within a 32-bit Lisp (SBCL & CCL) on a 64-bit OS (Windows 7 and OSX). A 32-
bit Lisp is used because the SDL library is 32-bit. No problems are reported 
using Lispworks/32-bit in Windows 7.

The errors reports state that the Lisp debugger is invoked on the CFFI call to 
"SDL_PollEvent" (stack trace below). This is intermittent in that it might 
happen almost immediately, or after several thousand times through the event 
loop.

SDL_PollEvent takes an SDL_Event struct as a parameter. 

SDL_Event looks like this;

(cffi:defcunion SDL-Event
	(type :unsigned-char)
	(active SDL-Active-Event)
	(key SDL-Keyboard-Event)
	(motion SDL-Mouse-Motion-Event)
	(button SDL-Mouse-Button-Event)
	(jaxis SDL-Joy-Axis-Event)
	(jball SDL-Joy-Ball-Event)
	(jhat SDL-Joy-Hat-Event)
	(jbutton SDL-Joy-Button-Event)
	(resize SDL-Resize-Event)
	(expose SDL-Expose-Event)
	(quit SDL-Quit-Event)
	(user SDL-User-Event)
	(syswm SDL-Sys-WM-Event))

A few of the SDL_Events structs include pointers...

(cffi:defcstruct SDL-User-Event
	(type :unsigned-char)
	(code :int)
	(data1 :pointer)
	(data2 :pointer))

(cffi:defcstruct SDL-Sys-WM-Event
	(type :unsigned-char)
	(msg :pointer))

If :pointer is created as a 64-bit pointer instead of 32-bit then I can foresee 
a problem as SDL_Event created by CFFI is larger than expected by SDL_PollEvent.

So my question is, on SBCL/32-bit & CCL/32-bit, what is the expected size 
of :pointer on a 64-bit OS?

Stack trace for SBCL/32-bit below;

debugger invoked on a SIMPLE-ERROR: EXCEPTION_ACCESS_VIOLATION

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE] Ignore runtime option --load "load.lisp".
  1: [ABORT   ] Skip rest of --eval and --load options.
  2:            Skip to toplevel READ/EVAL/PRINT loop.
  3: [QUIT    ] Quit SBCL (calling #'QUIT, killing the process).

("bogus stack frame")
0] ba

0: ("bogus stack frame")
1: ("foreign function: #x757A8112")
2: ("foreign function: #x68132D60")
3: ("foreign function: #x68106812")
4: ("foreign function: #x6810684B")
5: (LISPBUILDER-SDL-CFFI::SDL-POLL-EVENT #.(SB-SYS:INT-SAP #X02106EC0))

- Luke

Re: :pointer size on 64-bit OS's

On Thu, May 27, 2010 at 1:06 AM, Luke Crook <luke <at> balooga.com> wrote:
> So my question is, on SBCL/32-bit & CCL/32-bit, what is the expected size
> of :pointer on a 64-bit OS?

32-bit. You can check it yourself with (cffi:foreign-type-size :pointer).

--

-- 
Luís Oliveira
http://r42.eu/~luis/

Re: :pointer size on 64-bit OS's

On Thu, 27 May 2010, Luís Oliveira wrote:

> On Thu, May 27, 2010 at 1:06 AM, Luke Crook <luke <at> balooga.com> wrote:
>> So my question is, on SBCL/32-bit & CCL/32-bit, what is the expected size
>> of :pointer on a 64-bit OS?
>
> 32-bit. You can check it yourself with (cffi:foreign-type-size :pointer).

On my Slackware 13, 64-bit box,

#include <iostream>
int main(int, char**)
{
   std::cout << sizeof(void *) <<"\n";
   return 0;
}

prints "8".

- Daniel

_______________________________________________
cffi-devel mailing list
cffi-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel