cffi-devel March 2011

cffi-devel@common-lisp.net

3 participants
4 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] A question about C and Unicode
by nitralime 23 Mar '11

23 Mar '11

Hi folks! I am playing around with a C library and came across some issues related to unicode in C. In the unicode enabled version of this C library which implements UCS-2 (i.e. just BMP) the "unicode character type" is defined in the header file as follows: ====================================== /* * ZAB_CHAR * ZAB_UC */ #ifdef ZABonAIX #if defined(_AIX51) && defined(ZABwith64_BIT) #define ZABonAIX_wchar_is_4B #else #define ZABonAIX_wchar_is_2B #endif #endif #ifdef ZABonAIX #if defined(_AIX51) && defined(ZABwith64_BIT) #define ZABonAIX_wchar_is_4B #elif defined(ZABccQ) #define ZABonAIX_wchar_is_4B #else #define ZABonAIX_wchar_is_2B #endif #endif #if defined(ZABonNT) || \ defined(ZABonOS400) || \ (defined(ZABonOS390) && !defined(_LP64)) || \ defined(ZABonAIX) && defined(ZABonAIX_wchar_is_2B) #define WCHAR_is_2B #else #define WCHAR_is_4B #endif #if defined(ZABonLIN) && defined(GCC_UTF16_PATCH) #if __GNUC_PREREQ (4,3) #include <uchar.h> #define ZAB_UC_is_char16 #endif #endif #ifndef ZABwithUNICODE #define ZAB_UC_is_1B typedef char ZAB_CHAR; typedef char ZAB_UC; #else /* ZABwithUNICODE */ #if defined(WCHAR_is_2B) #define ZAB_UC_is_wchar typedef wchar_t ZAB_CHAR; typedef wchar_t ZAB_UC; #elif defined(ZAB_UC_is_char16) typedef char16_t ZAB_CHAR; typedef char16_t ZAB_UC; #else #define ZAB_UC_is_UTF16_without_wchar typedef unsigned short ZAB_CHAR; typedef unsigned short ZAB_UC; #endif #endif /* ZABwithUNICODE or not */ /* * CFRSDKwith(out)UTF16_LITERALS * for CFR SDK applications: controls use of UTF-16 * literal enabled compilers. */ #if defined(CFRSDKwithUTF16_LITERALS) #elif defined(CFRSDKwithoutUTF16_LITERALS) #define ZABwithoutUTF16_LITERALS #elif defined(WCHAR_is_2B) || \ defined(ZABonHP_UX) || \ (defined(ZABonLIN) && defined(__i386__) && defined(__GNUC__) && (__GNUC__<3)) || \ (defined(ZABonLIN) && defined(GCC_UTF16_PATCH)) || \ defined(ZABonSUN) || defined(ZABonAIX) /* we have literals for UTF-16 */ #else #define ZABwithoutUTF16_LITERALS #endif ====================================== All this boils down to +---------------------------+ +------>-| typedef wchar_t ZAB_CHAR; | | | typedef wchar_t ZAB_UC; | | +---------------------------+ | +---------+ | +----------------------------+ | Unicode |------+------>-| typedef char16_t ZAB_CHAR; | +---------+ | | typedef char16_t ZAB_UC; | | +----------------------------+ | | +----------------------------------+ +------>-| typedef unsigned short ZAB_CHAR; | | typedef unsigned short ZAB_UC; | +----------------------------------+ The question is now: Is it correct (resp. safe) to /*defctype*/ ZAB_UC just as :uint16 and interpret it as a UFT-16 code point (with an appropriate endiannness)? How can the types like wchar_t and char_16_t be defined (resp. used) in CFFI? Regards Nik

2 1

[cffi-devel] trivial-features, CLX and SBCL mutual incompatibility
by Cyrus Harmon 13 Mar '11

13 Mar '11

Forgive me if you've heard me rant about this before, but there is a mutual incompatibility between CLX, trivial-features (which, for me at least, gets pulled in whenever I try to use CFFI) and SBCL. The problem is that trivial-features puts :little-endian on *features* and CLX has the following code in defdeps.lisp: #+(or lispm vax little-endian Minima) (eval-when (eval compile load) (pushnew :clx-little-endian *features*)) These old-style eval-when conditions cause SBCL to issue a warning, which causes ASDF to stop compiling CLX. There are many workarounds to this, such as loading CLX before CFFI and there are many possible fixes (such as making SBCL less pedantic or making ASDF not stop on warnings of this kind, etc...) But it seems to me that either fixing the CLX source code such that it is more tolerant of SBCL's pedantry or, alternatively, picking less common names for the *features* in trivial-features would be a good thing. I don't really have a preference, but it would be nice if the CLX and trivial-features maintainers would play nice with each other such that, at least when using SBCL, one can load trivial-features and then CFFI. I'm certainly open to other suggestions, but I've grown tired of working around this particular problem. thanks, Cyrus

2 4

[cffi-devel] A question about arrays and enums
by nitralime 07 Mar '11

07 Mar '11

Hi folks! Hopefully here is the right place to ask CFFI user related questions. What would be an appropriate CFFI definition for the following C entities? 1) typedef enum { a = 0x01, b = 0x02, c = a | b, d = 0x04 | c } test; 2) typedef char XXX[8]; How are the C arrays handled in CFFI? Any feedback is very much appreciated! Regards Nik

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel March 2011