Barry Fishman | 4 Apr 2008 18:57
Picon
Favicon

CLISP no longer supports ffi::foreign-library-function

As of (From the CLISP src/Changelog):

2006-10-05  Sam Steingold  <sds <at> podval.org>

        merged LOOKUP-FOREIGN-FUNCTION & FOREIGN-LIBRARY-FUNCTION into
        FIND-FOREIGN-FUNCTION; LOOKUP-FOREIGN-VARIABLE &
        FOREIGN-LIBRARY-VARIABLE into FIND-FOREIGN-VARIABLE
        ...

This includes CVS releases starting with clisp-2.41.

FFI::FOREIGN-LIBRARY-FUNCTION and FFI::FOREIGN-LIBRARY-VARIABLE have
effectively been made legasy.

In the current CVS head (but not the last clisp-2.44.1 release) these
functions have quietly disappeared.  This causes problems with the CLISP
CVS head in cffi-clisp.lisp.

I'm not sure what version of CLISP need to be supported.  Should the
new FFI::FIND-FOREIGN-FUNCTION and FFI::FIND-FOREIGN-VARIABLE interface
now be used.
--

-- 
Barry Fishman
Luís Oliveira | 5 Apr 2008 03:59
Picon
Gravatar

Re: LispWorks 5.0/5.1 and LONG-LONG support

On Fri, Mar 28, 2008 at 5:37 AM, Chun Tian (binghe)
<binghe.lisp <at> gmail.com> wrote:
>  Though LispWorks cannot use a >=version like compile feature like those in
> Allegro, but since LW is very stable and its version grows very slowly
> (0.1/year ^_^), I think we can use #+(and lispworks-64bit (not
> lispworks5.0)) to mean "LispWorks 64-bit version >= 5.1"

183c193
< #+#.(cl:if (cl:find-symbol "FOREIGN-TYPED-AREF" "FLI") '(and) '(or))
---
> #+#.(cl:if (cl:find-symbol "FOREIGN-TYPED-AREF" "FLI") '(and lispworks-64bit (not lispworks5.0)) '(or))

IIUC, this would disable this optimization for all non-64bit
platforms. It seems easier to simply state that CFFI long-longs
require LW version 5.1 or greater on 64-bit platforms. Got any
objections against that?

--

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Luís Oliveira | 5 Apr 2008 05:18
Picon
Gravatar

Re: [cffi-devel] CLISP no longer supports ffi::foreign-library-function

On Fri, Apr 4, 2008 at 5:57 PM, Barry Fishman <barry_fishman <at> acm.org> wrote:
> As of (From the CLISP src/Changelog):
>
>  2006-10-05  Sam Steingold  <sds <at> podval.org>
>
>         merged LOOKUP-FOREIGN-FUNCTION & FOREIGN-LIBRARY-FUNCTION into
>         FIND-FOREIGN-FUNCTION; LOOKUP-FOREIGN-VARIABLE &
>         FOREIGN-LIBRARY-VARIABLE into FIND-FOREIGN-VARIABLE
>         ...
>
>  This includes CVS releases starting with clisp-2.41.
>
>  FFI::FOREIGN-LIBRARY-FUNCTION and FFI::FOREIGN-LIBRARY-VARIABLE have
>  effectively been made legasy.
>
>  In the current CVS head (but not the last clisp-2.44.1 release) these
>  functions have quietly disappeared.  This causes problems with the CLISP
>  CVS head in cffi-clisp.lisp.

The attached patch should fix that while maintaining backwards
compatibility. Unfortunately, CVS CLISP (my copy of the ChangeLog says
2008-03-25) dumps core on the callback tests. I'm using x86-64. Can
anyone reproduce this behaviour?

[1]> (asdf:oos 'asdf:test-op :cffi)
...
*** - handle_fault error2 ! address = 0x8 not in [0x333a9f000,0x333d4b160) !
SIGSEGV cannot be cured. Fault address = 0x8.
Permanently allocated: 161560 bytes.
Currently in use: 5352408 bytes.
(Continue reading)

Barry Fishman | 5 Apr 2008 16:46
Picon
Favicon

Re: CLISP no longer supports ffi::foreign-library-function

"Luís Oliveira" <luismbo <at> gmail.com> writes:
> On Fri, Apr 4, 2008 at 5:57 PM, Barry Fishman <barry_fishman <at> acm.org> wrote:
>>  In the current CVS head (but not the last clisp-2.44.1 release) these
>>  functions have quietly disappeared.  This causes problems with the CLISP
>>  CVS head in cffi-clisp.lisp.
>
> The attached patch should fix that while maintaining backwards
> compatibility.

Thank you.  My cl-opengl code now works.

>                Unfortunately, CVS CLISP (my copy of the ChangeLog says
> 2008-03-25) dumps core on the callback tests. I'm using x86-64. Can
> anyone reproduce this behaviour?
>
> [1]> (asdf:oos 'asdf:test-op :cffi)
> ...
> *** - handle_fault error2 ! address = 0x8 not in [0x333a9f000,0x333d4b160) !
> SIGSEGV cannot be cured. Fault address = 0x8.
> Permanently allocated: 161560 bytes.
> Currently in use: 5352408 bytes.
> Free space: 324432 bytes.
> Segmentation fault (core dumped)
>
> luis <at> haden:~$ clisp --version
> GNU CLISP 2.45 (2008-04-04) (built 3415563584) (memory 3415563829)
> Software: GNU C 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
> gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit
> -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O
> -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -x none -lreadline
(Continue reading)

Barry Fishman | 5 Apr 2008 17:05
Picon
Favicon

Re: CLISP no longer supports ffi::foreign-library-function

Oops, I left off the actual test result:

Test DEFCFUN.VARARGS.DOCSTRINGS failed
Form: (DOCUMENTATION 'SPRINTF 'FUNCTION)
Expected value: "sprintf docstring"
Actual value: NIL.

Also:

$ clisp -q -norc
[1]> (setf (documentation 'bozo 'function) "bozo docstring")
NIL
[2]> (documentation 'bozo 'function)
NIL
[3]> (defun foo (a b) "foo docstring" (+ a b))
FOO
[4]> (documentation 'foo 'function)
"foo docstring"
[5]> (setf (documentation 'foo 'function) "changed foo docstring")
"changed foo docstring"
[6]> (documentation 'foo 'function)
"changed foo docstring"
[7]>

--

-- 
Barry Fishman
Luís Oliveira | 5 Apr 2008 17:18
Picon
Gravatar

Re: CLISP no longer supports ffi::foreign-library-function

On Sat, Apr 5, 2008 at 4:05 PM, Barry Fishman <barry_fishman <at> acm.org> wrote:
[...]
>  Test DEFCFUN.VARARGS.DOCSTRINGS failed
[...]
>  $ clisp -q -norc
>  [1]> (setf (documentation 'bozo 'function) "bozo docstring")
>  NIL
>  [2]> (documentation 'bozo 'function)
>  NIL
[...]

Interesting, this is what makes this particular test fail though:

$ clisp -q -norc
[1]> (defmacro foo () "docstring" nil)
FOO
[2]> (documentation 'foo 'function)
"docstring"
[3]> (compile 'foo)
FOO ;
NIL ;
NIL
[4]> (documentation 'foo 'function)
NIL

--

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Luís Oliveira | 5 Apr 2008 17:46
Picon
Gravatar

Re: CLISP no longer supports ffi::foreign-library-function

On Sat, Apr 5, 2008 at 3:46 PM, Barry Fishman <barry_fishman <at> acm.org> wrote:
>  1 out of 219 total tests failed: DEFCFUN.VARARGS.DOCSTRINGS.
[...]
>  GNU CLISP 2.45 (2008-04-04) (built 3415900623) (memory 3415900915)
>  Software: GNU C 4.2.1 (SUSE Linux)

I tried again with the latest CLISP from CVS (2008-04-03) and GCC
4.2.1-5ubuntu4 and I still get a core dump when running the callback
tests.

--

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Chun Tian (binghe | 5 Apr 2008 17:51
Picon

Re: LispWorks 5.0/5.1 and LONG-LONG support

Hi,

> On Fri, Mar 28, 2008 at 5:37 AM, Chun Tian (binghe)
> <binghe.lisp <at> gmail.com> wrote:
>> Though LispWorks cannot use a >=version like compile feature like  
>> those in
>> Allegro, but since LW is very stable and its version grows very  
>> slowly
>> (0.1/year ^_^), I think we can use #+(and lispworks-64bit (not
>> lispworks5.0)) to mean "LispWorks 64-bit version >= 5.1"
>
> 183c193
> < #+#.(cl:if (cl:find-symbol "FOREIGN-TYPED-AREF" "FLI") '(and) '(or))
> ---
>> #+#.(cl:if (cl:find-symbol "FOREIGN-TYPED-AREF" "FLI") '(and  
>> lispworks-64bit (not lispworks5.0)) '(or))
>
> IIUC, this would disable this optimization for all non-64bit
> platforms. It seems easier to simply state that CFFI long-longs
> require LW version 5.1 or greater on 64-bit platforms. Got any
> objections against that?

I ... think CFFI should support LispWorks 5.0 for long-long, because  
5.0 (64-bit) do support it and not every 5.0 user can upgrade to 5.1  
(new license and money is required). And (I think) LispWorks will  
continue support 5.0 by release new patches in the future. For me, I'm  
using both 5.0 and 5.1 right now. Without long-long support, it is  
impossible to compile IOLIB on LispWorks 64-bit 5.0.

Since it's not hard to consider both versions, I (personal) hope you  
(Continue reading)

Luís Oliveira | 5 Apr 2008 19:39
Picon
Gravatar

Re: LispWorks 5.0/5.1 and LONG-LONG support

2008/4/5 Chun Tian (binghe) <binghe.lisp <at> gmail.com>:
>  I ... think CFFI should support LispWorks 5.0 for long-long
[...]
>  Since it's not hard to consider both versions, I (personal) hope you can
> support them both, and that will be perfect.

Can you test the attached patch (diffed against cffi+lotsastuff) and
see if it works for both LW 5.1 and 5.0? I only have the 32-bit
Personal Edition so I can't test long-long support myself.

By the way, foreign strings seem completely broken. Do the string
tests pass for you?

--

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
_______________________________________________
cffi-devel mailing list
cffi-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Barry Fishman | 5 Apr 2008 21:56
Picon
Favicon

Re: CLISP no longer supports ffi::foreign-library-function

"Luís Oliveira" <luismbo <at> gmail.com> writes:

> On Sat, Apr 5, 2008 at 3:46 PM, Barry Fishman <barry_fishman <at> acm.org> wrote:
>>  1 out of 219 total tests failed: DEFCFUN.VARARGS.DOCSTRINGS.
> [...]
>>  GNU CLISP 2.45 (2008-04-04) (built 3415900623) (memory 3415900915)
>>  Software: GNU C 4.2.1 (SUSE Linux)
>
> I tried again with the latest CLISP from CVS (2008-04-03) and GCC
> 4.2.1-5ubuntu4 and I still get a core dump when running the callback
> tests.

Luckly enough, my system dual boots to Ubuntu.

After bringing my stuff up to date, I tried building the latest CVS CLISP
there, and when I did a "make test" on CLISP, I got, on its callback test,
the message and core dump you had seen.

Then I remembered that another change in CLISP is to seperately package
the FFCALL interface.  Although Ubuntu comes with these libraries, they
don't seem to work.  I rebuild the libraries from the CVS repository:

  Repository:   :pserver:anonymous <at> cvs.sv.gnu.org:/sources/libffcall
  Root:         ffcall

After patching CLISP's make file to use the CVS version of these
libraries, everything worked fine.

--

-- 
Barry Fishman
(Continue reading)


Gmane