> * Hoehle, Joerg-Cyril <Wbret-Plevy.Ubruyr@...> [2004-02-26 18:42:08 +0100]:
> Sam wondered:
>>>>(setq z (allocate-shallow '(c-array char 1000)))
>>this is printed as #<FOREIGN-VARIABLE FOREIGN-ALLOCATE #x1012CEE8>
>>how do I extract the string?
> Using FFI:foreign-value
I get #(97 110 115 32 61 10 32 32 49 46 50 50 52 54 101 45 48 49 54 10)
convert-string-from-bytes gets me the string.
> If it's really a string, you probably want to use (c-array-max char
> 1000), or you'll get 1000 characters.
>>we need to write a C (not FFI) module to accomplish this.
> I don't understand why. No user of the other Lisps would write C
> code. Instead, they use thin or thick wrappers, dealing with foreign
> pointers and all in Lisp.
to avoid FFI overhead you mention below.
>>indeed. this makes it an imperative to offer a very low-level FFI layer
>>which would be suitable to port UFFI to CLISP.
> I already said that I believe that most of this is already available
> in CLISP. One can use c-pointer and ignore :out etc.
> Yet I don't know how CLISP goes along the UFFI design goal which says
> that performance of code using UFFI should be equivalent to the native
> stuff (ideally, all of UFFI is macro wrappers and goes away).
Do you think AFFI is more appropriate as the UFFI substrate?
> This is not the case with CLISP, where a complex DEF-CALL-OUT, where
> applicable, is more efficient than a series of WITH-FOREIGN-OBJECT
> etc. and C-POINTER manipulations that UFFI would translate to. CAST
> (run-time) is especially expensive.
This whole issue is actually very similar to the raw sockets, as being
discussed now on clisp-devel: high-level convenience vs. low-level
Some APIs, e.g., that of Netica, are very well thought through, and
easy to interface to using CLISP high-level macros.
Just like with TCP sockets, the high-level CLISP interface is perfect.
Some APIs, e.g., Matlab's, require low-level tweaking.
The fact of life is: some things are easier to express in assembly than
in C, some things are easier in C than in Lisp, some things are easier
with UFFI low-level macros than with CLISP FFI high-level declarations.
However few such things are, they do exist.
CLISP should offer low-level UFFI-style functionality.
> It would be much better if UFFI would adopt high-level declarations
> like CLISP does. Kevin Rosenberg said "UFFI Version 2" when I
> mentioned this in the uffi-users list.
does this mean that CLISP will support UFFI-2 automatically?
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
There is Truth, and its value is T. Or just non-NIL. So 0 is True!