Attila Lendvai | 18 Apr 17:29 2016

added a wiki page for cffi/c-stdlib system

https://github.com/cffi/cffi/wiki/Proposal-for-a-CFFI-C-STDLIB-system

--

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Have the courage to take your own thoughts seriously, for they will shape you.”
	— Albert Einstein (1879–1955)

Mirko Vukovic | 7 Apr 19:10 2016
Picon

How to define the interface to "const char *"

This is on Windows 7, CCL, latest CFFI pull.

I am writing an interface to a function that has a const char * as in input:

int DDC_GetFileStringPropertyLength (DDCFileHandle file, const char       *property, unsigned int *length);

In my defcfun, can I use :string, or do I need to do something special?

The reason I ask is that calls to this function cause a memory exception on one of my computers, while it works fine on the second computer.

Thanks,

Mirko
Mirko Vukovic | 7 Apr 05:13 2016
Picon

proposed fixes for cffi-libffi on Windows7+MSYS

So, after a long hiatus I updated CFFI, only to see dreaded compilation errors pop-up.  Nothing better to keep me awake for an extra hour.

The two patches (in the attached file) fix the error that I see and improve the code slightly.

One patch removes ^M that CCL sees at the end of output of pkg-config.

The need for the second patch arises in the case when the package loading fails, and I try to load it again.  In that case *cc-flags* gets loaded with duplicate entries.

This patch removes the duplicates.

I generated the patches with the command:
git format-patch master --stdout > mv-mods.txt

If there is a better way to submit patches, let me know how and I will resend.

Thanks,

Mirko


From 2d4408e394edba0741972d46225d13b14a6f237f Mon Sep 17 00:00:00 2001
From: Mirko Vukovic <mirko.vukovic <at> gmail.com>
Date: Wed, 6 Apr 2016 22:40:30 -0400
Subject: [PATCH 1/2] parse-command-flags: Added #\Return to separators

On Windows7+MSYS, the output of pkg-config as read by CCL included
\#RETURN.

I added #\Return the bag of separators.  I also reformatted the code a
bit, to make it a bit more readable (fewer long lines or ackward line
splits).
---
 toolchain/c-toolchain.lisp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/toolchain/c-toolchain.lisp b/toolchain/c-toolchain.lisp
index 8645c3b..9c6758c 100644
--- a/toolchain/c-toolchain.lisp
+++ b/toolchain/c-toolchain.lisp
 <at>  <at>  -33,7 +33,8  <at>  <at> 
 ;;; Utils

 (defun parse-command-flags (flags)
-  (remove-if 'emptyp (split-string flags :separator '(#\Space #\Tab #\Newline))))
+  (let ((separators '(#\Space #\Tab #\Newline #\Return)))
+    (remove-if 'emptyp (split-string flags :separator separators))))

 (defun parse-command-flags-list (strings)
   (loop for flags in strings append (parse-command-flags flags)))
-- 
2.6.3

From e687880d3ac5238dff7d9b78d70490265079a4a1 Mon Sep 17 00:00:00 2001
From: Mirko Vukovic <mirko.vukovic <at> gmail.com>
Date: Wed, 6 Apr 2016 22:57:40 -0400
Subject: [PATCH 2/2] Remove duplicates in *cc-flags*

`define-grovel-syntax pkg-config-cflags' would add the same paths even
if they were already in *cc-flags*.

The modified code appends the new flags, and then removes the
duplicates.  The new flags are placed at the end of *cc-flags*
---
 grovel/grovel.lisp | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/grovel/grovel.lisp b/grovel/grovel.lisp
index 9240685..2b73c72 100644
--- a/grovel/grovel.lisp
+++ b/grovel/grovel.lisp
 <at>  <at>  -281,8 +281,13  <at>  <at>  int main(int argc, char**argv) {
           (run-program program+args
                        :output (make-broadcast-stream output-stream *debug-io*)
                        :error-output output-stream)
-          (appendf *cc-flags*
-                   (parse-command-flags (get-output-stream-string output-stream))))
+          (setf *cc-flags* 
+                (nreverse 
+                 (remove-duplicates 
+                  (append (parse-command-flags 
+                           (get-output-stream-string output-stream))
+                          (nreverse *cc-flags*))
+                  :test #'string=))))
       (error (e)
         (let ((message (format nil "~a~&~%~a~&"
                                e (get-output-stream-string output-stream))))
--

-- 
2.6.3

Martin Kielhorn | 16 Mar 12:47 2016
Picon

Quicklisp CFFI doesn't load on Raspberry PI

Hi,
I tried to load cffi that comes with Quicklisp on SBCL 1.3.2 on a Raspberry PI 2.

I had to comment out FFI_UNIX64

(cenum abi
 ((:default-abi "FFI_DEFAULT_ABI"))
 ((:sysv "FFI_SYSV"))
 #+nil ((:unix64 "FFI_UNIX64"))
)


in the file quicklisp/dists/quicklisp/software/cffi_0.16.1/libffi/libffi-unix.lisp
to make it load.


Regards, Martin

Chris Bagley | 13 Mar 18:35 2016
Picon

expand-into-foreign-memory query

Hi all,

I am working on a project where I believe the overhead of the call to
translate-into-foreign-memory is starting to be an issue & as such I'm
looking into implementing expand-into-foreign-memory.

Before starting on this I thought I would ask if this feature would be
welcome in cffi and also if there are any fundamental reasons this
would not work.

So far I have been reading the source for expand-from-foreign and
expand-to-foreign and it seems that expand-into-foreign-memory would
be fairly similar. Also from the comments in mem-set it looks like this
feature was intended at some point.

As ever thankyou for the awesome work on this project and I hope I can
give something back to it soon.

Cheers,
Baggers

Luís Oliveira | 12 Mar 14:45 2016
Picon
Gravatar

CFFI 0.17.1 released

Hello,

We've just released CFFI 0.17.1!
https://github.com/cffi/cffi/wiki/NEWS#version-0171

Cheers,

--

-- 
Luís Oliveira
http://kerno.org/~luis/

Luís Oliveira | 24 Feb 20:35 2016
Picon
Gravatar

Re: defcenum with non-integer base-type

On Wed, Feb 24, 2016 at 7:29 PM, Attila Lendvai <attila <at> lendvai.name> wrote:
> some projects out in the wild use DEFCENUM with e.g. :DOUBLE
> base-type. this is not in adherence with the C standard (only integer
> types are valid enum types, and it's at least int sized). my
> refactoring of enums introduced an explicit check for this, and it
> broke some projects in ql. to alleviate that i've commented out this
> new check in master.
>
> the question:
>
> should we roll with this? does anyone see any problems or potentially
> surprising behavior? e.g. with the semantics of the enum increments
> and the double base type? or something else?

It sounds a bit silly at first, but from CFFI's point of view, a
DEFCENUM is really just a mapping between symbols and... something
else.

What would we gain from being a bit more draconian about the base type?

--

-- 
Luís Oliveira
http://kerno.org/~luis/

Attila Lendvai | 24 Feb 20:29 2016

defcenum with non-integer base-type

the situation:

some projects out in the wild use DEFCENUM with e.g. :DOUBLE
base-type. this is not in adherence with the C standard (only integer
types are valid enum types, and it's at least int sized). my
refactoring of enums introduced an explicit check for this, and it
broke some projects in ql. to alleviate that i've commented out this
new check in master.

the question:

should we roll with this? does anyone see any problems or potentially
surprising behavior? e.g. with the semantics of the enum increments
and the double base type? or something else?

--

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“There is nothing sacrosanct about the majority; the lynch mob, too,
is the majority in its own domain.”
	— Murray N. Rothbard (1926–1995), 'For a New Liberty' (1973)

Attila Lendvai | 24 Feb 20:10 2016

CFFI govels size_t into :sizet [Was: cffi 0.17.0 breaks some stuff]

> I'm seeing a bunch of projects that don't seem to work with the latest CFFI
> release. For example, I get this for a number of projects:
>
> Unhandled CFFI::UNDEFINED-FOREIGN-TYPE-ERROR in thread #<SB-THREAD:THREAD
> "main thread" RUNNING {1003DD5643}>: Unknown CFFI type :SIZET
>
> That happens in gsll and some other projects.

the situation:

cffi-libffi used to grovel size_t under the name :sizet, and it's used
by a few projects, e.g. gsll, which got broken.

i deleted :sizet in this cleanup:
https://github.com/cffi/cffi/commit/4fbe5864552d6f7d8866745f371346174acea942

i've reinstated it temporarily with an OBSOLETE warning just now.

reasons for the removal:

 - for me it seems pretty ad-hoc why this one definition is included
   and the other C stdlib definitions are not.

 - if we want to include and support size_t in the CFFI contract, then
   why in cffi-libffi? keep in mind that it requires groveling, which
   is quite a heavy dependency that CFFI proper doesn't require at
   this point.

 - why in the keyword package? (and it's another discussion why :int
   and other standard C definitions (not to be confused with stdlib.h)
   are in the keyword package, but i won't pursuit that argument at
   this point in time)

maybe we want to open a new ASDF system for the C stdlib that would
depend on the groveler and accommodate for C stdlib definitions like
errno, size_t, etc?

--

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Nationalism of one kind or another was the cause of most of the
genocide of the twentieth century. Flags are bits of colored cloth
that governments use first to shrink-wrap people's brains and then as
ceremonial shrouds to bury the dead.”
— Arundhati Roy (1961–), 'Come September' speech

Zach Beane | 24 Feb 15:38 2016
Gravatar

cffi 0.17.0 breaks some stuff

Hi,

I'm seeing a bunch of projects that don't seem to work with the latest CFFI release. For example, I get this for a number of projects:

Unhandled CFFI::UNDEFINED-FOREIGN-TYPE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {1003DD5643}>: Unknown CFFI type :SIZET

That happens in gsll and some other projects.

cl-gtk2 has this:

Unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {1003DD5663}>: NIL is not a valid symbol for bitfield type #<CFFI::FOREIGN-BITFIELD GOBJECT.FFI:G-TYPE-FLAGS>.

There are other problems in cl-glu.


Not all of the problems in the report are directly cffi-related, but many of them are.

Zach

Attila Lendvai | 16 Feb 00:53 2016

release policy and quicklisp

the situation:

hu.dwim.sdl depends on the new cffi/c2ffi stuff, and it's needed for
projectured. to make playing with projectured simple, in its readme
and its build.sh we rely on ql.

ql takes its snapshot of CFFI from the CFFI release tgz, so
hu.dwim.sdl cannot be added to the next ql release.

my goals:

have a shorter "release" cycle when it comes to ql snapshots.

my proposal:

set up a branch called 'quicklisp' in the CFFI repo and change ql to
capture that instead of the release tgz. this is what VCS'es are
designed for after all.

sidenote:

i think in the long run it would be better to use a moving tag for
this, but for now the ql infrastructure doesn't support that for git
repos. unfortunately git doesn't handle well when history is
overwritten with a push -f on the remote side, but tags don't have
that problem (git fetch --tags readily overwrites local tags with the
remote ones).

a small glitch in this almost ideal release management scheme is that
git overwrites tags as opposed to keeping a stack of them and thus
doesn't presere their history.

--

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“You are what you do, not what you say you’ll do.”
	— Carl Jung (1875–1961)


Gmane