- cffi-devel - mailman3.common-lisp.net

[Cffi-devel] cffi idioms: with-foreign-pointer
by Mirko Vukovic 16 Feb '15

16 Feb '15

Does with-foreign-pointer free up the memory after body is executed? I have been using constructs such as: (let ((num-channel-groups* (foreign-alloc :uint))) (ddc-get-num-channel-groups file-handle* num-channel-groups*) (prog1 (mem-ref num-channel-groups* :uint) (foreign-free num-channel-groups*))) Is with-foreign-pointer the idiomatic way to accomplish the same thing? Thanks Mirko

2 1

[Cffi-devel] foreign-free causes stack dump (on CCL) after a repeated calls
by Mirko Vukovic 13 Feb '15

13 Feb '15

Hello, I am running 64-bit CCL 1.10 on Windows 7. I'm writing an interface to a National Instruments library (dll) The library was downloaded from the NI site. It was compiled using Microsofts C++ compiler. I get a stack dump when a pointer is being freed using foreign-free. This error occurs not in a fresh lisp session, but after a second or third call to the same function (with same arguments). One more detail: the library is used to access data in files in NI's TDMS format. This error does not seem to happen on all files that I am trying to access, only some of them. I don't have much experience in cross-language library interface building, and I am wondering if I am making some kind of mistake. I am hoping for pointers on how to debug this further. I define a pointer of type :uint to access results of a call to a library function that places them into an unsigned int variable. I then retrieve the value using using mem-ref, and the free the pointer. This is where the stack dump happens. What follows is the defcfun, and the lisp function. I mark with *** the pointer, and the relevant variable definitions that pertain to it: The C-function interface (with the C-documentation included) is (defcfun (ddc-get-num-channel-group-properties "DDC_GetNumChannelGroupProperties") ddc-code " This function will get numberOfProperites (via a pointer) int DDC_GetNumChannelGroupProperties (DDCChannelGroupHandle channelGroup, unsigned int *numberOfProperties); *******" (group-handle group-handle) ;; group-handle is define to be a pointer type (num-channel-group-properties :pointer)) ;;******* The pointer issue arises with the second variable num-channel-group-properties. The lisp code where the error occurs is below (relevant lines highlighted with ***). (defun get-num-channel-group-properties (group-handle*) "Get number of file properties FILE-HANDLE* is a pointer to the file handle" ;; (trace foreign-alloc) (let ((number-of-properties (let ((number-of-properties* (foreign-alloc :uint))) ;;****** (print 'allocated-pointer) (print number-of-properties*) (ddc-get-num-channel-group-properties group-handle* number-of-properties*) (print 'done-with-ddc) (prog2 (print 'acessing-number-of-properties) (mem-ref number-of-properties* :uint) ;; ******** (print 'freeing-pointer) (foreign-free number-of-properties*) ;; ******** (print 'freed-pointer))))) ;; (untrace foreign-alloc) (print 'ready-to-return-with-value) number-of-properties)) The traceback is: ALLOCATED-POINTER #<A Foreign Pointer #x5FFC70> DONE-WITH-DDC ACESSING-NUMBER-OF-PROPERTIES FREEING-POINTER 1> Calling (FOREIGN-FREE #<A Foreign Pointer #x5FFC70>) and the debugger traceback is (#x0000000026479810) #x00000000000F532C : #<Function FREE #x00000001000F51BF> + 365 (#x0000000026479840) #x0000000001491314 : #<Function (TRACED FOREIGN-FREE) #x000000210149109F> + 629 (#x0000000026479888) #x000000000139DE14 : #<Function GET-NUM-CHANNEL-GROUP-PROPERTIES #x000000210139DCDF> + 309 So, to summarize: I have created a pointer to access results of a library call. Library accesses contents of files created with National Instruments software. Library is compiled with MS C++. The pointer free crash occurs on the third call of the lisp function. The first two calls (with same arguments) run OK. Thanks, Mirko

1 1

[Cffi-devel] cffi-grovel bitfield
by Frank 31 Jan '15

31 Jan '15

Given this C code: enum uv_tcp_flags { /* Used with uv_tcp_bind, when an IPv6 address is used. */ UV_TCP_IPV6ONLY = 1 }; The following cffi-grovel form fails: (bitfield (uv-tcp-flags) ((:ipv6-only "UV_TCP_IPV6ONLY"))) The C-file generated by cffi-grovel looks like this: /* bitfield section for UV-TCP-FLAGS */ fputs("(cffi:defbitfield (", output); fputs("uv-tcp-flags", output); fputs(")", output); fputs("\n (", output); fputs(":ipv6-only", output); fputs(" ", output); #ifdef UV_TCP_IPV6ONLY fprintf(output, "%d", UV_TCP_IPV6ONLY); #else fputs("\n #.(cl:progn (cl:warn 'cffi-grovel:missing-definition :name 'IPV6-ONLY) -1)", output); #endif fputs(")", output); fputs(")\n", output); Obviously the #ifdef guard is the culprit here. Maybe you guys want to fix this?

2 4

[Cffi-devel] New CFFI dependency: UIOP
by Luís Oliveira 26 Jan '15

26 Jan '15

Hello, While fixing lp bug #1414277 <https://bugs.launchpad.net/cffi/+bug/1414277> I needed to use a couple of utilities provided by UIOP that would have been a pain to implement in CFFI-SYS. UIOP is ASDF's utility library -- it is also available standalone via Quicklisp -- and next version of CFFI will depend on it. I hope that's not inconvenient to anyone. :-) Cheers, -- Luís Oliveira http://kerno.org/~luis/

2 2

[Cffi-devel] Fwd: Passed: cffi/cffi#1 (master - 6cf6892)
by Luís Oliveira 07 Dec '14

07 Dec '14

Hello, I've just finished setting up Travis CI for the CFFI repository. This means that each commit and pull request will be tested automatically. If an unexpected test fails, the commit author gets a notification similar to one I'm forwarding only with more red. Currently only SBCL (32, and 64-bit) and CCL (64-bit) are being tested because the other Lisps fail to even execute the suite on the test box. (The setup bits come from https://github.com/luismbo/cl-travis that I hope you may find useful in your own lisp projects.) Cheers, ---------- Forwarded message ---------- From: Travis CI <notifications(a)travis-ci.org> Date: Sat, Dec 6, 2014 at 3:31 PM Subject: Passed: cffi/cffi#1 (master - 6cf6892) To: loliveira(a)common-lisp.net *cffi / cffi <http://clicks.travis-ci.org/track/click/30007208/travis-ci.org?p=eyJzIjoia1…>* (master <http://clicks.travis-ci.org/track/click/30007208/github.com?p=eyJzIjoiS1VWN…> ) Build #1 passed. <http://clicks.travis-ci.org/track/click/30007208/travis-ci.org?p=eyJzIjoicU…> 2 minutes and 22 seconds *Luís Oliveira* 6cf6892 <http://clicks.travis-ci.org/track/click/30007208/github.com?p=eyJzIjoieExrR…> Changeset → <http://clicks.travis-ci.org/track/click/30007208/github.com?p=eyJzIjoiekRQa…> Test using Travis CI *Want to know about upcoming build environment updates?* Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you! Sign up here <http://clicks.travis-ci.org/track/click/30007208/eepurl.com?p=eyJzIjoiV044d…>. Documentation <http://clicks.travis-ci.org/track/click/30007208/docs.travis-ci.com?p=eyJzI…> about Travis CI For help please join our IRC channel irc.freenode.net#travis. Choose who receives these build notification emails in your configuration file <http://clicks.travis-ci.org/track/click/30007208/docs.travis-ci.com?p=eyJzI…>. *Would you like to test your private code?* Travis Pro <http://clicks.travis-ci.org/track/click/30007208/travis-ci.com?p=eyJzIjoiVG…> could be your new best friend! Travis CI is powered by -- Luís Oliveira <http://kerno.org/~luis/>http://kerno.org/~luis/

2 1

[Cffi-devel] Bugtracker
by Stelian Ionescu 01 Dec '14

01 Dec '14

Once upon a time Launchpad was the best in open-source and Github's issue tracker was unusable, but that's no longer the case. How about we officially switch to Github ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

2 6

[Cffi-devel] pkg-flags (was: Re: Cannot load cffi-libffi)
by Luís Oliveira 29 Nov '14

29 Nov '14

OK, so I see two needs for pkg-flags here then. 1. finding headers that aren't in the standard locations and wouldn't otherwise be found. 2. finding headers for a specific version of a library. I think the current committed behaviour works nicely for use case #1. Use case #2, which you've raised, suggests that ignoring a missing pkg-config is a bad default. What about adding making it an option? Also, if we're going to cater to use case #2, then perhaps we should support a list of alternatives à la define-foreign-library. What do you think? Finally, how about renaming the directive to pkg-config-cflags? (I can sort of imagine we might want a pkg-config-lfags for wrappers at some point in the future.) -- Luís Oliveira http://kerno.org/~luis/

3 3

Re: [Cffi-devel] [Asdf-devel] native-namestring in asdf/cache:normalize-namestring?
by Faré 25 Nov '14

25 Nov '14

Dear Orivej, I believe this is a bug in CFFI, and ASDF cannot do much about it. I'm copying the CFFI-devel mailing-list. I'm not convinced that these pathnames with invalid namestring would have a valid native-namestring (did you try?), and using native-namestring in asdf/cache:normalize-namestring would be quite impractical, since the function CL:FILE-WRITE-DATE that we subsequently use requires a Lisp namestring. The correct thing to do would be for CFFI to assume ASDF3 (which has been out for almost 2 years and has since been adopted by all maintained implementations), and use this definition: (defun exe-filename (defaults) (let ((defaults (uiop:ensure-pathname defaults :namestring :native :want-non-wild t :want-file t))) ;; YMMV (uiop:subpathname defaults (uiop:parse-unix-namestring (pathname-name defaults) :type *exe-extension*))) NB: if ASDF3 is adopted, the #+sbcl and other such kluges in cffi.asd could also be replaced by :if-feature :sbcl, the defmethod for operation-done-p should be dropped, and the defmethod perform could be replaced by: (defsystem "cffi" ... :in-order-to ((test-op (test-op "cffi-tests")))) and cffi-tests could similarly use an inline method :perform (test-op (o c) ...) instead of a defmethod. PS: the reason why SBCL (and many other implementations) have unprintable pathnames is because of the read-write consistency requirements for pathnames, which for the CLHS (see *print-readably* entry) specifies must be WRITE-n in a way that they must be read back as a "similar" object, which section 3.2.4.2.2 specifies as component-wise similarity, so that (make-pathname :name "foo.bar" :type nil) MUST NOT have the same readable representation as (make-pathname :name "foo" :type "bar"). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." — Isaac Asimov On Tue, Nov 25, 2014 at 11:24 AM, Orivej Desh <c(a)orivej.org> wrote: > Currently, between CFFI-GROVEL and ASDF, neither normalizes pathnames > with a dot in :NAME and NIL in :TYPE. > > > (cffi-grovel:grovel-file "grovel.cffi") > > in a system definition may cause an error under SBCL in > ASDF/CACHE:NORMALIZE-NAMESTRING when it calls NAMESTRING on > the value of CFFI-GROVEL::EXE-FILENAME: > > Calling > > (cffi-grovel::exe-filename #p"grovel.cffi.lisp") > > returns > > #<pathname (with no namestring) > :HOST #<sb-impl::unix-host {10002ACE43}> > :DEVICE nil > :DIRECTORY (:relative ".") > :NAME "grovel.cffi" > :TYPE nil > :VERSION :newest> > > to ASDF/ACTION:COMPUTE-ACTION-STAMP which can't deal with it when called > with :JUST-DONE NIL. > > Backtrace: http://report.quicklisp.org/cl-libssh2/2014-09-26/failtail.txt > > One solution is to make CFFI-GROVEL::EXE-FILENAME normalize resulting > pathname: https://github.com/cffi/cffi/pull/52 > > Another is to make ASDF/CACHE:NORMALIZE-NAMESTRING call > NATIVE-NAMESTRING instead of NAMESTRING. > > Who should be responsible for normalizing such a pathname, ASDF > of CFFI-GROVEL? >

2 1

[Cffi-devel] inline decfun
by FAU 25 Nov '14

25 Nov '14

I'm wondering if it as any effect to declaim inline a function defined by defcfun?

2 1

[Cffi-devel] clear foreign memory
by FAU 24 Nov '14

24 Nov '14

Hello, Lets say I want to keep around blocks of foreign memory but I need to clear them before I reuse them what would be the best way to do it? In C we could use memset() is there such an equivalent for CFFI? Thanks, Frank

3 4