Seo Sanghyeon | 15 Nov 20:45 2003
Picon

UFFI for CLISP

I started working on this, and current code is here:
http://sparcs.kaist.ac.kr/~tinuviel/clisp-uffi/

Wrote `load-foreign-library', 'def-function', and 'def-foreign-type'.
Basics working.

Does this look like a right way to go?
Kevin Rosenberg | 15 Nov 20:56 2003
Picon

Re: UFFI for CLISP

Seo Sanghyeon wrote:
> I started working on this, and current code is here:

Great -- I'd be glad to incorporate CLISP support in UFFI. However, I
currently don't have time to help develop this nor do I know anything
about the CLISP FFI. I'm glad to accept well-written patches which
don't break UFFI on other platforms.

> Does this look like a right way to go?

I took a quite look at this. The "right" way to go, in my opinion,
would be download the current UFFI code and make a copy of it. Work on
the copied code and submit a "diff" patch of your code compared to the
original UFFI code with a command like "diff -ur uffi.orig uffi".

--

-- 
Kevin Rosenberg
kevin@...
Vebjorn Ljosa | 18 Nov 20:17 2003

Bug in CONVERT-FROM-FOREIGN-STRING (patch included)

Hi,

I found a bug in CONVERT-FROM-FOREIGN-STRING.  When called with
:LOCALE :NONE, it would call FAST-NATIVE-TO-STRING, which determines
the length of the string with strlen(), even when :LENGTH and
:NULL-TERMINATED-P NIL were given as arguments to
CONVERT-FROM-FOREIGN-STRING:

    CL-USER 1 > (lisp-implementation-type)
    "LispWorks"

    CL-USER 2 > (lisp-implementation-version)
    "4.2.7"

    CL-USER 3 > (require :uffi)

    CL-USER 4 > (uffi:convert-to-foreign-string 
    (format nil "foo~Cbar~Cbaz" #\Null #\Null))
    #<Pointer to type (:UNSIGNED :CHAR) = #x08062068>

    CL-USER 5 > (uffi:convert-from-foreign-string * :null-terminated-p nil
    :length 11 :locale none)
    "foo"

I have attached a patch, which introduces LENGTH as a second argument
to FAST-NATIVE-TO-STRING.  LENGTH can be NIL, if which case the length
is determined by strlen() as before.  I have only tested it on
LispWorks; I would appreciate it if someone could verify that the
patch also works on Allegro CL.

(Continue reading)

Kevin Rosenberg | 18 Nov 21:11 2003
Picon

Re: Bug in CONVERT-FROM-FOREIGN-STRING (patch included)

Vebjorn Ljosa wrote:
> I have attached a patch, which introduces LENGTH as a second argument
> to FAST-NATIVE-TO-STRING.  LENGTH can be NIL, if which case the length
> is determined by strlen() as before.  I have only tested it on
> LispWorks; I would appreciate it if someone could verify that the
> patch also works on Allegro CL.

The patch works fine with AllegroCL, but I did have to remove the
comment characters on the type declaration. I've uploaded version
1.4.4 with this change.

Thanks.

--

-- 
Kevin Rosenberg
kevin@...
Vebjorn Ljosa | 18 Nov 21:29 2003

Re: Bug in CONVERT-FROM-FOREIGN-STRING (patch included)

* Kevin Rosenberg <kevin@...>
| Vebjorn Ljosa wrote:
| > I have attached a patch, which introduces LENGTH as a second argument
| > to FAST-NATIVE-TO-STRING.  LENGTH can be NIL, if which case the length
| > is determined by strlen() as before.  I have only tested it on
| > LispWorks; I would appreciate it if someone could verify that the
| > patch also works on Allegro CL.
| 
| The patch works fine with AllegroCL, but I did have to remove the
| comment characters on the type declaration.

Just so you know, LispWorks is not completely happy with that time
declaration.  During compilation, it gives the warning

    "Variable STR is declared type (SIMPLE-ARRAY (SIGNED-BYTE 8) (*)),
    but is bound to a value of type SIMPLE-STRING"

and if SAFETY is more than 0, it fails at runtime with an error like
the following:

    "In a call to SEQ::%SET-ACCESS-ARRAY: 102 is not of type BASE-CHAR."

When SAFETY is 0, it seems to work fine, however.  I guess this is the
only way to avoid CODE-CHAR?

| I've uploaded version
| 1.4.4 with this change.

Thanks!

(Continue reading)

Kevin Rosenberg | 18 Nov 21:31 2003
Picon

Re: Bug in CONVERT-FROM-FOREIGN-STRING (patch included)

Vebjorn Ljosa wrote:
> When SAFETY is 0, it seems to work fine, however.  I guess this is the
> only way to avoid CODE-CHAR?

Correct -- with safety 0 both AllegroCL and Lispworks "trusts" the
type definition so that code-char can be avoid.

--

-- 
Kevin Rosenberg
kevin@...

Gmane