gmane.lisp.cffi.devel

Re: problem with include-path in cffi-grovel on windows

Luís Oliveira — 2012-05-19T14:18:50

On Sat, May 19, 2012 at 11:49 AM, Karl Heinrichmeyer
<karl< at >gudrun-heinrichmeyer.de> wrote:

I believe the canonical repository is at
<https://github.com/edicl/cl-fad>. Check out
<http://weitz.de/patches.html>.

Cheers,

Re: problem with include-path in cffi-grovel on windows

Karl Heinrichmeyer — 2012-05-19T10:49:02

Hello Luís,

Am 16.05.2012 01:37, schrieb Luís Oliveira:
I wrote a new patch that uses only make-pathname and attached it to the 
bug report. It seems to fix the problem with the pathnames when trying 
to load osicat (although the loading still fails later on  ...) .

I'll also write a report to the osicat mailing list as soon as i find 
the time to investigate the problem on windows a little further (I kind 
of gave up on development on Windows in the meantime :) )
It would be great if my library could be integrated in one of those, 
preferably cl-fad.  I read that you maintain a darcs repository for it? 
Or should I ask Edi Weitz to include it?

Best regards,

Karl

cffi-libffi funcall path and :string

Ryan Pavlik — 2012-05-18T17:19:30

For functions using the libffi foreign-funcall path, functions defined
with :string parameters still fail because
TRANSLATE-INTO-FOREIGN-MEMORY is not defined on
FOREIGN-STRING-TYPE.  E.g.,

(defcfun ("xcb_intern_atom" xcb-intern-atom) (:struct xcb-intern-atom-cookie-t)
  (c :pointer)
  (only_if_exists :unsigned-char)
  (name_len :unsigned-short)
  (name :string))

Calling this fails:

There is no applicable method for the generic function
  #<STANDARD-GENERIC-FUNCTION TRANSLATE-INTO-FOREIGN-MEMORY (5)>
when called with arguments
  (#.(SB-SYS:INT-SAP #X7FFFD8000DC0)
   #<CFFI::FOREIGN-STRING-TYPE :UTF-8>
   #.(SB-SYS:INT-SAP #X7FFFECDB7FD8)).
   [Condition of type SIMPLE-ERROR]

This is using unmodified master.

Re: problem with include-path in cffi-grovel on windows

Luís Oliveira — 2012-05-15T23:37:41

Hello Karl,

On Wed, Apr 18, 2012 at 7:04 PM, Karl Heinrichmeyer
<karl< at >gudrun-heinrichmeyer.de> wrote:

Thanks for the bug report. I agree with Greg that simply using plain
make-pathname thus not adding an extra dependency would be better. Can
you rewrite the patch taking that into consideration?

Re: osicat being broken, could you report that to the osicat mailing list?

Re: testing cffi-grovel on window, Osicat is probably your best bet.
If that fails, writing a simple test and adding to cffi-tests would be
nice.

Finally, your library does seem useful. Perhaps it could be integrated
into CL-FAD and/or Osicat?

Cheers,

Re: Round trips through parse-type, unparse-type

Luís Oliveira — 2012-05-11T07:15:47

Right, I think it would make sense for struct slots to be parsed. I
suspect that they aren't because that code predates the concept of
parsed types in CFFI, hence the FIXME.

In practice this is not a performance issue because the compiler macro
for foreign-struct-slot wil perform parsing at compile-time. Also, the
current scheme lets us pass the unparsed type to mem-ref directly. If
the type were to be parsed, we'd need a version of mem-ref that
accepts a parsed type. Shouldn't be too hard, I suppose.

Re: Round trips through parse-type, unparse-type

Liam Healy — 2012-05-11T03:38:17


Ah, OK, not round trips, forget what I said about unparse-type.  My sense
is there's repeated reparsing.  If a type was always parsed when read, and
the parsed form is stored, would that save some reparsing?   So the type
slot in foreign-struct-slot would not need to be parsed each time it's used.

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

Re: Round trips through parse-type, unparse-type

Luís Oliveira — 2012-05-06T10:13:07

What makes you say there are a lot round-trips through parse- and
unparse-type? Grepping the source we code, we can find two usages of
unparse-type: (1) the make-load-form method for foreign-type and (2)
some foreign-array-type code.

(2) shouldn't be there and it's got a FIXME nearby. (1) is why
unparse-type was introduced. Instances of foreign-type can end up in
fasls after various macros and compiler macros kick in and so we need
a way to serialize them.

Cheers,

Round trips through parse-type, unparse-type

Liam Healy — 2012-05-05T15:40:17

I just pushed fixes to make the FSBV tests pass.  One fix was to the
recursive call to libffi-type-pointer that took the slot-type directly,
already unparsed, and tried to unparse it.   I fixed that by parsing it
again.  In the course of debugging this, I found this comment in defclass
foreign-struct-slot
 ;; FIXME: the type should probably be parsed?
I briefly investigated doing this, and decided to take the expedient route
for now.

However, this comment got me to thinking that there are a lot of
(unnecessary) round trips through parse-type/unparse-type.  It seems to me
that they could be eliminated or reduced.  Perhaps as a design philosophy,
we should only have parsed types internally, and then we won't need
unparse-type at all?   Changing this would be a lot of work, I realize.

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

Re: Cannot load cffi-tests

Luís Oliveira — 2012-05-04T13:47:21

Yes, the Makefile attempts to cross-compile a 32-bit version. However,
it should be optional. And in fact, as you can see in the error
message, make ignores the failure to compile libtest32.so. I've pushed
a fix to make it do the same for libtest2_32.so and libfsbv_32.so.

Cheers,

Re: Cannot load cffi-tests

Liam Healy — 2012-05-04T13:02:15


Thanks Luis.

 This is SBCL 1.0.53.76-0dda509, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
CL-USER(1): (asdf:load-system :cffi-tests :verbose t)

; Loading system definition from
/home/healy/languages/lisp/cffi/cffi-tests.asd
; into #<PACKAGE "ASDF0">
; Registering #<SYSTEM "cffi-tests">
; Loading system definition from
;
/home/healy/languages/lisp/quicklisp/dists/quicklisp/software/rt-20101006-git/rt.asd
; into #<PACKAGE "ASDF0">
; Registering #<SYSTEM "rt">
; Loading system definition from
;
/home/healy/languages/lisp/quicklisp/dists/quicklisp/software/bordeaux-threads-0.8.1/bordeaux-threads.asd
; into #<PACKAGE "ASDF0">
; Registering #<SYSTEM "bordeaux-threads">
; Loading system definition from /home/healy/langu

Re: Cannot load cffi-tests

Luís Oliveira — 2012-05-04T09:03:45

(asdf:load-system :cffi-tests :verbose t) should give you more
information. Alternatively, cd into to tests/ and run make.

Cheers,


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

Cannot load cffi-tests

Liam Healy — 2012-05-04T03:01:45

I cannot load cffi-tests (from the master branch).  I am on Ubuntu 11.10
amd64.  I can't even make sense of what the error is; it can't compile
libtest.c?

Liam

This is SBCL 1.0.51.34-43a5265, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
CL-USER(1): (ql:quickload "cffi-tests")
To load "cffi-tests":
  Load 1 ASDF system:
    cffi-tests
; Loading "cffi-tests"
..................................................
[package cffi-features]
debugger invoked on a ASDF:OPERATION-ERROR in thread #<THREAD
                                                       "initial thread"
RUNNING
                                                        {1002F81371}>:
  Error while invoking #<COMPILE-OP (:VERBOSE NIL) {1003900621}> on
  #<C-TEST

Re: Next release of CFFI with cffi-libffi

Luís Oliveira — 2012-05-01T21:04:14

Let's target the June dist. (Perhaps July if too many bugs crop up.)

Re: Recent library breakage

Luís Oliveira — 2012-05-01T21:00:17

Thanks for the extra information. I digged a little deeper a found two things:

  1. CFFI was indeed not signalling this warning for types defined via
DEFCSTRUCT until very recently. This was a bug.

  2. the 0.10.7.1 release tarball had the wrong contents! (release.sh
unconditionally archives from the master branch. doh!) I've rebuilt
that tarball. Please grab it again and pardon my fumbling...

Cheers,

Re: Next release of CFFI with cffi-libffi

Liam Healy — 2012-05-01T20:29:33



I assume this question was about the fix to master, i.e., including
cffi-libffi.  I hope that pretty soon (with errors confirmed fixed) this
will be tagged as a new release (1.0.0) and QL will pick it up on the next
cycle.

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

Re: Recent library breakage

Liam Healy — 2012-05-01T20:24:48


That mystified me as well.  There is one other system in quicklisp from the
same source (this is "middleangle" isn't it?), I think blapack, that gave
the same error.  I don't understand why this doesn't occur under older
versions of CFFI, like 0.10.6.

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

Re: Recent library breakage

Zach Beane — 2012-05-01T20:20:19


For what it's worth, I don't get any warning in 0.10.6, and that's the
latest one in Quicklisp.

Zach

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

Re: Recent library breakage

Luís Oliveira — 2012-05-01T20:09:42

The fix should be straightforward. fnv should rename its
:complex-double type to something like fnv::complex-double. I don't
have an explanation how this could be a new warning, since it has been
in CFFI for 5+ years.

Cheers,

Re: Recent library breakage

Stelian Ionescu — 2012-05-01T19:59:52

I sent a merge request to the author. IMO it should be deprecated
because static-vectors does everything fnv does, but better

Recent library breakage

Zach Beane — 2012-05-01T19:18:30

fnv (from git://github.com/blindglobe/fnv.git) used to build, but as of
today I get this full warning:

    ; caught WARNING: 
    ;   Defining a foreign type named :COMPLEX-DOUBLE.  This symbol
    ;   belongs to the KEYWORD package and that may interfere with other
    ;   code using CFFI.

I'm using CFFI 0.10.7.1 on SBCL.

What should be done to fix it? 

Thanks,
Zach

Re: Next release of CFFI with cffi-libffi

Luís Oliveira — 2012-05-01T11:13:25

The latest release does not contain any of this new support for
structures as values, so it shouldn't be an issue.