cffi-devel November 2011

cffi-devel@common-lisp.net

8 participants
7 discussions

[cffi-devel] Digitool MCL support for CFFI (was Re: [info-mcl] ? cffi)
by Chun Tian (binghe) 10 Mar '12

10 Mar '12

Hi, CFFI developers Digitool MCL was a old&famous Common Lisp implementation on PPC Mac OS. Recently it was ported into Intel Mac OS X by running in Rosetta (a PPC emulator by Apple). So there're people still using this platform even when Clozure CL is a better choice. Attach is two patches, one is a CFFI MCL support patch made by James Anderson, the other is a trivial patch for MCL support of trivial-features made by me. With these two patch, CFFI can now be loaded into Digitool MCL. This work seems work with James' own project which is based on CFFI. But CFFI-TESTS cannot run at this time, because ASDF:RUN-SHELL-COMMAND doesn't support MCL (I don't know how to fix this right now). IOlib also cannot work in MCL because Gray Streams wasn't supported by MCL yet ... However, I hope CFFI maintainer could merge this patch and let other MCL users help improving exist work. Chun Tian (binghe) 在 2010-9-28，06:41， james anderson 写道： > good morning; > > i have worked out enough of a cffi-mcl to be able to accomplish the immediate goal - to use the cl-zmq zeromq ffi binding.[1] > in case someone wants to carry it further, it's posted along with a mcl-compatible zmq version,[2] which eliminates un-ported dependencies. > > --- > [1] : http://repo.or.cz/w/cl-zmq.git > [2] : http://github.com/lisp/de.setf.zeromq > > On 2010-09-22, at 08:29 , Chun Tian (binghe) wrote: > >> I've read these documents. MCL 4.0's FFI seems based on the function "define-entry-point" which then depends on "ppc-ff-call", both of them are still available in MCL 5.x, and the related MCL source code is "lib/deftrap.lisp", which was last modified in 2005. >> >> However, I think "define-entry-point" is not the preferred way any more: >> >> ; Change log >> ; >> ; put back define-entry-point and things it depends on - though MCL doesn't use it users may >> ; ------ 5.2b2 >> >> I think CFFI people, if want to support MCL, should research "deftrap.lisp" and figure out the preferred way to do the work. But for me, a USOCKET maintainer, I'd like to use this interface directly to implement UDP networking, which was lack from OpenTransport. >> >> --binghe >> >> 在 2010-9-22，13:30， james anderson 写道： >> >>> there are two sources. >>> >>> if you go to ftp.clozure.com, you will find the 5.2 release and a copy of the documentation for 4.0. >>> i know of no revised documentation for 5.2. other than that, there is always the source. >>> i believe 5.2 has a very different calling mechanism then 4.0, as it uses a different os x facility to manage foreign libraries. >>> >>> the biggest '?' is turning off the gc for the dynamic extent of any foreign calls which pass lisp data. i do not know if that is possible in mcl, but it could be faked by moving the data to/from temporary external storage just to get it working. >>> two little question marks are the data type size calculations and the call-back protocol. >>> since the source is there, there's nothing stopping me from adapting the clozure-specific code to work in mcl. >>> i was just hoping to avoid having to wrap my head around those bits. >>> >>> >>> On 2010-09-22, at 04:45 , Chun Tian (binghe) wrote: >>> >>>> Never know how to do FFI in Digitool MCL ... Where can I find some API documents? >>>> >>>> --binghe >>>> >>>> 在 2010-9-22，05:36， james anderson 写道： >>>> >>>>> good morning; >>>>> >>>>> has anyone ported cffi to mcl? >>>>> >>>>> >>>>> _______________________________________________ >>>>> info-mcl mailing list >>>>> info-mcl(a)clozure.com >>>>> http://clozure.com/mailman/listinfo/info-mcl >>>> >>>> _______________________________________________ >>>> info-mcl mailing list >>>> info-mcl(a)clozure.com >>>> http://clozure.com/mailman/listinfo/info-mcl >>> >>> _______________________________________________ >>> info-mcl mailing list >>> info-mcl(a)clozure.com >>> http://clozure.com/mailman/listinfo/info-mcl >> >> _______________________________________________ >> info-mcl mailing list >> info-mcl(a)clozure.com >> http://clozure.com/mailman/listinfo/info-mcl > > _______________________________________________ > info-mcl mailing list > info-mcl(a)clozure.com > http://clozure.com/mailman/listinfo/info-mcl

2 3

[cffi-devel] cffi-grovel on windows 7
by Karl Heinrichmeyer 30 Nov '11

30 Nov '11

Hello, When I tried to load the osicat library via quicklisp yesterday i got an error because the cffi-groveler couldn't find the c compiler and because the path in the include parameter was ill formed (the drive letter was missing). I fixed the first one by setting the CC environment variable and worked around the second one by changing some few lines in the sources of the groveler. After that I got errors due to some libraries. I would like to check if this is an silicate problem or if the groveler is the cause. So here is my question: What "stable" applications that use the groveler exist? Applications that are known to run under Windows are preferred. Thanks for your help, best regards, Karl

3 3

[cffi-devel] New CFFI with cffi-fsbv
by Liam Healy 27 Nov '11

27 Nov '11

I think the new CFFI with cffi-fsbv is ready to be tested, even by those not needing to call or return foreign structures by value. You can checkout the cffi-fsbv branch after cloning. There are two things to keep in mind: one is to call structures by reference either with :pointer or (:pointer (:struct foo)), as using the structure name alone will result in a style warning. The second is that expand-to-foreign-dyn now has a keyword argument, so methods should have &key. I asked Zach to test compling/loading all of the current quicklisp dist with this branch. There were a few failures: 1) inotify failed because iolib is out of sync with this branch of CFFI (changes independent of fsbv). 2) lispmagick failed because this branch of CFFI didn't have an ASDF version number, so I gave it version number 1.0.0 :-). There remains a failure with TRANSLATE-INTO-FOREIGN-MEMORY on #<CFFI::FOREIGN-STRING-TYPE :UTF-8> which I don't understand. 3) fnv and blapack loads fine for me (apart from a path issue<https://github.com/blindglobe/cl-blapack/issues/1>); Zach gets warning/errors on defining keyword types :complex-double and :complex-float. 4) devil needs to have &key in the arglist for expand-to-foreign-dyn as explained. 5) blackthorn fails to load for Zach but I tried a few systems (blackthorn, blackthorn-stress-test, thopter) and they all load fine. His errors are all like this: Derived type of #:G331 is (VALUES SB-SYS:SYSTEM-AREA-POINTER &OPTIONAL), conflicting with its asserted type (UNSIGNED-BYTE 32). I have not pulled master into this branch, so it's a few commits behind. Post here on how things look for you, good or bad. Liam

1 0

[cffi-devel] Interface problem in LispWorks but not in SBCL
by Sascha Van Cauwelaert 26 Nov '11

26 Nov '11

Hello everybody, I am using SWIG to generate CFFI code to be used into LispWorks 6. The interface is between C++ and Common Lisp. Then, I try to call that function from LispWorks : std::string test() { freopen ("/tmp/mystdout.txt","w",stdout); freopen ("/tmp/mystderr.txt","w",stderr); std::cout << "Redirected stdout." << std::endl; std::cerr << "Redirected stderr." << std::endl; GRelation testgr(3); std::cout << "test ! " << std::endl; std::cerr << "test cerr! " << std::endl; std::cout << testgr.arity() << std::endl; std::cerr << testgr.arity() << std::endl; std::cout << "test after! " << std::endl; std::cerr << "test cerr after! " << std::endl; std::stringstream os; os << testgr << std::endl ; return os.str(); } As you can see, I just create one object and print lots of stuff, including an object attribute. Everything I print before trying to print the attribute prints ok in the redirected outputs. The attribute is not printed and nothing else afterwards. I also get the following error when I add testgr to the stringstream os : lispworks-personal-6-0-1-macos-universal(52881,0xb0314000) malloc: *** error for object 0x17be20f8: pointer being freed was not allocated This is what happen in LispWorks. If I compile directly in C++, no problem. If I use SBCL (other Common Lisp implementation) instead of LispWorks, everything works correctly ! The problem is that I have to use LispWorks ... Does anybody has had a similar problem ? I guess I am not the only one who tried to call some C++ from LispWorks. Any clue is very welcome. I think maybe the problem can be linked to the garbage collection from LispWorks but I don't know much about this. I thank you in advance for your help, I am really stuck here. Regards, Sascha

3 6

[cffi-devel] Refactoring SWIG-generated ACL stubs into CFFI/UFFI
by Victor 26 Nov '11

26 Nov '11

Hi! The CFFI generator in SWIG produces incomplete stubs compared to the Allegro CL one. The case in question are the stubs for Mapserver's MapScript wrapper: http://mapserver.org/mapscript/index.html The Lisp wrapper code generated for ACL is pretty much an ordinary Common Lisp. Except for a bunch of ACL-specific functions (from EXCL and FF packages). The functions from EXCL package are easy to replace with freely-available replacements. But the functions from FF package are a little bit different than the functions from CFFI. They look like more similar to the UFFI but still are not the same. Did anybody face a similar problem already? What is the best way to refactor the ACL wrappers to be portable across implementations? Does anybody have improved CFFI generator for SWIG? Thanks, Victor -- реклама ----------------------------------------------------------- Никогда не покупали в интернете? Лучшее место для покупок онлайн - http://aukro.ua

2 1

[cffi-devel] Accessing integer arrays Lisp->C
by Stephan Frank 24 Nov '11

24 Nov '11

Hi everybody, I have a problem that I was not able to resolve with the manual. I have the following C function (which is a trimmed down version of a C++ wrapper): extern "C" { void tryit(const int *ints, unsigned count) { for(unsigned i=0; i<count; i++) { cerr << "index " << i << ": " << ints[i] << "\n"; } } } /* extern "C" */ Now I want to call it with an array that is allocated and initialized on the Lisp side: (defcfun ("tryit" try-it) :void (vars :pointer) (count :unsigned-int)) (defun test () (let* ((l (list 1 2 3)) (len (length l)) (i 0)) (with-foreign-object (idx :int len) (map nil (lambda (x) (setf (mem-ref idx :int i) x) (incf i)) l) (try-it idx len)))) I'm quite convinced that this should now print 1,2,3 to cerr for the corresponding indices. However, I get the following: index 0: 197121 index 1: 0 index 2: 6581024 Any insight on what I'm doing wrong is greatly appreciated. Best regards, Stephan

3 2

[cffi-devel] cffi-grovel *cpu-word-size-flags*: wrong on Windows/amd64
by Anton Kovalenko 10 Nov '11

10 Nov '11

Hello CFFI developers, There is a following fragment in cffi/grovel/grovel.lisp: (defparameter *cpu-word-size-flags* (ecase (cffi:foreign-type-size :long) (4 (list "-m32")) (8 (list "-m64")))) It would be better to use :intptr instead of :long, because on 64-bit MS Windows, long is not long enough. AFAIK, there are no official "multilib" mingw64 builds, so -m32/-m64 are unlikely to be too useful nowadays. However, passing wrong word size to gcc prevents it from building correct binaries anyway: if that word size is unsupported, gcc will refuse to compile anything. I ran into this problem with my Windows/amd64 port of SBCL. -- Regards, Anton Kovalenko <http://github.com/akovalenko/sbcl-win32-threads> +7(916)345-34-02 | Elektrostal' MO, Russia

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel November 2011