Debugging a Callback

what does 'deprecated' mean with respect to "bare structure types"?

good afternoon;

upon pulling and building with the current cffi version, one observes, that the elementary form of
references to structure types has fallen into disfavor and leads to a style warning, to the effect, that
such forms are "deprecated". that term might lead one to understand such a form to be ambiguous,
inconsistent or incompatible some introduced mechanism, or to be expected to impair future changes for
similar reason. when, however, one regards the related commentary in the usage documentation and
examines the code locations which concern the deprecation, it appears, that the semantics of the
elementary form is unambiguously known and supported in all contexts, that there is no indication of
impending changes which would change this situation, and that, given these circumstances, the
deprecation warning is gratuitous and can actually be ignored.

is this a true comprehension of the situation?

if i have overlooked or disregarded some key aspect of this change, please advise.

best regards, from berlin,

[PATCH] Fold (foreign-type-size <built-in-type>) to constants

Hi,

PZMQ uses (foreign-type-size) dynamically on built-in types in its
getsockopt functions, which is called on every recv-string message call.

Please apply the following short patch, it seems self-obviously correct.

Regards,
  Max

From c3f6ede805431eac6d96379691ab54a0a951d4f3 Mon Sep 17 00:00:00 2001
From: Max Mikhanosha <max <at> openchat.com>
Date: Thu, 23 May 2013 21:50:58 -0400
Subject: [PATCH] Fold (foreign-type-size <built-in-type>) to constants

---
 src/types.lisp | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/src/types.lisp b/src/types.lisp
index 582a94d..ea5a020 100644
--- a/src/types.lisp
+++ b/src/types.lisp
 <at>  <at>  -1009,3 +1009,12  <at>  <at>  (defctype :ullong :unsigned-long-long)
                   (:uintptr . :pointer))
                  (:unsigned-char :unsigned-short :unsigned-int :unsigned-long
                   :unsigned-long-long))))
+
+;; Fold foreign-type-size on built-in types to constants
+(define-compiler-macro foreign-type-size (&whole form type)
+  (if (constantp type)
+      (let ((type (eval type)))
+        (if (member type *built-in-foreign-types*)
+            (%foreign-type-size type)
+            form))
+      form))
--

-- 
1.7.11.rc0.100.g5498c5f

Mailing list Issues

The references to the cffi-devel mailing list on the web page are broken.

I had disabled receiving mail from the list.  However, I have suddenly
started receiving mail from the list.  How do I stop it?

--

-- 
Barry Fishman

Groveler and HUGE_VAL

Problems with nested structs and the newer cffi

I am encountering some problems with trying to upgrade my old cffi code
to the new version from quicklisp.  
If I use the old code, I get lots of warnings about my structs, that I
should use either (:struct ...) or (:pointer (:struct ...))

However whateer I try, I do not seem to get it to work, and I am
starting to think there is some issue between me and the new cffi.

The main issue is a nested struct definition like this:

```
(defcstruct timeval
  (time %time)
  (offset :int))

(defcstruct (git-signature)
  (name :string)
  (email :string)
  (time (:struct timeval)))
```

With type definitions

```
(define-foreign-type time-type ()
  nil
  (:actual-type :int64)
  (:simple-parser %time))

(define-foreign-type git-signature-type ()
  nil
  (:actual-type :pointer)
  (:simple-parser %git-signature))
```

I encounter problems when I am trying to update the 
`translate-to-foreign` for the `git-signature-type`.
The implementation boils down to:

```
(defmethod translate-to-foreign ((value list) (type git-signature-type))
  (let ((signature (foreign-alloc '(:struct git-signature))))
    (with-foreign-slots ((name email time) signature (:struct git-signature))
      (setf name (getf value :name (getenv "USER")))
      (setf email (getf value :email (default-email)))
      (with-foreign-slots ((time offset) time (:struct timeval))
        (let ((time-to-set (getf value :time (local-time:now))))
          (setf time time-to-set)
          (setf offset (/ (local-time:timestamp-subtimezone
                           time-to-set local-time:*default-timezone*)
                          60)))))
    signature)
```

The problem is in the inner `with-foreign-slots ((time offset)...`.

The error I get is:

; Evaluation aborted on #<TYPE-ERROR expected-type: SYSTEM-AREA-POINTER
             datum: (CL-GIT::OFFSET 0 TIME  <at> 1970-01-01T01:00:03.000000+01:00)>.

The reason is, as far as I can tell, that in the code:

    (with-foreign-slots ((time offset) time (:struct timeval)) ...

the value of `time` is already a plist (due to the outer
with-foreign-slots), and the inner with-foreign-slots expects a pointer.

So what is the best way of fixing this?  I can fix this by replacing
the inner `with-foreign-slots` by

```
      (with-foreign-slots ((time offset) 
			   (foreign-slot-pointer signature '(:struct git-signature) 'time) 
			   (:struct timeval))
```
which seems a bit long.

An additional question is, when to use (:struct ...) and when to use 
(:pointer (:struct ..)))

I did expect that I needed to use (:pointer (:struct ..)) 
in the toplevel `with-foreign-slots`, because the argument is actually
a pointer to the struct.  But that did not work.

As you can tell, I am a bit confused.  
Hope that someone can give some hints to clear my head.

Kind regards,
Wim Oudshoorn.

Error on web page

Under "Getting Started", the home page now says.

The latest version is , released on (release notes).

Liam

cff-tests doesn't load (can't build libffi.so ?)

Hello.

(ql:quickload :cffi-tests) doesn't work in the latest quicklisp - 2013-03-12, cffi 0.11.0.
It worked in the previous quicklisp.

Best regards,
- Anton

version 0.11.1 released

bugfix: the ABCL backend now loads the required contribs properly.
bugfix: some callback bugs were fixed in the ACBL backend. (Thanks to
Mark Evenson.)
bugfix: the groveller was failing to regenerate its lisp files
whenever a grovel- or wrapper-file was modified.

--
Luís Oliveira
http://r42.eu/~luis/

Re: preparing to test ABCL trunk

On 4/2/13 10:58 PM, Luís Oliveira wrote:
> On Tue, Apr 2, 2013 at 1:43 PM, Mark Evenson <evenson <at> panix.com> wrote:
>> Yes, it fixes this problem.
>>
>> I thought I had already sent you a message confirming that this change
>> should be applied:  sorry if that didn't happen.
> 
> Grabbed ABCL 1.1.1 to test before preparing a bugfix release for CFFI
> but I'm seeing a bunch of failures related to callbacks. Were you
> aware of these failures? Should I delay the release so we (hopefully
> you!) can look at these failures?
> 
> 29 unexpected failures: CALLBACKS.CHAR, CALLBACKS.UNSIGNED-CHAR,
>    CALLBACKS.SHORT, CALLBACKS.UNSIGNED-SHORT, CALLBACKS.LONG,
>    CALLBACKS.UNSIGNED-LONG, CALLBACKS.LONG-LONG,
>    CALLBACKS.UNSIGNED-LONG-LONG, CALLBACKS.POINTER,
>    CALLBACKS.NIL-FOR-NULL, FOREIGN-GLOBALS.NAMESPACE.1,
>    FOREIGN-GLOBALS.NAMESPACE.2, FOREIGN-GLOBALS.NAMESPACE.4,
>    MAKE-POINTER.HIGH, FOREIGN-ALLOC.1, FOREIGN-ALLOC.2, FOREIGN-ALLOC.3,
>    FOREIGN-ALLOC.4, FOREIGN-ALLOC.6, FOREIGN-ALLOC.8, FOREIGN-ALLOC.9,
>    NULL-POINTER-P.NON-POINTER.1, NULL-POINTER-P.NON-POINTER.2,
>    NULL-POINTER-P.NON-POINTER.3,
>    STRUCT-VALUES-DEFAULT.TRANSLATION.MEM-REF.1,
>    STRUCT-VALUES-DEFAULT.TRANSLATION.MEM-REF.2, FSBV.2, FSBV.3, FSBV.4.
> 

I've [just submitted all that I have at the moment to address these
issues][24], which isn't much.  Unfortunately, last week has been a week
of fever and so forth, so when I am going to be able to work on these
things again is uncertain.  Therefore, I would advise releasing a minor
revision of CFFI with this and Stellian's work to go with Quicklisp
April 2013.

[24]: https://github.com/cffi/cffi/pull/24

Some of the FOREIGN-GLOBALS* tests appear to pass on some platforms and
not others.

Callbacks with pointers seem to just not work, for which I [posted a
test case in Java][1], but got a less than clear response.  When I get
healthy again, I will revisit more pure-Java examples to understand
exactly how JNA is supposed to be working.

[1]:
https://groups.google.com/forum/?fromgroups=#!topic/jna-users/qPUkrTqoesU

close-foreign-library assert

Hello again!

I am working on a project which used to be completely in C++, now i am  
gradually moving some of it to CL. For this reason i need to work on both  
sides, which requires me to reload cffi bindings too often. I couldn't  
find anything related to this in documentation. Probably this is not an  
intended use case so there is no support. Which means i need to use my  
hammer again, restart image :)

So, i started playing with load-foreign-library/close-foreign-library  
(probably not intended for this purpose) and whenever i call  
close-foreign-library with the result of load-foreign-library, i get this  
explosion:

Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion  
`map->l_init_called' failed!

Tracing this assert shows it was triggered from dlclose system call in  
sbcl source, and i am not entirely sure where i should report this bug.

I am still on archlinux using sbcl-git package from aur. Could it be  
another archlinux related bug?

Thanks.