Bitfields and defcenum

Hello,

While building CFFI bindings for GLUT and using enums for defining  
bitfield masks, I came across this example:

(defcenum display-mode
   (:rgb 0)
   (:rgba 0)
   (:index 1)
   (:single 0)
   (:double 2)
   (:accum 4)
   (:alpha 8)
   (:depth 16)
   (:stencil 32)
   (:multisample 128)
   (:stereo 256)
   (:luminance 512))

defcenum won't accept this because it contains duplicate values. This  
a misfeature introduced by myself that I forgot to fix and people  
have complained[1] about this before. Unless someone has any  
objections, I'll implement something like what CLISP has.

But this makes me wonder if another abstraction, say DEFBITFIELD  
would be useful. Something like:

(defbitfield name
   (0 sym1 sym2 ...)
   (1 sym3)

Re: unnamed callback (closures?)

[resending directly as it seems messages posted through Gmane don't
make it to the list :-/ ]

>>>>> "Luís" == Luís Oliveira <luismbo <at> gmail.com>:
 Luís> "Hoehle, Joerg-Cyril" <Joerg-Cyril.Hoehle <at> t-systems.com> writes:
 >> In CLISP, every closure can be turned into a callback, and this is
 >> valuable since it allows to retrieve context information out of the
 >> closure.  Is cffi's limitation caused by some implementations?

 Luís> To my knowledge, yes. AFAICT, only SBCL/x86 and CLISP support
 Luís> that.

 Luís> Regarding the behaviour of CFFI:DEFCALLBACK as a non-toplevel
 Luís> form, not only will it set it globally, the callback itself won't
 Luís> be generated at runtime on most Lisp, IIRC.

I've just ran into the same problem. I really really need closures as
callbacks. I've tried the naive approach:

(defmacro object-event-callback-add (obj type function)
  `(foreign-funcall "evas_object_event_callback_add"
    :pointer ,obj
    callback-type ,(foreign-enum-value 'callback-type type)
    :pointer (get-callback (defcallback ,(gensym "CB")
			       :void
			       ((data :pointer) (cb-e evas) (cb-obj object) (cb-event :pointer))
			     (funcall ,function cb-e cb-obj cb-event)))
    :pointer (null-pointer)))

... but that's a half-baked solution with too many limitations and only

Re: Re: unnamed callback (closures?)

Jan Rychter <jan <at> rychter.com> writes:

> I mostly develop on SBCL/x86 and ECL, so even if a solution worked
> on these platforms only, I'd be really happy.

If all else failed, you could resort to passing something like:

#+sbcl (alien-sap (alien-lambda ...))
#+ecl #| whatever is appropriate for an ecl anon callback |#

as a pointer to a CFFI function.

While I'd like to see some kind of CALLBACK-LAMBDA as the base
primitive in CFFI-SYS for callbacks someday, the implementation
support for this is pretty minimal.

I think it boils down to: how many Lisps need to support something
before we consider adding it an optional feature to CFFI-SYS?  If
there's enough support, what about exporting some sort of
CFFI-FEATURES:NO-ANONYMOUS-CALLBACKS feature and adding
CALLBACK-LAMBDA to CFFI-SYS for the Lisps that can do it?

James

Re: Re: unnamed callback (closures?)

>>>>> "James" == James Bielman <jamesjb <at> jamesjb.com> writes:
 James> Jan Rychter <jan <at> rychter.com> writes:
 >> I mostly develop on SBCL/x86 and ECL, so even if a solution worked
 >> on these platforms only, I'd be really happy.

 James> If all else failed, you could resort to passing something like:

 James> #+sbcl (alien-sap (alien-lambda ...))  +ecl #| whatever is
 James> #appropriate for an ecl anon callback |#

 James> as a pointer to a CFFI function.

Not sure if I fully understand what you mean here, but I'll try reading
some code. Perhaps I can implement something myself.

 James> While I'd like to see some kind of CALLBACK-LAMBDA as the base
 James> primitive in CFFI-SYS for callbacks someday, the implementation
 James> support for this is pretty minimal.

 James> I think it boils down to: how many Lisps need to support
 James> something before we consider adding it an optional feature to
 James> CFFI-SYS?  If there's enough support, what about exporting some
 James> sort of CFFI-FEATURES:NO-ANONYMOUS-CALLBACKS feature and adding
 James> CALLBACK-LAMBDA to CFFI-SYS for the Lisps that can do it?

Well, let me pitch in with a vote: I consider this feature absolutely
essential for any serious GUI programming. Generated menus with closures
that get called back and already have all the context information are
what makes Lisp GUI programming different from C GUI programming. If you
don't put that on top of GTK (or EFL, in my case), you end up with a

Re: Re: unnamed callback (closures?)

>>>>> On Wed, 01 Feb 2006 09:46:27 +0100, Jan Rychter <jan <at> rychter.com> said:
>>>>> "Luís" == Luís Oliveira <luismbo <at> gmail.com>:
>  Luís> "Hoehle, Joerg-Cyril" <Joerg-Cyril.Hoehle <at> t-systems.com> writes:
>  >> In CLISP, every closure can be turned into a callback, and this is
>  >> valuable since it allows to retrieve context information out of the
>  >> closure.  Is cffi's limitation caused by some implementations?
> 
>  Luís> To my knowledge, yes. AFAICT, only SBCL/x86 and CLISP support
>  Luís> that.
> 
>  Luís> Regarding the behaviour of CFFI:DEFCALLBACK as a non-toplevel
>  Luís> form, not only will it set it globally, the callback itself won't
>  Luís> be generated at runtime on most Lisp, IIRC.
> 
> I've just ran into the same problem. I really really need closures as
> callbacks. I've tried the naive approach:
> 
> (defmacro object-event-callback-add (obj type function)
>   `(foreign-funcall "evas_object_event_callback_add"
>     :pointer ,obj
>     callback-type ,(foreign-enum-value 'callback-type type)
>     :pointer (get-callback (defcallback ,(gensym "CB")
> 			       :void
> 			       ((data :pointer) (cb-e evas) (cb-obj object) (cb-event :pointer))
> 			     (funcall ,function cb-e cb-obj cb-event)))
>     :pointer (null-pointer)))
> 
> ... but that's a half-baked solution with too many limitations and only
> works in a simple example that you run once.
> 

Re: Re: unnamed callback (closures?)

> >>>>> On Wed, 01 Feb 2006 09:46:27 +0100, Jan Rychter <jan <at> rychter.com> said:
> >>>>> "Luís" == Luís Oliveira <luismbo <at> gmail.com>:
> >  Luís> "Hoehle, Joerg-Cyril" <Joerg-Cyril.Hoehle <at> t-systems.com> writes:
> >  >> In CLISP, every closure can be turned into a callback, and this is
> >  >> valuable since it allows to retrieve context information out of the
> >  >> closure.  Is cffi's limitation caused by some implementations?
> > 
> >  Luís> To my knowledge, yes. AFAICT, only SBCL/x86 and CLISP support
> >  Luís> that.
> > 
> >  Luís> Regarding the behaviour of CFFI:DEFCALLBACK as a non-toplevel
> >  Luís> form, not only will it set it globally, the callback itself won't
> >  Luís> be generated at runtime on most Lisp, IIRC.
> > 
> > I've just ran into the same problem. I really really need closures as
> > callbacks. I've tried the naive approach:
> > 
> > (defmacro object-event-callback-add (obj type function)
> >   `(foreign-funcall "evas_object_event_callback_add"
> >     :pointer ,obj
> >     callback-type ,(foreign-enum-value 'callback-type type)
> >     :pointer (get-callback (defcallback ,(gensym "CB")
> >           :void
> >           ((data :pointer) (cb-e evas) (cb-obj object) (cb-event :pointer))
> >         (funcall ,function cb-e cb-obj cb-event)))
> >     :pointer (null-pointer)))
> > 
> > ... but that's a half-baked solution with too many limitations and only
> > works in a simple example that you run once.
> > 

darcs patch: Add check for FreeBSD and remove some redundant assign...

Wed Feb  1 22:40:58 VLAT 2006  keriax <at> gmail.com
  * Add check for FreeBSD and remove some redundant assignments.

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

Re: darcs patch: Add check for FreeBSD and remove some redundant assign...

keriax <at> gmail.com writes:

> Wed Feb  1 22:40:58 VLAT 2006  keriax <at> gmail.com
>   * Add check for FreeBSD and remove some redundant assignments.

Thanks, I've merged this.

James

Re: Problem with SDL_Init using CFFI with Clisp in Windows 98

Jeremy Smith <jeremy <at> decompiler.org> writes:

> I'm posting this to the CFFI discussion group, I previously posted it to
> the Lisp Application Builder list.

(Sorry for the delay in approving your message; the list gets so much
spam I don't check it all that often.)

> What I'm getting to is, I read on comp.lang.lisp that the CFFI-based
> SDL module does not work on Windows 98 under Clisp. I just tested it
> on my Windows 98 laptop (P166  and it says the same thing. "FFI:
> FOREIGN-LIBRARY-FUNCTION: No dynamic object named 'SDL_Init' in
> library :DEFAULT"

My first guess is that you are using an older version of CLISP that is
technically unsupported by CFFI.  What CLISP version are you using,
and do the SDL bindings work if you upgrade to the latest release?

IIRC, several releases ago, a feature was added to CLISP to look for
foreign symbols globally when the library is :DEFAULT, instead of only
in the C library.  Perhaps this is not working on Win9x... does this
work under NT/XP/whatever?

> I did a little bit of detective work:
>
> Clisp's top-level view shows the scope, at the time of the above error
> as (from src/cffi-clisp.lisp):
>
>       `(funcall
>         (load-time-value

AW: Bitfields and defcenum

>But this makes me wonder if another abstraction, say DEFBITFIELD  
>would be useful. Something like:
The more expressive, the better IMHO.

>(defbitfield name
>   (0 sym1 sym2 ...)
Never thought about it.  But who says bitfields will soon say "arbitrary width".  Not everything is a single bit.

Regards,
	Jörg Höhle.