Subject: [clisp-list] Re: array of strings?

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Thu Feb 26 09:53:01 2004

Hi,

Sam wondered:
>>>(setq z (allocate-shallow '(c-array char 1000)))
>> ok
>
>this is printed as #<FOREIGN-VARIABLE FOREIGN-ALLOCATE #x1012CEE8>
>how do I extract the string?
Using FFI:foreign-value

If it's really a string, you probably want to use (c-array-max char 1000), or you'll get 1000 characters.

>nevertheless, (engOutputBuffer ep NIL 0) returns 1 (error code!)
No idea why.

>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.

>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). 
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.

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.

>indeed, this works.
Great!

Regards,
	Jorg Hohle.

---

From: Sam Steingold <[email-masked]>
Date: Thu Feb 26 10:59:10 2004

> * Hoehle, Joerg-Cyril <[email-masked]> [2004-02-26 18:42:08 +0100]:
>
> Sam wondered:

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.
yuk.

> 1000), or you'll get 1000 characters.
thanks.

> 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.

> 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
flexibility.

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/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
There is Truth, and its value is T.  Or just non-NIL.  So 0 is True!