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?
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@...
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)
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@...
* 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)
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@...
RSS Feed2 | |
|---|---|
3 | |
16 | |
3 | |
6 | |
18 | |
6 | |
2 | |
3 | |
20 | |
2 | |
6 | |
2 | |
4 | |
3 | |
4 | |
18 | |
11 |
