CFFI + gtkairo + sbcl 0.9.18

I'm not sure if this is really a CFFI issue or not, but when I'm trying
to use the gtkairo backend for McCLIM (which uses CFFI) I get the
following:

* (clim-demo::run-test 'clim-demo::demodemo)

debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread"
{B28F279}>:
  Trying to access undefined foreign variable "_gdk_error_warnings".

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(CFFI::FOREIGN-SYMBOL-POINTER-OR-LOSE "_gdk_error_warnings")
0]

Is this a CFFI issue?

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: CFFI + gtkairo + sbcl 0.9.18

Quoting C Y (smustudent1 <at> yahoo.com):
> I'm not sure if this is really a CFFI issue or not, but when I'm trying

Probably not.

[...]
>   Trying to access undefined foreign variable "_gdk_error_warnings".

Hmm, gtkairo should probably use the documented API function
gdk_error_trap_push() instead.  I'll look into it.

d.

Re: CFFI + gtkairo + sbcl 0.9.18

David Lichteblau wrote:
> Quoting C Y (smustudent1 <at> yahoo.com):
>> I'm not sure if this is really a CFFI issue or not, but when I'm trying
> 
> Probably not.
> 
> [...]
>>   Trying to access undefined foreign variable "_gdk_error_warnings".
> 
> Hmm, gtkairo should probably use the documented API function
> gdk_error_trap_push() instead.  I'll look into it.

The released version (McCLIM 0.9.3) works, so it's probably an McCLIM
issue introduced in cvs.  My bad.

CY

cmucl callback patch

Following patch lets cffi callbacks survive saving/loading a core on
CMUCL, tested on 19dpre2
(also works on 19c with (pushnew #'system::reinitialize-global-table
ext:*AFTER-SAVE-INITIALIZATIONS*)
not sure if that is something cffi should do for 19c or not though)

diff -rN -u old-cffi/src/cffi-cmucl.lisp new-cffi/src/cffi-cmucl.lisp
--- old-cffi/src/cffi-cmucl.lisp        2006-11-12 03:27:51.000000000 -0600
+++ new-cffi/src/cffi-cmucl.lisp        2006-11-12 03:27:51.000000000 -0600
 <at>  <at>  -320,6 +320,18  <at>  <at> 
       (error "Undefined callback: ~S" name))
     pointer))

+;;; cmucl makes new callback trampolines when it reloads, so we need to
+;;; update cffi's copies
+(defun reset-callbacks ()
+  (loop
+     for k being the hash-keys of *CALLBACKS*
+     do (setf (gethash k *callbacks*)
+              (alien::symbol-trampoline (cffi-sys::intern-callback k)))))
+
+;;; needs to be after cmucl's restore-callbacks, so put at the end...
+(setf ext:*after-save-initializations*
+      (append ext:*after-save-initializations* (list 'reset-callbacks)))
+
 ;;;# Loading and Closing Foreign Libraries

  ;;; Work-around for compiling ffi code without loading the

:string and external formats

Hi,

in the mailing list archives, I found some discussion of external format
support for :string types.

What is the recommended way to define a `utf8-string' type currently?
Do I have to write my own foreign type translator?

Thanks,
David

Re: :string and external formats

David Lichteblau wrote:
> in the mailing list archives, I found some discussion of external format
> support for :string types.

I have made support for external format of string (base on 
http://slacknet.com/~jamesjb/cffi-encoding/), but only for clisp/sbcl 
(but very pre-alpha and with some restrictions and reduction of 
functionality).

But I do not have time to complete it. I can send you the current variant.

--

-- 
WBR, Yaroslav Kavenchuk.

Re: cmucl callback patch

On 11/12/06, Bart Botta <00003b <at> gmail.com> wrote:
> Following patch lets cffi callbacks survive saving/loading a core on
> CMUCL, tested on 19dpre2
> (also works on 19c with (pushnew #'system::reinitialize-global-table
> ext:*AFTER-SAVE-INITIALIZATIONS*)
> not sure if that is something cffi should do for 19c or not though)

Works for me with "Snapshot 2006-09 (19C)" without pushing
#'system::reinitialize-global-table. I've applied your patch, thanks!

--

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/

New patches: 16-Nov-2006

Thu Nov 16 22:35:35 EST 2006  Luis Oliveira <loliveira <at> common-lisp.net>
  * Fix typo in strings.lisp

    M ./src/strings.lisp -1 +1
    M ./tests/bindings.lisp +1

Thu Nov 16 22:31:20 EST 2006  Luis Oliveira <loliveira <at> common-lisp.net>
  * New function: CFFI-SYS:NATIVE-NAMESTRING

  - Use it to load foreign libraries. Using plain CL:NAMESTRING was causing
    trouble with OpenMCL where (namestring #p"foo.bar.baz") returns
    "foo\\.bar.baz".

    M ./src/cffi-allegro.lisp +4
    M ./src/cffi-clisp.lisp +4
    M ./src/cffi-cmucl.lisp +4
    M ./src/cffi-corman.lisp +4
    M ./src/cffi-ecl.lisp +4
    M ./src/cffi-lispworks.lisp +4
    M ./src/cffi-openmcl.lisp +4
    M ./src/cffi-sbcl.lisp +4
    M ./src/cffi-scl.lisp +4
    M ./src/libraries.lisp -1 +1

Thu Nov 16 22:28:32 EST 2006  Luis Oliveira <loliveira <at> common-lisp.net>
  * CMUCL: pick up new callback trampolines after loading core

  Patch courtesy of Bart Botta.

Problems with ECL+CFFI

I have run into some problems with the cffi-061116 tarball and cvs ECL.
When trying to load the cffi-examples I get 'The variable  
CFFI-SYS::ARG-VALUES is unbound.' error. It looks like a typo(?) in  
cffi-ecl.lisp: PRODUCE-FUNCTION-POINTER-CALL.
After fixing that the examples compile fine but trying any of the them  
gives errors like '"gethostname" is not of type SI:FOREIGN-DATA.'

--------------------
T. Neste

Re: Problems with ECL+CFFI

2006/11/24, Tomi Neste <tomi.neste <at> netikka.fi>:
> I have run into some problems with the cffi-061116 tarball and cvs ECL.
> When trying to load the cffi-examples I get 'The variable
> CFFI-SYS::ARG-VALUES is unbound.' error. It looks like a typo(?) in
> cffi-ecl.lisp: PRODUCE-FUNCTION-POINTER-CALL.
> After fixing that the examples compile fine but trying any of the them
> gives errors like '"gethostname" is not of type SI:FOREIGN-DATA.'

There were two errors in the ecl backend which only appeared when
using the dynamically generated FFI. Attached to this email there are
fixes for CFFI in the form of patch file.

Juanjo

_______________________________________________
cffi-devel mailing list
cffi-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel