Re: cffi-sys::default-encoding returns nil on clisp/mingw

Hoehle, Joerg-Cyril wrote:
> Jack Unrue wonders:
>   
>> For instance, can anyone point me at a spot in the CLISP manual that
>> states that *FOREIGN-ENCODING* will always correspond to the value
>> of one of the symbols in the :charset package?
>>     
>
> Quite to the contrary.  When linked with the iconv library, you can also use any encodings provided by that
library. The encoding name would then be a string.
>
> I've never heard of anyone making use of that feature. People are typically satisfied with the many
encodings that clisp ships.
>
> Perhaps I misread you. Above, I'm talking about ENCODING-NAME, which yields a symbol from the CHARSET
package in typical cases. Were you asking whether
> (LOOP/ITERATE FOR s IN-PACKAGE "CHARSET"
>       THEREIS (eq (symbol-value s) *foreign-encoding*))
> ? That's a false assumption, as the user may set the *-ENCODING* variables to any value of
(ext:make-encoding ...)
>   
It was the issue of what values the user can bind to *-ENCODING* vs an 
assumption
that CFFI was making previously. You addressed what I was really after.
> BTW, don't be fooled by the way that the encodings found as SYMBOL-VALUE in package CHARSET claim
:LINE-TERMINATOR :UNIX, even on MS-DOS systems.  The FFI and ext:convert-string-to/from-bytes never
performs a CRLF translation. Only the streams do, when talking to files, sockets or pipes (not string-streams).
>   
Thanks, that is good to keep in mind.

getting CFFI function signature

Hi,

I have CFFI bindings generated by SWIG, which look like

(cffi:defcfun ("cairo_line_to" cairo_line_to) :void
  (cr :pointer)
  (x :double)
  (y :double))

I would like to generate wrapper functions that would take the first
argument from a global variable and apply conversions for the rest.
The problem is that there are many functions, and I want to automate
this as much as possible.

Is there any way to get the signature of a function defined with
cffi:defcfun?  In this case, I need something like (:void cr :pointer
x :double y: double) (of course the syntax and the ordering can vary).
With this, I could automate the generation of wrappers.

Thanks,

Tamas

Re: getting CFFI function signature

On Sun, 2007-05-13 at 10:00 -0400, Tamas K Papp wrote:
> (cffi:defcfun ("cairo_line_to" cairo_line_to) :void
>   (cr :pointer)
>   (x :double)
>   (y :double))
> 
> I would like to generate wrapper functions that would take the first
> argument from a global variable and apply conversions for the rest.
> The problem is that there are many functions, and I want to automate
> this as much as possible.
> 
> Is there any way to get the signature of a function defined with
> cffi:defcfun?  In this case, I need something like (:void cr :pointer
> x :double y: double) (of course the syntax and the ordering can vary).
> With this, I could automate the generation of wrappers.

Sorry, this information is used in the macroexpansion, but not saved.
See src/functions.lisp.

If you're using SWIG's output unedited, there should be a pattern of
output.  In that case, you could pretty easily postprocess the output.

(defun wanted-signature-p (form)
  (and (eq (first form) 'cffi:defcfun)
       (cdddr form)
       (eq (second (fourth form)) :pointer)))

(defun save-signature (form)
  "Save CFFI:DEFCFUN signature in FORM."
  (destructuring-bind (macro-name (c-name lisp-name) &rest rettype-args)

Re: getting CFFI function signature

> I have CFFI bindings generated by SWIG, which look like

just a hint: by now verrazano generates much better bindings out of
the box then swig and it has a pregenerated cairo binding.

this won't solve your problem either, but if you are interested in
such a change, then verrazano could easily be extended to support
custom generators. yours would be the first though, so it would need
some refactoring in verrazano, but its internal state has all the info
that is needed.

hth,

--

-- 
 attila

[PATCH] emulating LONG-LONG on ECL

Attached there is a patch made against the main branch(not the newtypes
one) which adds :UNSIGNED-LONG-LONG and :LONG-LONG to ECL; to be more specific:

1) it adds a new feature: CFFI:EMULATED-LONG-LONG(not sure this is a
good name - see the callbacks issue below)
2) it calculates at compile time the machine endianess and pushes a new
feature, either :LITTLE-ENDIAN or :BIG-ENDIAN
3) %MEM-REF and %MEM-SET are renamed to %NATIVE-MEM-REF and
%NATIVE-MEM-SET while the new %MEM-REF and %MEM-SET dispatch on the
effective type using CANONICALIZE-FOREIGN-TYPE(which is
forward-referenced but it should be ok)
4) it adds compiler macros for %NATIVE-MEM-REF and %NATIVE-MEM-SET

this patch passes the DEREF.*LONG-LONG memory tests(which I ran manually
since ECL seems to have some problems in running the tests)

two are the problems I've encountered:
1) callbacks don't work since actually ECL doesn't have LONG-LONG. this
can be "fixed" by stating in the docs that on platforms where LONG-LONG
is emulated callback simply don't work.
2) although possibly not related to CFFI, when loading IOLIB-POSIX I got this: 
NIL is not of type REAL.
Broken at CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION.
IOLIB-POSIX>> :backtrace
Backtrace: CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION > eval

I'll investigate further this issue.

--

-- 
(sign :name "Stelian Ionescu" :aka "fe[nl]ix"

Re: [PATCH] emulating LONG-LONG on ECL

On Mon, May 14, 2007 at 06:28:13PM +0200, Stelian Ionescu wrote:
>Attached there is a patch made against the main branch(not the newtypes
>one) which adds :UNSIGNED-LONG-LONG and :LONG-LONG to ECL; to be more specific:
sorry, I forgot to actually *attach* the patch :(

-- 
(sign :name "Stelian Ionescu" :aka "fe[nl]ix"
      :quote "Quidquid latine dictum sit, altum videtur.")

diff -rN -u old-cffi/src/cffi-ecl.lisp new-cffi/src/cffi-ecl.lisp
--- old-cffi/src/cffi-ecl.lisp	2007-05-14 18:01:21.000000000 +0200
+++ new-cffi/src/cffi-ecl.lisp	2007-05-14 18:01:21.000000000 +0200
 <at>  <at>  -62,7 +62,7  <at>  <at> 
 (eval-when (:compile-toplevel :load-toplevel :execute)
   (mapc (lambda (feature) (pushnew feature *features*))
         '(;; Backend mis-features.
-          cffi-features:no-long-long
+          cffi-features:emulated-long-long
           cffi-features:flat-namespace
           ;; OS/CPU features.
           #+:darwin       cffi-features:darwin
 <at>  <at>  -74,6 +74,28  <at>  <at> 
           #+:powerpc7450  cffi-features:ppc32
           )))

+;; This is very ugly but since not all implementations put the
+;; machine endianess in *FEATURES* we need to do it ourselves
+(eval-when (:compile-toplevel :load-toplevel)
+  (flet ((memset1 (value ptr offset)

unicode

Hi,

What is the suggested method to pass unicode strings (const char*
pointing to an utf8 string) to C functions in CFFI?  I am using CMUCL.

Thanks,

Tamas

defcenum values not evaluated

Hi cffi-devel,
In the defcenum macro, the values don't seem to be evaluated. Is this
behavior a bug or a feature?

On clisp,

[4]> (cffi:defcenum test 
       (:a 1) 
       (:b (* 2 2)))

*** - The value of CFFI::VALUE should be of type INTEGER.
      The value is: (* 2 2)

thanks,
Lawrence Nakamura

Re: unicode

Tamas K Papp <tpapp <at> Princeton.EDU> writes:
> What is the suggested method to pass unicode strings (const char*
> pointing to an utf8 string) to C functions in CFFI?  I am using CMUCL.

The cffi-newtypes branch at <http://common-lisp.net/~loliveira/darcs/>
contains preliminary support for encodings.  You would use the type
(:string :encoding :utf-8).

However, CMUCL does not support unicode so you'd need to convert foreign
strings to vectors of either utf-8 octets or unicode code points, or you
could use something like Closure's Runes:
<http://common-lisp.net/cgi-bin/viewcvs.cgi/cxml/runes/?root=cxml>
In either case, you could write your own string type to deal with that.

Well, and you can deal with foreign pointers but I that might not be
particularly useful.

--

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/

Re: defcenum values not evaluated

"Lawrence Nakamura" <ln <at> imap.cc> writes:
> In the defcenum macro, the values don't seem to be evaluated. Is this
> behavior a bug or a feature?

I'm not sure.  What's your use case?  Would #. work there?

--

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/