>does this mean that CLISP will support UFFI-2 automatically?
Nope. 1. Somebody has to do a porting job.
2. Kevin Kosenberg and possibly others has to be convinced that =
something very close to CLISP is the perfect candidate for UFFIv2. For =
now, UFFIv2 is possibly not more than a word (trademark :-).
>>>>>(setq z (allocate-shallow '(c-array char 1000)))
>I get #(97 110 115 32 61 10 32 32 49 46 50 50 52 54 101 45 48 49 54 =
1. Oops, there's that difference between ffi:character and ffi:char...
2. you should have gotten 1000 signed bytes out of c-array, not the =
>> I don't understand why. No user of the other Lisps would write C
>to avoid FFI overhead you mention below.
From the Amiga POV, writing C code to interface to existing dynamic =
libraries is unacceptable. Similarly, I don't want to have to add C =
stubs to interface to existing shared libraries on UNIX or MS-Windows =
-- unless the addtional performance is beneficial. The idea is: the =
library, the Lisp system is there, just combine the two and run (no =
intermediate Makefiles, C compilation, link kits, separate memory =
images). I still know how to use CLISP extensions with just a unique =
>Do you think AFFI is more appropriate as the UFFI substrate?
I think I already said no in clisp-devel. I expressed the idea that =
AFFI *only* provides a low-level layer, on which lots of things (except =
callbacks) can be built (like any good low-level layer provides for =
BTW, how current are sf's mailing archives??
I recommend using the FFI for UFFI, and possibly enhance some issues =
(e.g. better variable-sized arrays support).
E.g. I recently thought that either FFI:ELEMENT or FFI:DEREF =
(preferably) could be extended to provide pointer arithmetic like in C: =
*(p+i). This way, one wouldn't have to dynamically construct a =
FOREIGN-VARIABLE object of the given `(C-ARRAY x ,size) type, just to =
extract some value.
I believe some of the people posting here could make use of this (I =
forgot whose posting lead me to come up with this idea).
(DEREF #<FOREIGN-VARIABLE (C-ptr char)> &optional signed-index)
Of course, people should know that block- or array-oriented operations =
are faster than their element by element counterpart.
One should work with c-string and c-array[-max] as much as possible, =
instead of dealing with individual characters.
Yet, here, for short arrays, the overhead of building up the =
foreign-variable object's C-type may outweight the inherent performance =
advantage. That's a very implementation dependent area: with compilers =
to native code, there wouldn't be much of a difference.
There are more than a dozen conceivable useful extensions to the FFI.
Another example would be the ability to convert part of a foreign =
array, possibly open-ended to and from Lisp. I already mentioned AFFI's =
MEM-READ/WRITE once. Something similar, based on #<FOREIGN-*> objects, =
could be added to FFI. Then people would continue to be able to use =
fast array operations, instead of elementwise using that DEREF =
One has to carefully choose. IMHO, something low-level (from an =
application POV) like any FFI is not suited for a hundred utility =
functions, which would all provide somehow similar functionality.
I can't remember where I had my notes about a page full of possible =